Chat support available. Click the chat icon on the bottom right corner to start chatting with us right away!

mSecure Support

base di conoscenza Invia un biglietto

Auto-Copy Passwords

On mSecure 6, both Windows 11 and iOS 15.3.1, with the setting to auto-copy passwords when visiting URLs, the password does not get copied to the clipboard.  The button to copy the password does work, and if I remember to do it before clicking the link I get almost the same experience I had with previous versions.

Two things that may be relevant here:

1. I am still on my 30-day trial of essentials (but do plan to upgrade to premium)

2. I have altered My Login template from the default, specifically I have two password fields.  I keep the previous password in a second field along with an added date field to remind me when I last changed it.  (I had changed this long ago using version 5 and it has always worked fine, until the upgrade to 6.)

Is this a known bug?

Hi Jerry,

Thank you for contacting us. I'm not sure what's happening here, but the auto-copy feature should work for both username and password. Real quick, in order for the feature to work, you have to click on a field that is of the URL type. Are you doing that? For example, the default Login template has a field called "Website," and if there is a url in it, if clicked, it will open your default browser automatically to that site. After you do this, the username and/or password should be copied to your device's clipboard.

Is the field you are clicking on a URL type field, and if so, is any data copied to the clipboard after you click on that field?

Hi Mike

Turns out this is not so straightforward as I thought. I haven't detected any kind of a pattern to it, but some sites consistently work (meaning that after I click the URL, the password is copied to the clipboard) and other sites consistently fail (meaning that after I click the URL, the contents of the clipboard are unchanged).

This is the kind of feature I am so used to using that it becomes second nature, and I only notice when it doesn't work. I cannot remember whether the password for this forum was copied to the clipboard last night when I logged in to enter this comment. But I know for certain that after seeing that you had responded, I visited this forum and the password WAS copied to my clipboard. However, the next time I tried it, and every time since, the password was not copied to the clipboard for this forum's record.  This is the only record I can say with certainty worked and then stopped working.  I did not edit it.

I have added several password fields to my Login template.  The most obvious pattern I thought of was that maybe it was failing on the ones that contain more than one password; but I've seen it fail on sites with only one and work on a site with every security question filled in.   It's not whether they are marked as favorites or not, it's not whether they are tagged or not, and it's not whether the site is already logged in or not.  And as I mentioned in the OP, it also happens on my iPhone.  I did not check to see whether it consistently works or fails on the same sites on the iPhone as in Windows 11.  So far, I have not been keeping written track of which ones work and which ones don't, though I do remember some for certain that work and that don't work.

I'll be happy to provide whatever information I can that may help you figure out how to reproduce this, or try some experiments if you have any hunches (I am a software QA engineer).  I don't think I'm doing anything wrong, and these are mostly records that have been working for years, until the upgrade to mSecure 6.  So I think it has to be a bug.

I have attached a .png of my template file. Most logins use this template so I can't say I've tried any others. The template was created using an earlier version of mSecure.  I couldn't say which one, but I've been a user for many years.

Let me know what you'd like me to try or any other information I can provide. 








Hi Jerry,

I just did some testing of this on my PC, and everything is working the way it should. The one thing I need to confirm for you is that only the first password field in the record is getting seen when copying data onto the clipboard. This means that in the template you attached in your previous post, the 2nd and 4th field will be used for copying data to the clipboard, and it will copied in this format: username/password. No matter how many password fields you add to the template or to an individual record, only the first username and password field's data will get copied to the clipboard when you click on a URL field.

To be clear, every time I tested the copying of the data to the clipboard by clicking a URL field in one of my records, the first Username and first Password field were always on the clipboard. This means that after the website loaded in my browser, I would use the paste feature for the clipboard, and the correct data was pasted in this format: username/password.

Hi Mike

I'm not sure exactly how "first" is defined, but in my experience it has always copied from the built-in password field from the default Login template, and that's what I was expecting and what I wanted.

