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.
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.
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.