Sounds like jQuery could benefit from committing their own fixes to WebKit rather than working around them. If the bug Opera fixed really was just one line then why did they have to wait for Opera to do it?
2. Even if it were to make it into a shipping browser quickly, there is no guarantee any reasonable amount of people will run that upgrade anytime soon.
Hitting browser bugs really sucks for this reason. The bug has to be worked around no matter what, since there will probably be people running that bug for a long time (this has gotten much better with things like Chrome's auto-update which is why if you talk to people from that team they are such big believers in it). Regardless, you have to remember that the jquery team is providing a product to clients. If a client's site is broken because jquery hits a bug in a browser, the priority is to have that site work asap. Its unacceptable to say "Oh we fixed the bug in webkit, Safari users will see it whenever the new Safari ships which we have no idea when that is since its an apple secret. Bug closed." The best response is "Fixed in new jquery version whatever, just update the script on your site". And once you've fixed the bug for your own concerns, it just doesn't make sense to then spend time fixing it in WebKit as well vs. spending those resources on fixing another jquery bug.
I mean, I could argue that people shouldn't work around iOS bugs and should instead apply for jobs at Apple and fix UIKit itself so that everyone can best benefit from their labor. But that's absolutely absurd. It's also more than a little unfair to judge members of the jquery team for not going into a project like WebKit that's millions of lines of C++ and acting like they're coming up with excuses for "not fixing bugs". This is a symbiotic and healthy relationship, browser vendors benefit from groups like jquery that make those bugs livable today through workarounds so that their products can be more usable in the immediate and they can focus on the "real" fixes for the future.
And don't forget that there are people who are running old OSes that would require buying a new computer before being able to upgrade their browser.
EDIT: I misread the article on how the bug was actually handled, and that it was fixed five years after it was reported, not that it took five years to apply the patch. However, it still is easier for the library maintainers to use a workaround than to patch the browser itself, especially when legacy versions still need to be supported.
What are you talking about?
Comment #5 From Morten Stenshorne 2013-02-13 00:01:06 PST Created an attachment (id=188026)
12 hours and 12 minutes later:
Comment #11 From WebKit Review Bot 2013-02-13 12:13:22 PST Clearing flags on attachment: 188026
Also, if there is a long delay in the pipeline, that is no justification for even more delay in putting something into it, just like things being put into it quickly would be no justification for not trying to shorten that delay.
If you don't fix any bugs, but Apple etc. update overnight everything via WiFi or Ninjas, jQuery will still keep accumulating fixes for old bugs and explode - on the other hand, if you fix bugs quickly, even a 3 year delay with vendors means that jQuery will "only" have to carry fixes for bugs of the last 4-5 years, not for bugs that existed since the dawn of time.
I think that is not even the job of jQuery, anyway; it fixes bugs that have to do with using jQuery and plugins, providing a consistent baseline despite browser bugs.
http://bugs.jquery.com/ticket/11663 http://bugs.jquery.com/ticket/12986 http://bugs.jquery.com/ticket/12968 http://bugs.jquery.com/ticket/12964 http://bugs.jquery.com/ticket/10509 http://bugs.jquery.com/ticket/12577