[untitled]

13 comments

> Apple never actually does anything about their bugs.

Yeah, Apple never fixes bugs. Like iOS 7.0.1, 7.0.2 and the forthcoming 7.0.3, all within a couple of weeks of a major new release. Those contain no bug fixes.

Also Apple is the only company with bugs. They're really incompetent. Especially for not catching this simple form bug with 5,000 hidden fields.

potatolicious13년 전

As someone who has filed many radar bugs in the past, I don't think it's a literal claim to Apple never fixing any bugs whatsoever.

It's that they seem to be very arbitrary about which bugs they fix, they don't seem to fix a lot of what's reported, and the entire system is closed and black-boxed.

Here's the process in most sane places:

- You file the bug in a place that's visible to the public. You can link other people to it, for example. "Oh yeah, that's a bug, here's the bug report [link]"

- Developers responsible discuss the bug in said bug tracking software.

- Someone eventually marks some kind of disposition on the bug "can't replicate", "won't fix", "fixed", etc. Bonus points if they can give some rough estimate on fix availability "should be available in next week's build", for example.

here's how the Apple process works:

- You file the bug in a private bug tracker. This bug report is only visible to you (and Apple), so you can't link it. When users report bugs in forums the only solution is "I filed it already, but I can't link to you, you should file it again". In fact Apple encourages the repeated filing of the same bugs as a "vote" mechanism.

- Apple never contacts you, or anyone else, about said bug unless they specifically need help tracking it down. This is rare.

- There is no word on the disposition of the bug in any case. If it's fixed, you don't hear about it. If they're passing on the bug, you don't hear about it. If it's not-really-a-bug, you don't hear about it. The only way for you to know if your bug got fixed is to download each new release and try to repro the bug for yourself.

So sure, Apple certainly does fix bugs, but the way they handle bug reports and resolution makes them one of the worst companies to work with from a bug reporting and triage perspective.

[edit] Not to mention that fairly major bugs go unfixed for a very long time. If you have a iOS7 device give this a go: go to Calendar (yes, that first-party built-in app), create a new event. Type in a long description - one that exceeds the size of the textbox. Your text now overflows without scrolling and just disappears off the edge of the control. Oops.

This bug existed all the way from iOS7 beta 1. Naturally, something this basic was reported constantly on the forums, with the requisite multi-page bitch-fest from devs. People filed bug reports on this, but as usual there was never any feedback from Apple. So beta 2 came along and it wasn't fixed, but people kept supposing they'd fix in the next one. Then the next one. Then the next one.

And here we are, iOS 7.0.2 and it's still not fixed.

Apple isn't exactly known for being very on top of their bug-fixing game.

0x013년 전

A lot of times, bugs are "resolved" as "duplicate of IDxxxxxx". With no way to read up on the linked bug, not even the status. Duplicate wontfix? Duplicate can't reproduce? Duplicate in progress? Who knows?

phoboslab13년 전

This is the right way to get Apple to fix bugs: exaggerate and get it on HN. Worked like a charm for me[1].

[1] http://phoboslab.org/log/2012/07/what-the-fucking-fuck-apple

mistercow13년 전

Yeah, I think the translation there is "The bugs I report always seem way higher priority to me than they do to Apple."

ajanuary13년 전

The conditions of the problem would be clearer if they didn't hide the extra form elements. But then they wouldn't be able to get the punch of "a simple form breaks iOS 7!"

[deleted]13년 전

(2)

donut2d13년 전

Looking at the source, there are a ton of hidden <input type="text"> fields. At first I thought the author was saying that it was because the field was stretched to 300px wide.

[deleted]13년 전

(1)

flyosity13년 전

Yeah, I just checked that as well. Perhaps after a touch event occurs, Safari iterates across all DOM nodes with the same tag to see which DOM node's coordinates intersects with the touch's XY point?

[deleted]13년 전

Killswitch13년 전

JavaScript alerts, confirms, and prompts don't work when you add a web page to your home screen either.

brunolazzaro13년 전

Well, the bug seems NOT to be on the ammount of fields, or that they are hidden.

But that they all have the same name="" in them. Probably causing Mobile Safari to loop trough all of them (at the same time?) for some reason.

Here is the same, but without the fields hidden, and without name attributes: http://jsbin.com/EziLODur

I just tested it on ios7, on a 4S and while there was a 2-4 second lag on the initial tap, after that it worked fine on every field.

RKearney13년 전

This also causes the tab to freeze on the OS X version of Safari as well.

OS X 10.9 (13A584)

Safari 7.0 (9537.71)

jamieomatthews13년 전

This should be renamed to iOS7 Disaster! Oh and also this crashes on most modern browsers too...

lelandbatey13년 전

Odd, it works fine on my kindle web browser...

jamieomatthews13년 전

Same goes for Chrome 29.0.1547.76

jsnk13년 전

Nope, works just fine on Chrome 29.0.1547.76 for me.

RossM13년 전

"29.0.1547.76 m" works fine for me (must be the 'm'). Just takes a bit of time to load the view-source.

[deleted]13년 전

batuhanicoz13년 전

Safari 6.0.5, works without problems on my desktop, Safari 7.0 freezes on my notebook too.

hexley13년 전

Same,

OS X 10.7.5 (11G63) Safari 6.1 (7537.66)

LordIllidan13년 전

While it hanged Safari on my iOS7 iPad 4th generation, Chrome kept on working without a problem. Could it have anything to do with Nitro?

batuhanicoz13년 전

Chrome (on iOS) does not use Nitro, it uses WebView.

stygiansonic13년 전

I believe that was the point LordIllidan was trying to make; that is, because Chrome doesn't use Nitro, it remained unaffected because (possibly) the issue is within Nitro.

batuhanicoz13년 전

Stupid me was thinking "Blink" instead of "Nitro". Sorry :)

Alphasite_13년 전

Exactly.

film4213년 전

To be fair though, that form has like 5-6 thousand hidden inputs.

Pxtl13년 전

Yeah. I get that it's a problem that iOS7 safari crashes with a lot of inputs, but that's an insanely-huge number of inputs. This is kind of an edge-case and you should probably avoid doing that in your web-pages. A hundred-ish inputs per-page is probably a better idea.

Bootvis13년 전

Presenting such a form to users is probably a bad idea. I think we can agree on that, even for surveys with many conditionally visible elements.

However, a malicious site can also create such a form and simulate a tap using JavaScript to crash safari. I hope we can also agree that that is bad. So OP has a point here.

[deleted]13년 전

(1)

[deleted]13년 전

racl10113년 전

paulschreiber13년 전

If you want a bug fixed, you need to file it at bugreport.apple.com. Complaining in the forums won't get it tasked to an engineer.

mistercow13년 전

This headline is a tad misleading, although I'm sure it's unintentionally so. When I hear "kill", I tend to assume "crash". This bug just hangs for a long time, which is not the same.

The distinction is really important because a crashing bug tends to be a significant security concern, while a hanging bug, not so much.

gtmtg13년 전

Oddly enough, it seems fine within a UIWebView...

itry13년 전

Also, Bookmarklets dont work anymore in iOS7.

Samuel_Michon13년 전

I haven’t noticed anything of the sort. For instance, my Instapaper and 1Password bookmarklets work fine in Mobile Safari.

A quick search query also doesn’t turn up anyone else having problems. What exactly isn’t working for you?

frytaz13년 전

lol, this crash safari :D