Slashdot Mirror
If You Type 1+2+3 Into Your iPhone's Calculator on iOS 11, You Probably Won't Get 6 (qz.com)
A reader shares a report: If you've upgraded your iPhone's operating system to iOS 11, try this: Go to the calculator app and quickly type 1+2+3. You likely won't get 6. You might get 23, or 24, or 16, or 32, or something else, depending on what buttons you tap and in what order, and, obviously, none of which is the right answer. It seems to be because of a new animation in the calculator app, where a button briefly fades to white when you press it. The result is that if you press an operator button (i.e., the plus sign) before the short animation finishes, the app ignores it. So, 1 + 2 + 3 accidentally gets read as 1 + 23.
GUI animation is the absolute cancer. It's everywhere, on desktop, in applications, on websites.
Really feels like everything returned to the 90's web state full of animated GIFs, blinking text and endless pop-ups.
If you're a developer, please don't be a jerk and get rid of all the animated crap, please.
Math is hard.
In Windows, open the calculator and do this:
Take the square root of 4
Subtract 2
You should get 0, but you don't.
The calc app does some sort of weird floating point math (despite the fact that the square root of 4 is exactly 2 and no floating point math is needed) and comes up with an answer of
-1.068281969439142e-19
Math is hard
Reminds me of gmail.com's login form which has a similar bug.
If you type username and then Return, the Return does not immediately switch focus to the password field - it only starts an animation and passes focus to the password field when the animation is done.
So, if you type your password too fast, the first few characters will not end up in the password field (or not at all, if your password is short).
Bugs the hell out of me. The older login form did not have this bug.
"We mustn't be caught by surprise by our own advancing technology" -- Aldous Huxley
Texas Instruments had a similar screwup in the early 80's. After capturing a huge chunk of the U.S. calculator market (TI and HP were the brands to buy), Texas Instruments released a series of lower-cost scientific calculators where the keys were not properly debounced . It was practically impossible to type in a long equation without having multiple double or triple press errors.
I tossed mine in disgust, tried out one of the new Sharp scientific calculators just hitting the market, and never looked back. Texas Instruments basically handed over their share of the scientific calculator market to Sharp and Casio in the space of two years.
At least Apple has the advantage of being able to fix this in a software update.
As a developer I can see exactly how something like this can happen, and I've had variations of it happen to me numerous times over the years. This is a case of the person writing the app making assumptions about how the user interface behaves, and these assumptions turning out to be wrong OR the interface not behaving as documented. (more likely the latter)
The person that wrote the app was probably "safe to assume" that taps on the screen will be buffered during animations and other gui actions. So the app waits for you to tap, and the user taps a coordinate on the screen and your app is notified of this. You look at the location on the screen, figure out the user pressed "2, remember it, and tell the gui to do the fade on the "2" to indicate the press was accepted. Then you go back to waiting for another tap.
If in the meanwhile, the gui is displaying the fading of the "2", the user taps "3", the interface should buffer the tap, and it can either notify the app immediately (during the animation) of the new tap, OR it can wait until the animation is done and then notify the app.
I don't know which approach the gui takes. If it notifies immediately, I would expect the app to tell the gui to stop the "2" animation and start the "3" animation, as this leads to better response time. SOME apps I've seen just linearly buffer and the app won't be notified of the "3" until the "2" is done animating. In those cases you can mash a bunch of keys and then look at the screen as they are animated one at a time until all keys are animated. This is generally considered poor design but I still see it from time to time.
So what went wrong here? There's several possibilities, depending on what the gui supports.
- the gui always disables tap detection while the specific sort of animation used on the "2" is being done
- the developer used an animation api that specifically does not buffer taps when there was a buffering api available he should have used
- the application told the gui to disable buffering during the animation (or neglected to indicate it wanted buffering, if it's not the default action)
- a bug in the app caused it to not buffer taps made while the gui was still rendering an animation
There are probably a few other possibilities but that's the 99% of it. Could be a bug in the API, could be a documentation problem with the API, could be the developer used the wrong API, or used the right API in the wrong way, or got all the information he needed but just bumbled it and lost it in this specific circumstance. There's just no way to know who to blame, and I wouldn't care to take a bet either way.
But really... a user interface bug in a calculator app makes front page news on slashdot? Must be a slow news day?
I work for the Department of Redundancy Department.
How does this happen?
It explains how it happened in the summary...
I think the "this" refers to "shipping an obviously untested product."
Part of the problem is that we (collectively) just don't get how complex software is. Sure, a good software engineer who sits down and thinks through the implications of a change will do so, but in the modern rush to market that's a rare happening. In this case, I'm guessing something like the following happened:
That said, much as we (software engineers) don't like it, there's something to be said for shipping quickly and, sometimes, before things are ready. Users reward this behavior, and shipping quickly can mean the difference between a product or company that succeeds vs. one that fails. The saying is "you can't shine shit," but I've seen countless examples otherwise (and the Mythbusters disproved this in, well, a literal sense). I hate it; despite it, in fact. Push back against it. But it's hard to argue when there's a throng of consumers ready to spend their money on it.
So, we're relegated to having to be judicious in what we push back against. Is it safety critical? Will someone get maimed or killed by this? If it's running on an iPhone, the answer is probably no. For Apple here, the main result is a bit of embarrassment -- a calculator that seems to give wacky results. A civil engineer using this for estimating should see this kind of issue immediately (and is unlikely to use the iOS calculator for final documents). Someone trying to split their restaurant bill, maybe not, it's an acceptable risk. The Excel 2007 multiplication bug was probably more serious because that's an application that is more likely to be used in civil engineering. If you're writing software that could lethally irradiate someone and encounter shady practices, immediately raise flags and alert everyone who will listen.
Ok, so we're not going to manually test everything on a smart phone before a new OS is released. What can we do? Push for more automation. Making aesthetic judgements automatically might still be a bit difficult, but we ought to be able to simulate key misregistrations. A quick check would be to do this in software to see the effect of a change while you're hacking away on your laptop, but a robot providing millions of taps and swipes on actual hardware would be even more insightful. This would be daunting for most startups trying to make the next Zynbookwitter on shoestring VC funding, but child's play for the likes of Apple or Google.
Of course it's a bug, but how do you not see it within the first five minutes of testing? When I saw this earlier I thought the claim must be ridiculous, but it's actually more difficult to avoid this problem than it is to demonstrate it. I like my Apple stuff and I get a new iPhone every year, but iOS 11 and Mac OS High Sierra are rife with small disappointments and annoyances like this.
This is similar in a way to the bug behind the famous Therac-25 incident. The Therac-25 as a medical radiation machine which had software which was supposed to prevent patients receiving dangerous doses of radiation. However it turned out the operators entered configuration command far faster than testers did, creating a race condition that could result in the machine delivering over 100x the safe dosage.
The bug never showed up in testing because the testers never got as fast at input as the operators, and in any case the specific keystroke combination that caused it was rare.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
It may take a few lawsuits to get back to an interface which actually works while driving without requiring the user to take their eyes off the road.
Since we had a well proven system for decades and the replacement is defective by design because it's unsafe, hopefully it won't take a few juries long to award big bucks in a few high profile cases to get manufacturers to fix the error of their ways.
Normally, I'm not particularly plaintiff friendly in product liability lawsuits, but in this case the manufacturer better show me if I'm on the jury that their design decision SAVED more lives than it cost and that they could not have reasonably achieved the same life saving feature without costing (fewer) other lives. That's a pretty high bar to clear!
I actually drive an older car now and one reason is just this -- I looked at replacing it and found the UIs to basic functions in too many midrange cars to be unsafe.