1. Just because a bug is fixed and accepted doesn't mean it will make it into a shipping browser anytime soon.

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.

That's perfectly realistic, but it's the same 'tragedy of the commons' that the jquery developer is bemoaning in browsers. They stand to benefit (eventually) from fixing Webkit and improving things for everyone. But in the short term, their time is better spent focussing on their own project, and hoping someone else fixes Webkit.

So, moral of the story is don't fix bugs because it might take a long time to make to the end user?

There is no moral, its just an observation of realities. From these circumstances judgement calls are made on a case by case basis. Maybe someday when all browsers have auto-update like Chrome it will absolutely make sense for everyone to focus their efforts on fixing bugs in the engine vs. writing workarounds. That is not the reality we live in today.

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.

No, it's that even after bugs are fixed in widely-used libraries, they will still exist in downstream projects and in the wild for quite some time. Given that jQuery exists to paper over implementation quirks (including upstream-fixed bugs) between real-world browsers, jQuery needs to worry these bugs long after they are fixed in the core library code.

That doesn't stop their need to work around the bugs in the existing version. It's easier for the jQuery maintainers to work around a Webkit bug than to submit a patch and hope that it gets applied in the next few years.

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.

"submit a patch and hope that it gets applied in the next few years."

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

If you read the linked post the complaint is that vendors like Apple and the developers of packages like PhantomJS regularly ship versions of WebKit that are months or years out of date. the jQuery dev team could fix every outstanding bug in WebKit and they would still have to ship compatibility hacks in jQuery for years-old builds of WebKit.

If you read the linked post the point is that if they fixed every outstanding bug via a JavaScript workaround, everybody else would have even less incentive to fix anything.

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.

I suspect that was a well-orchestrated commit to show that Opera had joined the WebKit collective. It was mentioned in Opera's press release.

That wasn't a bug that jQuery reported or has encountered. The ones we report probably aren't half a line of code to fix. And as for why we don't fix them ourselves, I can't speak for the rest of the jQuery team but one unpaid volunteer open source job is plenty for me.

Is it safe to assume that any bugs that you're running in to are being reported to the browser vendors?

The most telling thing that jQuery (or any other library) could do would be to have a policy that any browser bug workaround has to be accompanied by both a) a bug report to the browser vendor and b) a corresponding test to the relevant W3C testsuite. That would put public pressure on browser vendors to fix the issue, and provide the jQuery team with a convenient way of telling when the workaround was no longer needed.

Speaking as someone that has spent time working on a web browser, that would be a fantastic policy, both for browser developers and for web standards in general.

Sadly, from what I can tell, at least some browser vendors (and more importantly the developers working for them) don't particularly care about whether they pass W3C test suites....

Yes, we try to put a link into our tracker with the ticket in their tracker for both bugs and spec ambiguities. Note that several are a few years old and are still open.

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

There are a lot of really talented people working on jQuery, but I'm not sure how many of them have much expertise in fixing rendering engine bugs.