What does data-com.agilebits.onepassword.initial-value mean?

danshumaker

I'm a web developer and when i'm testing webforms that I've created i like to save those fields in 1 Password 6 so that when I test them again I can quickly fill out the forms. This works 90% of the time. But lately I've been seeing that 1Password sets the data-com.agilebits.onepassword.initial-value field in the input forms elements but doesn't actually set the input form values even though they are correctly stored in 1Password.

I think what's happening is that 1Password is also saving some hidden form elements and perhaps that is messing things up. When I click on "show webform elements" button in 1Password the values seem correct.

I've got forms that have about 10 to 15 input fields so I'd really like 1Password to help me automatically fill out the forms.

Is there a secret vulcan key board shortcut that says "Force fill out form elements no matter if it's Tuesday from 9-5 and my Aunt Jenny is on the phone".

Thanks for any help.

---

1Password Version: 6.3.5
Extension Version: 4.6.2.90
OS Version: OS X 10.11.6
Sync Type: Not Provided
Referrer: forum-search:data-com.agilebits.onepassword.initial-value

littlebobbytables

Hello @danshumaker,

That data attribute is to help with pages that do funky things dynamically. An example of this are a few banks that obfuscate fields before sending the login credentials. I don't confess to understand how this helps with security, only that we still want to fill when a site does something like this. This attribute is set when we collect the page data that we send to 1Password to determine what to fill and where so it happens very early on in the filling process.

Without having seen the page in question I would suspect one of two strong possibilities if filling is not happening as expected.

1. There's a bug that your form helps highlight.
2. We identify the form as a registration form. When this happens we don't restore all the fields like we would other 3+ field forms. Except for a few niche cases, such as testing during web development, filling of registration forms is not what the user will want 1Password to do. If a site has a single login/registration page what our users want to happen is 1Password offer to save when they register and fill in the login form when they fill and so that's what we do our best to have happen.

At the moment there is no way to bypass this behaviour from the perspective of the user. If the page details we collect suggest a registration form then we disallow restoring of all fields. As a web developer, you likely could tweak the page for testing purposes so that we identify it as such. We currently look at the name and action related to the form for keywords that would suggest registration, signing up or creating an account.

If you think it's a bug we would happily review the page with you and can do so via email if you prefer. That way we can say without doubt why 1Password is behaving the way it is whether it be by design or a bug that we then need to file a report for.

danshumaker

Thanks Bobby,
The form in question is an order form that does have address fields for "the customer" to fill out. So the form has address fields as well as clothing sizes, colors etc. So I guess 1Password is disallowing "re-registration", which is understandable from AgileBit's perspective but IMHO I think you should let us (the 1P user) decide whether or not they should fill out the form upon hitting Cmd+/. In general it's bad practice to try and out smart the user, but that's my opinion. I mean, what's the harm in re-filling out a registration form? Who cares? if the user wants to fill out a registration form a million times why should AgileBits care? I think of 1Password as a fancy copy and paster and right now it's not pasting.
No need to fill out a bug report, just food for thought, and perhaps something to suggest to management.

littlebobbytables

Greetings @danshumaker,

That doesn't sound like something we should be identifying as a registration form. Now normally we'd expect users would fill using an Identity item for forms requiring details such as physical address etc. but based on the limited available information I would expect a saved Login item to work.

As to why we do this, in the significant majority of cases filling a registration form isn't what a user wants 1Password to do. I understand why you want 1Password to do so but we also have to look at how 1Password needs to work for the average user. It has often resulted in stuff even our own developers would like to see in 1Password being disallowed because it isn't something enough of our users would benefit from. I don't see us changing this particular behaviour but it is foolish for us not to remain open-minded, especially if sufficient users want 1Password to do something.

Why we're not restoring all fields here is likely to be for another reason. Given it has options for sizes and colours does the form change a lot in shape and size? The restore fields strategy only works if the page contains the same number of fields and the page description matches that stored in the Login item. If the form changes at all between tests that would also stop 1Password. Is there a possibility this is happening here?

danshumaker

Yes and no (regarding the form changing). No it does not change, it remains mind-numbingly the same (hense the desire to not have to fill it out again and again), but yes, technically Drupal puts hidden input fields that have unique identifiers (think hash values) on them that change per page load so that it can securely deny robot auto-submissions and scripts from auto submitting.

littlebobbytables

Hi @danshumaker,

Ah, the page likes to mess about with the IDs? That would do it. We do look at the IDs as part of how we fingerprint a page.

ref: SHS-79963-945