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.
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?
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!"
Surely, those are divided in several steps/pages? Anything over 5 fieldsets and I’m sending it to the server first and then present a new page with the rest of the questions.
I could easily see it coming up in survey-software or massive legal forms where paging is implemented via hide/show. This is a bit of an abuse of the hide/show mechanic, but I've written abominations like that myself.
Yes, books of paper forms with over 6000 fields can happen. Especially common if you've got a lot of "only fill the one out of these 10 forms that are relevant to you" kind of layout, or cases where you're using forms in a tabular layout - 6000 fields is a 20x300 (dunno why I said 80 a moment ago) grid. Large, but not unthinkable. 300 lines of a personnel directory with 20 fields on each?
Imagine you've got a scrollable list of something and have 20 visible textbox elements in each list entry?
This kind of stuff was super-common back before AJAX. I could see supporting an internal application and having this problem, for example.
Huh, how does that work? According to my math, it would be a 20x300 grid, and every single field would have to have an input element on it. That’s pretty darn big.
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.
Right, Apple never fixes bugs and HN doesn’t understand demonstrations. People continue to disappoint, don’t they.
You found a bug. Kudos, but one of the reasons we haven’t heard about it before is because most people won’t encounter forms with thousands of inputs. It would’ve been helpful if you had filed a Radar, then the only party who can actually fix it would know about it. You chose not to. Instead, you made a misleading post to HN. And as you may well have noticed, HN readers don’t like to be tricked.
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.
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.
> 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.
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.
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?
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.
52 comments
[ 2.5 ms ] story [ 108 ms ] threadOS X 10.9 (13A584)
Safari 7.0 (9537.71)
OS X 10.7.5 (11G63) Safari 6.1 (7537.66)
Yes, books of paper forms with over 6000 fields can happen. Especially common if you've got a lot of "only fill the one out of these 10 forms that are relevant to you" kind of layout, or cases where you're using forms in a tabular layout - 6000 fields is a 20x300 (dunno why I said 80 a moment ago) grid. Large, but not unthinkable. 300 lines of a personnel directory with 20 fields on each?
Imagine you've got a scrollable list of something and have 20 visible textbox elements in each list entry?
This kind of stuff was super-common back before AJAX. I could see supporting an internal application and having this problem, for example.
Huh, how does that work? According to my math, it would be a 20x300 grid, and every single field would have to have an input element on it. That’s pretty darn big.
It would’ve been better to simply concede that it’s an edge case. Putting thousands of inputs on a form is bad web development.
You found a bug. Kudos, but one of the reasons we haven’t heard about it before is because most people won’t encounter forms with thousands of inputs. It would’ve been helpful if you had filed a Radar, then the only party who can actually fix it would know about it. You chose not to. Instead, you made a misleading post to HN. And as you may well have noticed, HN readers don’t like to be tricked.
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.
A quick search query also doesn’t turn up anyone else having problems. What exactly isn’t working for you?
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.
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.
[1] http://phoboslab.org/log/2012/07/what-the-fucking-fuck-apple
The distinction is really important because a crashing bug tends to be a significant security concern, while a hanging bug, not so much.
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.