Auto-filling card info w/ Chrome (Mac) changed my purchase!

rensa

This isn't an emergency—I caught the change before I hit the Order button—but when I was placing an order on redbubble.com, I auto-filled my credit card info and the extension changed the quantity of one item from 1 to X ! Which changed my purchase price from $45 to $YYY :

Obviously I can't share the card details on here, but it has the following fields:

• Title
• Cardholder's name
• Type
• Number
• Verification Number
• Expiry Date
• Valid From
• Issuing Bank
• PIN

---

1Password Version: 6.3.3
Extension Version: 4.5.9.90
OS Version: OS X 10.11.6
Sync Type: Dropbox

rensa

(Without putting too fine a point on it, I understand that by talking about which fields the card has and the quantity the order changed to, there's a possibility that I'm leaking a wee bit of card data here, if this is a bug that operates that way. I don't know that it is or does, and I'm comfortable with the possibility either way.)

littlebobbytables

Hi @rensa,

I'm possibly being crazy cautious but that's who I am. I've removed a couple of the details so that nothing should be guessable even though key data was never at risk.

If you're comfortable providing it here, what will really help us look into this report is the site where you experienced the issue. If we can reproduce the issue we can work on trying to make sure it doesn't happen again. The reason it happened at all is unlike Login items, where they only need to work well with one site, Credit Card and Identity items need to work well anywhere and we're normally trying to identify a variety of text based fields based on just a few clues. It does mean sometimes 1Password can guess wrong but we do what we can to improve the guessing when we hear of sites that highlight less than ideal filling.

If you prefer to tell us the site via email that's fine too, our address is support@agilebits.com and if you include a link to this discussion it will help the person who responds to your email to understand what is happening and ensure the right people see it :smile:

rensa

Hi @littlebobbytables, no worries :) The site it happened on was redbubble.com. If you need any other information, let me know and I'll be happy to email it to you :)

jxpx777

Hi, @rensa. I looked at the redbubble.com checkout page and I definitely see what the problem is. When the Stripe payment form pops up, it is in an <iframe>, which is a way for one page to include another page, often by some third party like Stripe or Twitter. To slightly oversimplify, in this situation, each of the frames on the page looks to 1Password as a separate page, so 1Password gets the information of each of those frames, and then attempts to fill your information in the fields it receives. So, in this case, it gets the fields for the Stripe payment form in one request and the fields for the cart form in another request. The former should have filled in pretty much perfectly. When it gets the latter, though, 1Password is in a bit of a sticky wicket. On the one hand, there's not a lot to go on to fill your credit card details. On the other hand, 1Password knows you asked to fill your credit card details into redbubble.com. What it doesn't have a way to know right now is that both of these requests came from the same tab in your browser, so it treats it as basically the same request.

All this being said, 1Password does have some hints built in to avoid filling quantity fields like this because as you've found out it's not a good surprise. I looked at why we failed to identify the quantity field in this case, and there's honestly just not a lot for us to go on with these fields. Here's what I see:

<input type="number" pattern="\d*" value="1" min="1" class="app-ui-components-EditableNumber-EditableNumber_editor_1YCPs" data-reactid=".1.3.$=1$items.1.$65901194.0.1.1.0.0.1">

Normally, 1Password would look at things like the name and id attributes and the field's <label> (among many other things) to try to reason about the field and exclude it as a quantity field. In this case, there's no id, no name, and no <label> associated. So, that leaves 1Password sort of fumbling in the dark…

All of this isn't to offer any excuse but rather just an explanation of why the behavior you're seeing is happening. If you want to pass this on to the folks at redbubble.com, I think that could be very helpful. In many cases, we have had good results in sharing this information with sites and them being kind and considerate enough to make a slight adjustment to their markup that can help sidestep this issue. But I want to be clear that we aren't passing the buck. This is a problem we need to address very soon and with something more robust than further tuning our exclusion hints for the edge cases that might present themselves.

I'm sorry I don't have a better answer for you at this time. I have created an issue for us to track the work necessary to make the necessary improvements. In the few minutes of typing that up, it's clear that this will require changes across several different codebases, so it's likely not something we can get to in the very short term, but it is something we'll be looking into fairly soon.

Please do let us know if we can be of further assistance.

--
Jamie Phelps
Code Wrangler @ AgileBits

ref: OPX-1238

rensa

Hi Jamie,

Thanks for the explanation! I understand that making solutions like this work universally isn't a trivial exercise, and it's pretty much no-harm-no-foul for me in this case. I'm glad I'm able to draw it to your attention, though, and I appreciate that the feedback is taken seriously :) I'll pass this thread onto redbubble.com too!

(FYI, the Stripe payment frame with the actual card detail fields did indeed fill in perfectly!)

jxpx777

Thanks for your gracious reply, @rensa. I am glad to hear that the Stripe form filled properly. That tells me we're on the right track and just need to exclude the other frame and not boil the ocean to make it all work. :)