One difference between what you described and what I'm doing is that I only copy the password, not the user name.  I tried setting the preference to copy both, and then tried one of the records that doesn't work for me.  After clicking the URL link for that record, the user name is copied to the clipboard, but not the password.  Then I tried one that has been working and it copied both the username and password.  (In all cases, there is no slash between the user name and password, as implied by your comment.  I don't know the normal behavior as I haven't been doing it this way.)

Sounds to me like the problem may be data related.  So I experimented a little by recreating one of the records that fails, and although I did find that there are two different URL fields in my template (probably just a mistake on my part), no matter which one I click, it fails in the existing record and works in the recreated record.  If I can find a way to make it fail in the recreated record, that should give you repro steps.  I'm in the middle of my work day, so I need to be testing the software I get paid to test. ;o)

But I'll play with it later and let you know whether I can make it happen or not.  Thanks.

Hi Mike

I understand what's happening now.  The sequence of fields in many of my records do not match the sequence of the Login template.  For some records (and that happens to be the ones I use most frequently), the main password field was not the first and so it was not captured to the clipboard.


But why wasn’t it the first?  It’s the first field in my Login template.  I have noticed since the upgrade to 6 that the field sequence of the records I’ve edited was strange.  I am sure I didn’t do that myself, and I’m sure I never saw it before the upgrade to 6.  I had it on the back burner, but now it has a material effect.


Are there any known scenarios when field sequences can change after upgrading to mSecure 6?  Is there a way I can make them all match the template sequence, or do I have to fix the field sequences one by one?  And if I do that, how likely is it that whatever changed them in the first place changes them again?

Thanks in advance.

Hi Jerry,

At this time, there aren't any known issues with field order changing. I'm not sure why yours have changed, but the relationship between fields and templates is much different in mSecure. In past versions, the relationship was very tightly coupled, but in v6 it's much looser, which helps in different circumstances. This change could have led to some of what you're seeing, but I'm not sure at this time.

You should be able to fix the order by changing the order of a fields in the template, save the changes, then edit and reorder again. That should cause mSecure to look through all of the records using the template and set the order on them.

Hi Mike

Thanks for the tip, but unfortunately that didn't work.  I changed the template order and saved several times, and it seems to have no effect on any existing records.  I tried a different template that has only 6 records.  All 6 were in the same sequence, but a different sequence than the template.  I changed the template sequence to match the records, then changed it to something else.  None of the records changed.

Looks like I may have to manually change the field order of a lot of records, unless you have any other ideas?  (Put in a feature request for a "Restore Template" button when editing a record.) 

Hi Jerry,

I talked about this with our developer this morning, and it's not possible for the fields to be reordered now in mSecure 6. The changes we made to the way templates work in the new app have made it so this type of reordering is not currently possible. I will definitely add this as a feature request.

Hi Mike

I realize this is kind of a new topic, but with regard to this template/field order problem (the ultimate cause of password copy not working), it seems that the template model in mSecure6 is this:

  • A template is nothing more than a starting point - a set of fields in a particular sequence that provides a structure for a new record
  • Once created, each record has its own independent set of fields - independent from all other records made by the same template, and independent of the template itself
  • That goes for the field names/types, field sequence, visibility, everything - there is no such thing as changing a template and having that template apply to existing records

Is that correct?  If not, what do I have wrong?

