Waves.com Cannot Fill Logins

Temptin

https://www.waves.com/login doesn't work with the 1Password extension. Nothing gets filled in.

Here's what my 1password says about the saved login fields (which matches what's in the fields in the current HTML):
Marked as username: "p$lt$placeholder_zone$main_placeholder$p$lt$ContentZone$WavesLogonForm$LoginForm$UserName"
Marked as password: "p$lt$placeholder_zone$main_placeholder$p$lt$ContentZone$WavesLogonForm$LoginForm$Password"
Marked as checkbox: "p$lt$placeholder_zone$main_placeholder$p$lt$ContentZone$WavesLogonForm$LoginForm$RememberMeCB"
Marked as text: "p$lt$placeholder_zone$main_placeholder$p$lt$ContentZone$WavesLogonForm$LoginForm$LoginButton"

---

1Password Version: 6.3.BETA-12
Extension Version: 4.5.5
OS Version: 10.11
Sync Type: Dropbox

jxpx777

Hi, @temptin. I'm sorry for the trouble you're having. I'm not sure what could be the problem… I tested by saving a new Login for this page manually as well as directly in the 1Password application. Both of these filled fine for me. Could you try creating a new Login in the main 1Password application and see if that works for you? If that fails, please try creating a new Login manually in the browser extension.

Let us know how it turns out!

--
Jamie Phelps
Code Wrangler @ AgileBits

Temptin

@jxpx777: Very weird. I created a new entry and it works. The old entry still does not work.

So I compared them:

• New Username:
  p$lt$placeholder_zone$main_placeholder$p$lt$ContentZone$WavesLogonForm$LoginForm$UserName

• Old Username:
  p$lt$placeholder_zone$main_placeholder$p$lt$ContentZone$WavesLogonForm$LoginForm$UserName

• New Password:
  p$lt$placeholder_zone$main_placeholder$p$lt$ContentZone$WavesLogonForm$LoginForm$Password

• Old Password:
  p$lt$placeholder_zone$main_placeholder$p$lt$ContentZone$WavesLogonForm$LoginForm$Password

• New Checkbox:
  p$lt$placeholder_zone$main_placeholder$p$lt$ContentZone$WavesLogonForm$LoginForm$RememberMeCB

• Old Checkbox:
  p$lt$placeholder_zone$main_placeholder$p$lt$ContentZone$WavesLogonForm$LoginForm$RememberMeCB

