Apple Releases iOS 9.3.1 With Fix For Unresponsive Links 36
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.
booking.com (Score:1)
crashing.YEAH!
Found a bug and fixed it. (Score:1, Troll)
Oh wait, The Linux/Android Zealots and Microsoft apologists want to make fun of those pompous Apple Fanboys.
Never mind why 2 or 3 time a week when I do an apt-get upgrade there are new patches to apply. Because that is Linux and we get fixes to problems.
Re: (Score:2, Insightful)
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.
Re: (Score:2)
Re:Found a bug and fixed it. (Score:5, Informative)
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.
Re: (Score:1)
If it was just one app that broke it, one not just remove the app? Why does iOS need to be updated to fix the behavior of a buggy app? Isn't the App Store supposed to be curated, blocking misbehaving apps from ever making it to a user's phone?
Your answer still means Apple is incredibly bad at software QA.
Because, you frickin' nitwit, it wasn't an issue until Apple added the "Universal Links" feature to iOS.
.booking.com) WEBSITE's behavior that who's behavior is outside all reason. And Apple has no control over that. So they had no choice but to patch the OS to handle the ridiculous data-flooding.
So, do you want Apple to now do a code-review of every possible App ALREADY IN THE STORE to see if it is abusive in this manner?
And besides, I don't think it was the APP's fault anyway; it is the (e.g
Re: (Score:1)
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
Re: (Score:2)
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.
Re: (Score:2)
"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.
Re: (Score:2, Interesting)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Finally! (Score:4, Funny)
How could they take so long?!?
Re: (Score:2)
Re: (Score:2)
One thing I wish they had fixed (Score:1)
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 b
Re: (Score:1)
The solution to that is obvious. Apple should create a HTML extension tag and coerce everyone into using it.
Ah, the Microsoft way of "following" standards.