And assuming it is correct, all I can do is scratch my head and wonder what is the thinking behind that design?  It makes import/export effectively impossible, at least to standard formats like .csv.  It makes the task ahead of me - changing the field sequence of all the logins that no longer copy the password because of the field sequence - as difficult as it possibly could be.  (If you have a better methodology than manually editing one record at a time, I'm all ears.)  And it makes it impossible to decide, for example, "I want to add a field to my login records" and then update the template and have the new field appear in existing records.  It looks like to implement such a decision I would have to add the field(s) to every record!

So what's the upside?  Why is this a feature that was worth developing and testing?  What benefit does it provide for the user?  I cannot think of any legitimate use case.  I must be missing something.  Is there a doc you can point me to that describes how templates work and serving suggestions on how to use them?  I couldn't find one.

I do love the record linking feature described on this page ( and would love to provide input for the design (assuming I can get by the last sentence in this post).  There are so many uses for a feature like this.  I have wanted it for a long time. 

Lastly, there is no doubt in my mind that the reordering of fields in my records was done by mSecure itself.  I can see how I might have accidentally moved or deleted a field or two here and there, but there is no way I moved Password near the end and Previous Password near the beginning in as many records as I'm having to correct.  I'm a long-time user so it's possibly related to many upgrades over the years, and no doubt untraceable at this point.  But to be honest, this mess has got me considering alternatives.

Hi Jerry,

Most of what you said in your 3 points is correct, but what you are saying afterwards is not. There are still points in time where mSecure does the work of helping make connections to the record even though the template is a starting point. For example, if you change a record from using one template to another, you'll see that as long as the field names and fields themselves match, the data will be moved over to the new template in the correct field.

Also, if you export your data, it exports correctly in the CSV file. I'm not sure why you would think that wouldn't work just because the records have been decoupled from the template it started with, but it does work. If you export to a CSV file, you'll see each record has all of its data formatted correctly, and if you make a backup, when you restore, all of your data will be restored correctly. Now, instead of the process relying on the templates to get things correct, all of the information needed for the import and restore is held in the record. Templates are not needed to import or restore data.

I've never tried to infer that you reordered your fields, so if that came across in any of my responses, please understand that was not what I meant. I have no doubt that when you upgraded to mSecure 6, or if you restored your data from a backup, the field order was changed. I don't know why, but I believe you. I'm not sure what do for you at this point, because the fields have been reordered, and aside from trying to restore the data from a backup, the only way to get them back in order is to reorder them manually. The app doesn't have a memory of the field's order from previous states, so there's no way to put them back to a previous point without trying to restore from a backup.

Do you want to try restoring from a backup? It should restore the order of the fields.

One thing I need to ask, while we don't want to make excuses for the order of the fields not being changed after the upgrade, and if there is a bug we are able to reproduce in this context it will be fixed, can you let me know why the order of the fields is so important that you're considering moving to a different password manager? Was data lost as well?

Hi Mike

Your first comment above about changing from one template to another suggests a strategy that might work for me.  Maybe I can make a template identical to the login template and then switch the errant records to that one and then back to login.  Something to try anyway. 

Export is really not important to me anyway, I just cited it as one apparent flaw in a model that potentially has a different field structure for each record.  (Note I said to standard formats like .csv, by which I meant exchanging the data with a different program.  I'm sure mSecure can interpret its own flavor of .csv, but I wouldn't imagine, say, Excel would make much sense of .csv data that has a different number of fields in a different sequence in every row.  But this is all moot, because as I said import/export isn't all that important to me.)  The other two flaws I cited are more important to me: having to fix the records that no longer copy the passwords like they used to; and having the flexibility down the road to add a field to a template and have it appear in all records for that template.

So I was really asking, and still am, if you have any doc about the benefits of that model.  It seems to me a bad design choice, but I'm probably missing something.  I'd like to understand what the upside is.

I'm sorry if I implied that you said I must've reordered the fields myself.  You neither said nor implied any such thing.  That just the software QA guy in me analyzing the problem and concluding that, although user error is often the cause of strange anomalies, it couldn't have been so widespread as what I'm seeing.

I think there is a bug in there somewhere, but I can't imagine there's enough info to reproduce it.  I'm not even sure it happened entirely in the transition from 5 to 6 or if it happened in an earlier upgrade.  I do know that you would fix it if I could give you repro steps.  And to best of my knowledge no data was lost.

My saying I was "considering alternatives" overstated my position a little, not intentionally.  "Thinking about thinking about alternatives" is a better description, and it's a combination of events that's led me to that point.  First, some of my records are a mess.  Some have very few fields (probably only the ones that had data) and many have fields out of sequence, particularly the password field moved to the bottom.  Until I saw your comment about switching templates, I believed I had hours of cleanup work to do - the kind of work I would have to do if I switched password managers, so I thought why do it twice if there's a more suitable solution out there.  (I'm a bit of a neat freak when it comes to data, so I am not one who can just be happy moving my password field up in the sequence - which admittedly is my own contribution to making this task more difficult.)  Also I just bought a Norton 360, which comes with a password manager (not a good one, at first glance).   And it's cosmetic only and I suspect it may correct itself over time, but a lot of my records have TD Ameritrade icon for some reason

So all these things got me thinking about thinking - but not actually thinking yet.  I'm likely sticking with mSecure, especially if the template trick helps restore my field sequence .  (It's still an edit of all records, but switch-save-switch back is much easier than reordering 17 fields and recreating many records where fields - empty ones I believe - were lost.)

All in all, mSecure has been good to me over the years, and the support has been good when I've needed it.  So although I'm not thrilled about the template model and how it's put a big task on my plate, I know and trust mSecure, I plan to take advantage of the sharing feature, I like tags rather than groups (I'm one whose groups were lost, but not concerned about that), and am really looking forward to the record linking feature.  So it's unlikely I'll really be jumping ship.

