How to autofill CBS All Access sign-up/sign-in page?
CBS All Access has no separate sign-in page thatI can find, just a unified "sign up or sign in" page (https://www.cbs.com/user/signup/), and 1Password always fills the username and password the "sign-up" half of the page. I've tried manually saving a new login with only the "sign-in" fields filled out; I've tried manually changing the web form details (the sign-in fields are named j_username and j_password), but no matter what I do, 1Password stubbornly keeps filling in the plain username and password fields on the left hand side. I can use shift-command-C to copy and paste the password, but still have to manually type in my email address every time I sign in. How can I fix/work around this?
1Password Version: 1Password 6 Version 6.8.3 (683005) AgileBits Store
Extension Version: 4.6.11 (Safari), 4.6.11.91 (Chrome)
OS Version: MacOS 10.12.6 (16G29)
Sync Type: 1Password account
Comments
-
@markjreed: You're right. I'm sorry. This is just completely broken. Arguably 1Password is doing the sensible thing here, by preferring "username" and "password" to their "j" counterparts...but when confronted with this rather insensible web design, that's no help at all to the user. It looks like we'll probably have to make a custom rule for this page. As far as I can tell there's no other workaround for the time being besides copy/paste. I'm sorry for the inconvenience there. Thank you for letting us know about this.
ref: OPX-1436
0 -
Hm. I know 1P is trying to be robust and flexible in the wake of changing sign-in pages (or multiple different ones on a given site), but it seems that if the web form details for a login item list a set of fields to fill in, and those fields are on the page, it should fill those fields in on the page. At least in addition to, if not instead of, filling in whatever other username and password fields it can find. That doesn't seem like a special case for this one site - it's the behavior I was expecting and was surprised not to see.
0 -
@markjreed I think that the answer to this lies in the extension and form filling library being a bit smarter about what fields we target for filling. In this case, for instance, the page is helping us by having fairly simple, semantic code that 1Password should be able to reason about. If 1Password could know that a) you're filling a Login and not an Identity or generated Password and b) there are multiple forms on this page and one and only one of them looks like a basic sign in form (a single text field and password), then we should be able to target that form for that particular type of filling.
A while back (maybe a couple years at this point?) we tried to accommodate poorly coded pages1 so much that we ended up punishing some sites that had good coding practices. We're working to swing this pendulum back toward the middle with some smarter targeting of fields when the extension or form filling library can reasonably target a smaller subset of fields. This requires some cooperation with the platform apps, but it is something we are working on and hope to have in our users' hands in the not-too-distant future.
--
Jamie Phelps
Code Wrangler @ AgileBits
Fort Worth, Texas-
Some pages were using separate
<form>elements around each field rather than a single<form>element for all the fields that should be submitted together. Still some other sites had one gigantic<form>object that encompassed multiple logical forms such as a registration and sign in form. There are other approaches as well, but this gives an idea of the kind of thing we have tried to accommodate and often times at the expense of compatibility with some other sites that are coded to behave better. ↩︎
0 -
