Slashdot Mirror
Apple Releases iOS 9.3.1 With Fix For Unresponsive Links
An anonymous reader writes: Apple, on Thursday, rolled out a minor update to iPhone, iPad, and iPod devices. The update, dubbed iOS 9.3.1, brings with it a fix for a software glitch that caused many apps -- including Safari, and Chrome -- to freeze and crash when trying to open a link. The issue was related to Universal Link, a feature Apple first introduced with iOS 9. Many reported that some apps including Booking.com were abusing this capability, causing the Universal Link database to overload.
crashing.YEAH!
How could they take so long?!?
is the "link" Safari will generate for something that looks like a phone number. It took me forever to figure out that it wasn't some bug where it was treating a real html link as a phone number, but that it was creating its own 'call button' for any unlinked series of digits that looked like a US phone number. It was only by the third incidence or so of going to a non-Apple device to look at the page that I finally realized the page provider wasn't offering any further information.
Stupid, I know, but I blew at least an hour of my life on that.
Their QA department somehow missed that iOS 9.3 made it so that links broke in the mobile browser.
How do you miss that? How shoddy do your testing practices have to be to miss that you've broken LINKS?!
I don't recall the last time Android broke something so fundamental to the smart phone experience. Remember when Apple's plan was that all apps on iOS were going to be webapps? And they can't even take to the time to see if LINKS still work?!!
So, yeah, I'd say Apple fully deserves mocking in this instance.
"some apps including Booking.com were abusing this capability,". So yeah.
Perl Programmer for hire
No, links were not broken. Certain apps broke it by being stupid about how it does things.
What happens is some apps allow deep linking - so you can browse in Safari and then have a link open in an app. Perhaps you're shopping on Amazon and if you have the Amazon app, it will allow you to view the link in the Amazon app instead of just opening the page. The deep link will tell the Amazon app to not show its normal front page, but to go directly what the user was looking at. So if you did a search for an item, it would open with the search results.
The problem was, you're supposed to list the URLs you allow, using wildcards if necessary. Some apps, like Booking.com, instead enumerated EVERY link on their website and told the OS to use that, rather than wildcard linking. So the file they presented to the OS was around 2.8MB of URLs.
The problem is when the OS URL handler started looking through, well, it was not supposed to be presented with lists of thousands of URLs, which caused it to crash.
So yeah, the links worked, just some apps broke it. So of course it would pass QA because it was only stupidly coded apps that broke. The affected apps have been removed.
Their QA department somehow missed that iOS 9.3 made it so that links broke in the mobile browser.
The reason it didn't get caught was that only a very few websites try to cram multi-MEGABYTES of "related-links" data down a browser's throat when the user simply clicked on a single link.
So, howabout you share some of that copious hatred for the stupid-ass web developer that thought it was ok to send every URL on the interwebs (yes, I know that's much more than a few MB) to your browser just because the user clicked on a single link.
The reason it didn't get caught was that only a very few websites try to cram multi-MEGABYTES of "related-links" data down a browser's throat when the user simply clicked on a single link.
I've never run into this bug, myself. Having said that - someone, somewhere in the QA chain, really should've been thinking about edge cases.
Operating under the expectation that everyone will play nicely with your services is what led to stuff like Heartbleed.
#DeleteChrome
Wait, you're saying a WEBSITE is capable of breaking LINKS in the browser, simply by having the user visit it?!
That's EVEN MORE DAMNING to Apple than just some rogue app breaking things!
You don't do QA, do you? One of the first things any QA guy worth their salt does when generating tests is generate a purposely large dataset to ensure that nothing breaks if some idiot tries to store the Library of Congress into any input the program accepts. What happens if I decide my iCloud password is the entire text of War and Peace? Do text messages break?
There should be a limit to the amount of data allowed, and if that limit is exceeded, then the program should handle the error gracefully.
Not break links in everything that can process them.
So, again - what the hell is wrong with Apple's QA department that they missed this?!!
Only specific apps. I have been using iOS 9.3 on both iPhone and iPad since the day of release and have had no issues whatsoever. Their testing can't account for every possible combination of apps that people have installed, I guess.
"So of course it would pass QA because it was only stupidly coded apps that broke."
Assuming well-formed input from a source you do not control is at minimum QA failure, and potentially a security risk.
Any other app could still create a unexpectedly large list of allowed URLs, then you'd have the same problem over and over again.
While they could add a check in App Review to look at the size of hr URL list, it would also be prudent to also update the OS to better handle unexpected input.