Thanks for all your help.


Hi Jerry,

I don't have a document citing the benefits of our design choice. We specify changes for our developers to implement, but we don't write up documents as to the changes benefits for the general public.

I'm still not sure why you think it's a design flaw, however. You are running into a specific problem, that may or may not be related to the changes that were made to how templates were decoupled from record data. Certainly, not being able to change the record fields in the template is related to those changes, but the issue of the fields being reordered may or may not be. Had the fields not been reordered, which they shouldn't have been, you may not have ever known that the way templates and records were related had changed in v6.

To your point about exporting data to a CSV file for use in other apps, that has always been a pretty tedious process. The way the data is exported never matches up well with the formatting needed for the data to be imported into another app, and it always needs to be reformatted to be used in a different password manager. If you were just opening an exported CSV in Excel for some reason, you would be able to do so without any problems. The template/record data relationship has no negative effect on this feature.

Really, the only change is that instead of the records relying on the template for structural, label and icon information, everything is now stored in the record instead. The records are simply self-contained now but that self-containment should never lead to issues for the user unless something went wrong to begin with, which is what has happened here with your fields getting reordered.

I think the best course of action that could fix the entire problem very quickly would be restoring from a backup. If you have a backup that has all your data up to date from before the upgrade to mSecure 6, you could try restoring from that backup, and the field order in your records should be corrected. It's worth a try, I would think, if you know the data is up to date in the backup file.

One thing you mentioned that I have missed is you aren't able to copy passwords like you used to, and I'm not sure what that means. You should be able to copy passwords from your fields in any of the mSecure apps just like you could mSecure 5. The UI may be a little bit different, but you should be able to copy the data from any field very easily. Can you explain this in more detail so I can understand the problem better? Is it happening in the Windows app?

One other thing, regarding adding a field to a template and it being added to all your records, I do see some convenience in this, but so far as I can tell, it only saves a couple of clicks and typing in a label for the record when you edit it next. You still have to add the data to the record, so each record would need to be edited even if you could add a field to the template. Again, I do see the value in it, and it's not impossible for this feature to be added to the current app, I'm just trying to figure out if I'm missing something big that would add a lot more value to being able to do this. 

Hi Mike

The original problem is that passwords stopped auto-copying when I clicked the URL from mSecure. This happened with many of my records, and is what started this thread.

The cause of this problem was the sequence of fields in the record, which after the upgrade to mSecure6 no longer matched the sequence in the template. My Login template has 5 password fields, the upgrade caused the empty ones to move up in the field sequence for many of my records.

