Password not saved from Consumer Reports Log In

nathangsm

There was no existing Login in my 1Password vault for this site. I entered the username and password at https://ec.consumerreports.org/ec/cro/sem/login.htm, but I did not receive a dialog box to save this to 1Password. After manually creating a Login for this site, 1Password successfully auto-populates the fields but is not able to trigger the "Sign-In" button.

Hope that helps.

p.s. Is this the proper place to report this type of thing, or should I be using some other location/process?

---

1Password Version: 1Password 6 Version 6.3 (630032) AgileBits Store
Extension Version: 4.5.6.90 (Chrome Version 50.0.2661.94 (64-bit))
OS Version: OS X 10.11.5
Sync Type: Families

littlebobbytables

Hi @nathangsm,

This is definitely the right place to be reporting such issues :smile:

So I'm not 100% certain I know the answer here but I think I do. We look for certain actions, certain things being present before the extension fires an event and the idea is to avoid the extension annoying you so much you're sent diving for the uninstall button. I know we react to the enter key and in fact after trying to create a test Login item my natural response was to tap the enter key after typing in my test password. This resulted in 1Password asking if I wanted to save a new Login item and also the site not reacting which is unusual. I deleted the test Login item and repeated the experiment, this time clicking on the Sign-in button. This time 1Password did not react.

Here is where I'm somewhat confident. The form doesn't use the submit action which is generally a really strong clue. I believe the submit event is also what enables the use of the return key, something almost universally used. It also isn't using a button, something else we look for. It seems to an image that responds to the click event. So it slips by all of the checks we have for various indicators that a form is being submitted.

I'm not the best person to comment but it might be the site is unusual enough that tweaking the extension to work here causes false positives elsewhere. I could easily be wrong, I freely admit I don't have enough experience yet of the various designs seen and the implications of adding checks for certain behaviours.

What I'm somewhat more confident is that with time we can support this sites use of a clickable image for logging in terms of auto-submit but it will require creating a specific rule for the site to say don't use the standard procedure, it won't work here - click on this element instead. The reason auto-submit isn't working right now is the standard approach to auto-submit is to place focus on the password field and mimic the enter key being pressed. That's how common it is that this works, it's how it works on over 99.9% of the sites we can auto-submit on but there are a handful that insist on a button being clicked instead so we do have a way of doing this when we discover a site that insists on it.

So I apologise for the difficulties you've had with this site. I'm not sure what we can do about 1Password recognising it as a login form in terms of saving but if there is something that can be done I'll be learning from it :smile:

nathangsm

:+1:

jxpx777

Thanks for understanding, @nathangsm, and thanks for bringing it to our attention. In looking at the site to follow up, I see the following code for the "Sign-In" "button":

<img class="button" src="/ec/images/bnb/btn_signin.png" onclick="loginSubmit();" height="26" width="75">

So, as you can see, there's not a lot for 1Password to go on but we could be a touch more confident than we are now in recognizing this as an attempt to sign in. For instance, the src attribute is trying to tell us that this is a button (btn) that is used for signing in (signin) and that it will be styled as a button (class="button"). So, we have a scintilla of information to go on but not very much. This will require some careful and very deliberate consideration to avoid false positives like LilBobby mentioned.

What's more worrisome to me is how problematic this page would be for anyone that doesn't speak English or the visually impaired. It's generally considered bad form to put text in images like this. First, the text inside this image isn't easily localizable or translatable by something like Google Translate. Moreover, a screen reader such as OS X's VoiceOver can't interpret them and in this case, they've also neglected to include any accessibility attributes such as alt, title, or aria-role, so all VoiceOver would report is that there is an image there but it won't be able to say anything particular about it that would help a visually impaired user know this is the element in need of clicking.

I hope that clarifies things a little further. Thanks again for the report. :)

--
Jamie Phelps
Code Wrangler @ AgileBits

nathangsm

Yeah. You folks are very thorough in your responses. It really does appear that this is a bigger issue than simply finding a way to implement 1Password or other password managers, but a larger "standards" or "best practices" issue that significantly affects accessibility. I myself don't have any visibility or web navigation-related impairments, but I certainly recognize the impact that these "special cases" can have on those who do, in which case it becomes far more than a minor annoyance or a workflow disruption but a real barrier to access. :(

jxpx777

Yep, that's our thinking as well. As someone with fairly good eyesight (I wear glasses but that's not a "disability"…) and who primarily speaks English, I'm in a privileged position to not be more than inconvenienced by such poor practices, but others aren't so fortunate and the subtle bias that makes websites harder to use for people that aren't as privileged is difficult to recognize if steeped in that privileged position.