An HTML attribute potentially worth $4.4M to Chipotle | Hacker News Reader

An HTML attribute potentially worth $4.4M to Chipotle

cloudfour.com

108 pointsitaibo30 comments

In the race to use fancier and fancier tools to make web user interfaces go I think we loose out a lot by avoiding the browser's inbuilt support for these things.

Like how eBay's new search feature does not allow me to click in it and type in one motion. I have to click, wait for it to redraw without the magnifying glass, and then click again to put the cursor where I wanted it, before editing the query.

Or how some sites hijack the scrollbar, or muck with it, or how about that endless scroll that gets mucked up every so often and you gotta start over.

I suppose web programmers need something to do.

Because someone in business wants something different than the web standard.

I shit you not, someone asked to remove scrollbars from nested lists in Windows.

This has nothing to do with web standards. A developer decided to limit a field which could be either 2 or 4 characters to only 2. They could have used 10 different approaches to do this and they all would be broken for autocomplete and copy/paste.

From TFA:

> To test what would happen if Chipotle’s form used these standards, I opened my browser’s developer tools and edited the expiration year field:

> Video of autofill on the Chipotle order form after `maxlength=”2″` has been added using developer tools. It works!

> Adding the maxlength attribute to the field fixes the problem. This makes sense. We’re telling the browser, and by extension the autofill feature, how many digits it should use for the expiration year.

> Autofill is smart enough to know that if we only want two digits for a year field, that the form needs the last two digits of the year. We just need to tell the browser how many digits we expect.

The remapping of middle click is a scourge. I want it to open a new tab, not behave like a left click or do nothing.

I have still never encountered a perfect masking implementation for the web. I don’t believe that they exist. If you think you know of one, please tell me and I’ll see how many seconds it takes me to find bugs in it. Normally it’s less than ten. I’ll be mightily impressed if someone can present me with one that I can’t find bugs in.

Masking is generally surprisingly user-hostile. It’s better to instead take arbitrary user input and make sense of it after the fact—if you want to reformat the value they’ve entered, you might be able to get away with doing that after they blur the field (though even then there are often downsides to doing it), but I believe it’s genuinely impossible to accomplish in a side-effect way before then, across all devices. (It’s not easy, but possible to do it for desktop; but various mobile keyboards are particularly weird and do all kinds of crazy things if you meddle with the value while typing.)

I’m talking about the web specifically here. It’s possible to do things properly outside the web, but the web just doesn’t give you quite the right tools for bug-free implementations of masking.

Do you have a list of issues with various masking techniques, and / or sample input actions? For example, something wanting a North American telephone number in the format (999) 999-9999 often has issues if the user tries to enter parentheses or dashes. A proper solution is to allow the user to enter punctuation, and accept it if it is expected there, and to remember it for backspace purposes (so a backspace will either stop at, or skip over a "-" depending on if the user entered it).

It would be a fun programming exercise to take a long list of inputs and write some javascript that properly handles every one of them (or to point out where there are mutually exclusive requirements).

This.

This is particularly terrible for addresses. The only acceptable solution (that nobody uses) is as follows: allow FREEFORM addresses. Like, I'm OK with the website or the server doing some post-hoc validation, and suggesting to the user "This address doesn't seem right, are you sure it is correct?" But the amount of time I have to enter "county" (or whatever) for my London address (and sometimes it's Greater London, other times just London, or probably something else as well...) is ridiculous, doubly so because mail in the UK arrives without problems with little more than just a postcode.

I hate the way companies try to do custom formatting and validation as you type. It breaks form handling in many different and exciting ways and pretty much ensures that autofill (or even just copy/paste) will fail.

If you must do client-side massaging of form data, at least wait until the user has pressed Submit before messing with the form's contents. And don't assume that the keypresses are the only way your inputs will change.

When I was a UI tester, one thing that would almost always break these validators was to select some text on the the surrounding page, then drag it into the text box. Right-click paste is another way.

I would doubt that it really results in lost orders as people have already invested a lot of time by selecting their food choice and by that time are hungry.

Not everyone will understand that the problem is related to their autofill not behaving properly - it's not too far fetched to think that after trying to submit a few times, that someone would abandon their efforts because the "site isn't working". Probably not as high of a lost revenue as proposed, but I wouldn't doubt it leading to some lost orders.

I mean, that it will result in lost orders is almost a fact due to the sheer number of transactions. At scale, all possible events will happpen. So with that in mind the author of the post said he thinks a conservative number is 0.5%. Maybe you think that's lower. The author posited that option and asked how low do you think it can go to make it worth it to fix the form?