The simplest solution for me is, whenever I encounter this problem, to move the Password field up so it's the first Password field in the list. Annoying, and leaves my data in an untidy state which I do not like, but grudgingly workable I guess. This is what I'll do.

But discovering the cause of this problem has me scratching my head as to the benefits of the 'feature' that caused this problem for me. If you don't have a document that explains the benefit of this feature, can you give me a bullet point? Field sequence bugs aside, why on earth would a user ever want templates decoupled from record data? I can't think of a single reason.

I don't have a backup. And even if I did, I've made changes since the upgrade.

There has never been a problem clicking the clipboard icon and explicitly copying a field's contents. This only refers to the auto-copy. My preference is set to auto-copy the password only, not the user name.

As to your last paragraph, which I'll repeat here:

One other thing, regarding adding a field to a template and it being added to all your records, I do see some convenience in this, but so far as I can tell, it only saves a couple of clicks and typing in a label for the record when you edit it next. You still have to add the data to the record, so each record would need to be edited even if you could add a field to the template. Again, I do see the value in it, and it's not impossible for this feature to be added to the current app, I'm just trying to figure out if I'm missing something big that would add a lot more value to being able to do this.

Yes, I think you are. You must be assuming that I might want to add one field to one record every once in awhile.

First, a little more info about this problem that you don't yet have. It seems there are two ways my records were changed by the upgrade, which I'll call Model 1 and Model 2.

Model 1 is the one that manifested the original problem. In Model 1, the fields that contain no data are moved to the top. Since I have 5 Password fields in my Login template, those records would no longer copy my password when I clicked the URL. (More specifically, they 'copied' the first Password field, which was empty.)

In Model 2, the fields that contain no data are removed. This seems to be far more common. These records didn't manifest the copy problem, since the empty Password fields were removed. But when I want to edit those records - which usually means I want to add something to them - the template fields I hadn't populated (yet) are missing.

Model 2 is actually a much worse problem for me.  Changing the order of existing fields is much easier than adding fields.

My Login template has 17 fields (2-3 of which are admittedly redundant or unnecessary, which I may remove someday). Among these are 6 Security Question and Security Answer fields (3 each). The Security Answers are Password fields, which I use in place of the 'true' answers. There are also Previous Password and Date Changed fields.

Imagine I go to a website and I decide to set up the security questions. This website has 3 and I want to provide them all. I now have to add 6 fields and type in the names Security Question 1, Security Answer 1, etc. I realize it would take less time than typing this paragraph, but I already made these fields, why do I have to make them again? And when I do, I'm making them in this one record only, so I'll have to repeat it for every record.

Imagine I go to another website and want to change my password. Normally I would just copy from the Password to the Previous Password field, select today's date, and then click the button in Password to generate a new password. But if the fields have been removed, I need to recreate them first, which is more work than the few clicks it takes to populate them.

This applies to the current problem I have with the way mSecure has upgraded my records, but that was presumably a bug - a side effect of the change in design to decouple the record data from the template, not an effect of the design itself.

Imagine instead that I had say 100 records using a Login template that did not have the Security Question/Answer fields or the change password fields, and I decide to change that template. Now I want to start using those new fields, but instead of them being there in records created using the template, I have to recreate them - in every record where I want to use them.

Of course it saves more than just a couple of clicks if the fields in my template are unrelated to the records.

That's the price I'm paying for mSecure decoupling record data from the template. I'd really like to know what I'm paying it for. That's why I'm asking what the benefit of this decoupling is. It appears to me to be all cost and no benefit, especially given the bugs that manifested during the upgrade. Maybe I'm missing something.

Lastly, regarding the bug itself. You might have a shot at recreating it using my Login template.  Here is a screenshot. 


Maybe if you populate it in mSecure5 and upgrade to 6, you'll see the same issue I'm seeing.  It won't help me at this point, but maybe it will help other users.





















Hi Jerry,

