Username won't fill in on pre-release.mattermost.com

lieut_data

I'm a core committer with Mattermost, and have been scratching my head trying to figure out why 1Password sometimes won't fill in usernames on https://pre-release.mattermost.com (but will fill in passwords). All testing done using Chrome.

I believe the application is following the key parts of your guide at https://support.1password.com/compatible-website-design/. Here's an affected 1Password login configuration (it's not a real account, but it suffices to demonstrate the problem):

The weirdest part about this is that I have some 1Password entries that /do/ fill in the username. So I duplicated one of those, manually changed each bit to match a login that doesn't work (down to the webform details), and verified that it still works. At least from the 1Password UI they're identical, so I'm assuming there's some internal 1Password metadata difference that's breaking things.

Any suggestions?

---

1Password Version: 6.8.9
Extension Version: 4.7.1.90
OS Version: OS X 10.13.5
Sync Type: None

littlebobbytables

Hello @lieut_data,

So the one weird bit I found was it is an extremely clean form but despite that 1Password didn't correctly designate the loginId field as being the username, despite the fact that it's the only other field other than the password one. My testing was somewhat limited but in each test 1Password would fill both the username and password and that was both with using an untouched Login item saved in the browser and one edited to correctly designate the loginId field as being the username. Out of curiosity, when you find only one field is filled, has the field background colour changed from the other field? I'm wondering if the browser is a potential factor here.

lieut_data

@littlebobbytables, thanks for the quick reply, and sorry for my delay. I wanted to give you something a bit more to go on.

To answer your question, when only one field is filled, the background of the username doesn't change, though our app does add the has-error class to give it a red border.

An additional detail I failed to mention: if I auto-fill from this half-filled-in state, the username does get entered the second time.

I decrypted my local database to extract all the metadata, and noticed that when it works, the username is recorded as:

    {
          "value": "test@example.com",
          "name": "username",
          "type": "T",
          "designation": "username"
   },

and when it doesn't, it's recorded as:

{
      "value": "test@example.com",
      "id": "name;opid=__1",
      "type": "E",
      "name": "username",
      "designation": "username"
    }

It looks like newly created logins in 1Password are being auto-filled correctly, so it's entirely possible this was just a bug, since fixed. But without being able to see this metadata difference in the UI, it was hard to "fix" it short of creating a brand new entry.

Thanks for your help :)

littlebobbytables

Hello @lieut_data,

The id field will depend on whether an item was saved within the browser or if the item was manually created from inside the main 1Password window. What the id field is encoding is the HTML id attribute of the field if available and an identifier used by us based on field order. Mostly it's important if we need 1Password to fill multiple fields i.e. three or more as it requires a very particular filling strategy which uses this ID.

lieut_data

That makes sense -- any idea why the id field isn't exposed via the UI? I think it would have been easier to "fix" by hand if the web form details exposed same.

Thanks for the explanation!

littlebobbytables

Hi @lieut_data,

Even the current ability to edit the web form details is a double-edged sword. There are two key filling approaches that lean heavily on the web form details. One requires the web form details match the page so almost any modification beyond the value stored will break that approach. The other allows the user some control but it requires that the Login item was created inside the main 1Password window and that the user has a reasonable understanding of HTML to allow them to build a web form details that will fill the right fields. The label must match the ID, name or at a pinch the label for the field and the field type must match. For the vast majority of our users this is more than they want to know about HTML and should need to know.

Part of me kind of regrets pushing for the ability to edit the web form details. I didn't appreciate how almost any real change would break the most powerful form of filling. Maybe if we ever have the chance to really shake up how filling works we can make some real changes here.