Or to put it another way. Estimate how many programmer-hours it takes to fix this issue. With that number calculate the % of people that are likely to abandon the order. Is that % likely to be happening?

Some 25 years of web usability research has taught us that users are incredibly impatient and will bust out of conversion funnels over the tiniest obstacles like they are the Kool-Aid Man on crack. The conversion rate for most restaurants (e.g. customer places an order) is only 1-3% [0,1].

[0] https://www.blog.shippypro.com/2019/01/27/2019-ecommerce-con...

[1] https://www.growcode.com/blog/ecommerce-conversion-rate/

An interesting read, but the dollar figure is author guesswork. I appreciate this kind of digging into web behaviour though.

"but the dollar figure is author guesswork" any figure presented would be guesswork. It's impossible to measure how many users left your site because they thought it was broken.

The estimate provides meaningful context. Without an estimate, this article amounts to complaining about web standards. With an impact estimate, it is actionable. We have a problem, we know roughly how bad it is, we have a solution.

Maybe it's off by an order of magnitude or 2. If it's costing them $44k/year, it's still worth fixing.

Side question, does not displaying the credit card number and CVV provide any real security value? An overwhelming majority of sites that accept credit cards don't do that and I can't say I have ever been worried about that fact. At least the expiration year is displayed to the user so it is possible to notice if something is entered incorrectly And considering the expiration year masking issue only impacts people who use autofill, likely a small minority of users, I wonder if not displaying the credit card number leads to an even higher number of lost sales.

Yes, most browsers treat password boxes as sensitive input which has implications to a lot of things. For instance if a blind person types in their CVV using assistive tools on Firefox on macOS, making it a password stops it from being read out loud like other input (it's probably the same on an iPhone, and in some cases this would be annoying if you're in public, etc).

Aside from not displaying it, the browser will also not autofill/cache the sensitive information for future visits.

1,000,000 Online transactions per week is most likely browser + mobile based, the larger chunk of transactions being mobile based (I would assume).

This problem does not happen on native mobile apps due to saved Apple Pay/Android Pay cards.

Still a nice article.

There was a much less juicy bug in the previous iteration of Chipotle's website. Due to demand, the pickup time would often be several hours away from time of ordering. But there was no server validation of the time being sent. A little manipulation of the dropdown picker, and you could send any time (or indeed, any text at all), and it would be printed on the ticket at the restaurant.

It was so easy that half our office was able to figure out that you can right click the picker, "Inspect", then type in any time you like.

If there was lost sales from this I would bet it would be related to the error message of failing to save card. I would think more people would leave because of fear of their card being saved.

My bank in the U.S. (BOFA) has some weird autofill problems. When I try to log out of one business account and log into another, often at the last second the autofill will re-fill in the other account (and clash with my LastPass!) and I find myself logged back into one account when the form had the other login info right up to the time I pressed submit.

There are several issues with this. Narrow thinking as regards the sort of input to expect from users. But asides from the input and what sort of data to expect, I'd like to think they have some sort of analytics which shows drop off rate and what actions occurred before these drop offs, this should have made the problem obvious.

I understand why maxlength would be appealing but it takes the hacking skills of a fourth grader to change it in the browser's html and submitting any number that they'd like.

So? That is true for either client side option, which is why you need server side validation as well.

This would make an amazing A/B test to get the real data about how much money was in fact lost due to this issue.

Click bait title. TL;DR: Chipotle is manipulating the year field in CC transactions and expecting a two digit year instead of a four digit, but didn't set a max length on the field.

ALWAYS SANITIZE YOUR INPUTS. When that sanitation is complete, replace what's in the form. You don't always have to sanitize the frontend, but ALWAYS sanitize the backend.

Click bait because there's nothing substantial claiming that this actually resulted in a loss of revenue for Chipotle other than some napkin mathematics. A counter point I would make is that I assume most people don't use CC saving in their browser as everyone seems to make a big stink about it. Additionally I would wonder about the amount of people that would notice their info was correct, but failing, and then go through and manually change the information before submitting again. In this case, they may be more inclined to follow the standard 2 digit year that everyone seems to ask for.

Exactly - complete click bait.

Auto fill messes up the entry, people refill manually. This happens all the time on numerous payment forms

> people refill manually

Only if they suspect that might help. This case doesn't exactly make that clear.

Reply on news.ycombinator.com