Thank you for the clarification with what you were experiencing in the first place. The problem here is that you are talking about needing a feature to compensate for an issue that shouldn't have taken place. Does that make sense? We aren't going to add a feature to work through an issue, or bug, that took place and shouldn't have. What we need to do is figure out what caused the problem in the first place and fix it. That can be difficult to do at times, but it's how the process works. So in this context that you're trying to work through, had your record fields not been re-ordered to begin with, you probably wouldn't be dealing with many of the problems you have here.

Another thing to mention, when you copy data to the clipboard when you're launching a URL, even if you have 10 empty password field, mSecure should seeing the one field that has data in it. So in the one case you mentioned, the problem with the data getting copied to the clipboard isn't related to the changes to the template/field relationship. The problem is that mSecure is not seeing data that it should. That's simply a bug that needs to be fixed, and I'll talk to our developer about it today. Even with this fixed, however, the fields being reordered could have caused a problem if you have 2 or more password field, and you had them ordered in a certain way to make sure that one of them was copied to your clipboard. The app has to make a decision on which field to copy data from when there are multiple password fields, so if you had them ordered a certain way, the reordering of the fields would have caused a problem. Again, though, that problem shouldn't have happened to begin with, regardless of the template/field relationship.

It would be good to stop thinking every problem you are dealing with is because of this new relationship, because it makes it difficult for me to help you. I don't know how the code was designed. I don't know whether or not this bug or that bug is related to specific changes to specific features. That's something the developer would have to determine. You seem to be stuck on thinking that all of the issues you are experiencing are due to something we changed with the templates that you think was not a good decision. While that may or may not be true, the changes have been implemented, and that implementation isn't going to be reverted. Tweeks will be made to how things work, and bugs will obviously be fixed, but the way template/fields are related is the way it will be unless it changes in some update quite a ways in the future. We need to work on bugs you run into, whether they're related to the template/field relationship change or not, but neither you nor I are ever really going to know why a bug exists. At this point, I need to stop delving into any of that and just try to help you, because I think I may be leading you to believe I know more than I do about the way the code actually works.

From here on out, please just let me know the problems you are dealing with, and I'll do my best to address them. I may have to take it to the developer first to get the right answer, but I'll address them. It doesn't help at this time to continue talking about the template/field relationship implementation and whether it was a good decision or not. From here on out, I want just need to help you get everything working the way it should and address any bugs that need to be addressed if they can be reproduced.

Another thing you mentioned is having to recreate multiple fields when you go to a new website. I don't understanding this one, because if you have created fields in an existing record, those fields you showed me shouldn't ever get removed. You shouldn't have had to recreate them. If you added any number of fields to your Login template, then if you are creating a new Login they will all be there. What do you mean when you say, "I now have to add 6 fields and type in the names Security Question 1, Security Answer 1, etc." You shouldn't have to do that except for existing records that don't yet have those fields yet. If it's a new Login, then you would simply go edit the Template before you create this Login, add the field you want to add for Logins in the future, then the new Login you create and all Logins after that would have all of the fields you added to the template.

Also, you said, "Normally I would just copy from the Password to the Previous Password field, select today's date, and then click the button in Password to generate a new password. But if the fields have been removed, I need to recreate them first..."  None of your fields should have been removed. The only way empty fields should be removed is if you change the Template you use for a record. If you don't change the template for the record, then any field you have added should remain on the record, even if they're empty. If empty fields are not remaining on your records, then there's a problem. On my PC, I don't lose empty fields on my records. I just tested adding multiple fields to my Logins template, then I created records and left certain fields empty. After I edit the record, the empty fields are still there.

So in your example, I would only ever have to add fields to records that existed before those fields were added to the template. After they have been added to a template, they should always be available in every record you create from that time forward. Are you saying that you create a record, fill in certain fields, and then the next time you edit the record, empty fields have been removed?

Accedi o Iscrivitiper pubblicare un commento