They're identical. And they're marked as affecting the exact same URL (https://www.waves.com/login). So I started looking at the differences...

The old one had an additional form field that wasn't in the new one, so I deleted this one from the old login entry:
Name: p$lt$placeholder_zone$main_placeholder$p$lt$ContentZone$WavesLogonForm$LoginForm$LoginButton
Type: Text
Value: LOG IN

That didn't help. Then I noticed that the new one had an extra, empty "Text" type form field, with no label, no value. So I added that manually to my old login. Still nothing.

So now I have two login items, with identical form field names, and only the newly created one works.

Perhaps I've textually encoded the web field names incorrectly somehow (UTF vs whatever). Because the Waves website was recently redesigned, and I manually edited the old login's form details to copy-paste the new field names there. I copied the field names via Safari's web inspector and pasted them into 1Password, and ensured there was no leading/trailing whitespace when copying. Maybe manually writing the fields into 1Password results in some different encoding compared to letting the extension save it, which means it can't find the fields on the site. The $ sign may be problematic when copied manually from Safari's web inspector? Just my only theory. I've deleted the old login now.

Temptin

It's also possible that 1Password itself has some encoding bug, which properly stores $ to the database when saved via the extension, but not when manually editing the names of the form fields in the item details?

littlebobbytables

Hi @Temptin,

It's hard to say. On the surface the site looks simple enough that we should be able to cope with it no matter what, essentially ignoring the specifics web form details and using just the username and password fields. In general though what you see in the web form details section is a partial view of the full fingerprint. There's a lot more hidden and if you're interested you can get a better view.

1. Switch to the Advanced tab of 1Password's preferences.
2. Enable the Copy JSON option.
3. Select the item in your vault.
4. Use the keyboard shortcut ⌥⌘J to copy the extension JSON to your clipboard.

If you nice text editor that allows you to compare differences between files (I like TextWrangler) then you can paste the extension for the two items into different files and if you pretty up the format you can have a way of more easily comparing the two items. There's a nice filter you can add to TextWrangler for example using the steps in TextWrangler filters to tidy XML and tidy JSON. I use this system myself for this very reason, to compare JSONs as sometimes that helps me understand what the heck is going on.

Given even a basic Login item (that's what I call an item created from inside 1Password, one that has no clue what the page looks like) I wonder if something has gone wrong and we should really figure out what. Do you still have a copy of the original item that failed to fill before you started tweaking it?

Temptin

@littlebobbytables Hmm, alright I'd like to help with this. So I restored the old item (the one that came from 2013, but was manually changed to the new URL and input field names of the new Waves website).

The old, manually-updated one is the one that fails to fill on Waves.com. Maybe one of these hidden differences can explain why the Old fails to fill and the New succeeds.

• Old (Created in 2013, and edited to use the form field names and login URL of the modern Waves website)

{"nakedDomains":["waves.com"],"secureContents":{"fields":[{"value":"Temptin","id":"ctl00_ContentPlaceHolder1_LoginTxt","name":"p$lt$placeholder_zone$main_placeholder$p$lt$ContentZone$WavesLogonForm$LoginForm$UserName","type":"T","designation":"username"},{"value":"ASuperPassword!","id":"ctl00_ContentPlaceHolder1_PasswordTxt","name":"p$lt$placeholder_zone$main_placeholder$p$lt$ContentZone$WavesLogonForm$LoginForm$Password","type":"P","designation":"password"},{"name":"p$lt$placeholder_zone$main_placeholder$p$lt$ContentZone$WavesLogonForm$LoginForm$RememberMeCB","type":"C"},{"name":"p$lt$placeholder_zone$main_placeholder$p$lt$ContentZone$WavesLogonForm$LoginForm$LoginButton","value":"LOG IN"}],"notesPlain":"2013-06","htmlForm":{"htmlName":"aspnetForm","htmlMethod":"post","htmlAction":"https:\/\/register.waves.comClientlogin.aspx","htmlID":"aspnetForm"}},"overview":{"tags":["Studio"],"title":"Waves (Old)","url":"https:\/\/www.waves.com\/login"},"uuid":"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"}

• New (Created manually by going to the page, filling in the login form, and telling the extension to "Save Login".

{"nakedDomains":["waves.com"],"secureContents":{"fields":[{"value":"","id":";opid=__7","name":"","type":"T"},{"value":"Temptin","id":"p_lt_placeholder_zone_main_placeholder_p_lt_ContentZone_WavesLogonForm_LoginForm_UserName;opid=__9","name":"p$lt$placeholder_zone$main_placeholder$p$lt$ContentZone$WavesLogonForm$LoginForm$UserName","type":"T","designation":"username"},{"value":"ASuperPassword!","id":"p_lt_placeholder_zone_main_placeholder_p_lt_ContentZone_WavesLogonForm_LoginForm_Password;opid=__10","name":"p$lt$placeholder_zone$main_placeholder$p$lt$ContentZone$WavesLogonForm$LoginForm$Password","type":"P","designation":"password"},{"value":"","id":"p_lt_placeholder_zone_main_placeholder_p_lt_ContentZone_WavesLogonForm_LoginForm_RememberMeCB;opid=__11","name":"p$lt$placeholder_zone$main_placeholder$p$lt$ContentZone$WavesLogonForm$LoginForm$RememberMeCB","type":"C"},{"value":"LOG IN","id":"p_lt_placeholder_zone_main_placeholder_p_lt_ContentZone_WavesLogonForm_LoginForm_LoginButton;opid=__12","name":"p$lt$placeholder_zone$main_placeholder$p$lt$ContentZone$WavesLogonForm$LoginForm$LoginButton","type":"I"},{"value":"Continue Shopping","id":";opid=__15","name":"","type":"B"}],"htmlForm":{"htmlMethod":"LB1"},"notesPlain":"2013-06"},"overview":{"tags":["Studio"],"title":"Waves","url":"https:\/\/www.waves.com\/login"},"uuid":"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"}

jxpx777

Hi, @Temptin. It's not obvious, but 1Password does store some more information about the page than what is shown in the Web Form Details section. For instance, in your case there, the ids of the fields has changed. The new Login has an id of p_lt_placeholder_zone_main_placeholder_p_lt_ContentZone_WavesLogonForm_LoginForm_UserName for the username field. The old Login has an id of ctl00_ContentPlaceHolder1_LoginTxt. Also, since you originally saved that Login in 2013, we have improved Login saving and now collect even more information and we now try to understand the page slightly differently than we did before.

That's the bad news and explains some of why saving a new Login works for you. The good news, though, is that in recent releases, we have greatly improved 1Password's ability to fill Logins after the page has changed and including when saving the Login from the main 1Password application, which does not capture all of these details about the page. Depending on your current version, I would also recommend trying this out when 1Password 6.3 is available as it contains the latest and greatest version of our form filling brain with many of these improvements. It should be available pretty soon, so stay tuned.

Let us know if you have any other questions or troubles. We're always here to help. :)

--
Jamie Phelps
Code Wrangler @ AgileBits

Temptin

@jxpx777 @littlebobbytables

Thanks for finding it, that's a good catch, and that's exactly what Little Bobby Tables suspected: 1Password does something "wrong" (it could be improved in that area) when manually editing a login.

In this case, you are right Jamie! The new site has "input name="p$lt$placeholder_zone$main_placeholder$p$lt$ContentZone$WavesLogonForm$LoginForm$UserName" type="text" maxlength="100" id="p_lt_placeholder_zone_main_placeholder_p_lt_ContentZone_WavesLogonForm_LoginForm_UserName" class="tb username" data-validation-type="required""

Both the name and the ID of the field has changed on the new website.

So now we know that this problem happened because I manually edited the form field data in the login, but that 1Password only changes the "name=""" portion of 1Password's DB. The browser extension still kept looking for the old "id=""" input object on the website, since the old ID was in the internal (hidden) data, which the user can't edit at all. Ugh. It's problematic that 1Password maintains the oldest-possible form "id" value, even as a website evolves.

Here's a proposal: When the user manually edits the "Show Form Details" entries, do this: "If newfieldname != oldfieldname { delete the hidden id field from the database, and the hidden form ID field too }". So in my case, I would have changed the name of the Username field, and 1Password would have deleted the old "id" entry. As a result, it would have been able to fill with the updated old login, instead of having to make a new one.

Alternatively, make the browser extension smart enough to try a name="" match if the id="" match fails? Or maybe that's already been done in the latest betas? But I'd prefer 1Password deleting the old, invalid ID when the user manually changes the name of a form field. The only time a user would change those fields is when the website has been redesigned and no longer fills in, so we can assume that the old ID is no longer valid either.

Yet another alternative: Make the 1Password Extension detect the new form field id/name pair when you log in, and compare it to what's in the DB, and automatically update the DB if it's outdated.

jxpx777

You're right. This is something we can do better with, and we have a few ideas for how to approach it. But, it will require quite a bit of coordination among all the platforms in order to make any changes related to this go well. At any rate, I'm glad that we solved the issue. We'll definitely keep this on our list for future improvements.