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.<p>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.<p>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.<p>I suppose web programmers need something to do.
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.<p>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 <i>possible</i> 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.)<p>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 <i>quite</i> the right tools for bug-free implementations of masking.
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.<p>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.
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.
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.
1,000,000 Online transactions per week is most likely browser + mobile based, the larger chunk of transactions being mobile based (I would assume).<p>This problem does not happen on native mobile apps due to saved Apple Pay/Android Pay cards.<p>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.<p>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.
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.<p>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.<p>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.