Skip to main content

Tragedy of the WebKit Commons

With Opera announcing that their future products will be based on WebKit, the Internet is abuzz with discussion about what that means and whether it's a good thing. Looking at it as a jQuery developer, it's a good thing if it gets WebKit participants to fix bugs and update older implementations. I can't be optimistic without some evidence that things are really going to change.

We don't know how many of Opera's core developers will move to WebKit development, but the press release isn't encouraging: "The shift to WebKit means more of our resources can be dedicated to developing new features and the user-friendly solutions." I suspect they want some cost savings by eliminating Presto technical staff, or -- in the most optimistic case for their employees -- refocusing existing staff on the parts outside WebKit core that make browsers different.

Opera did land their first WebKit patch so they wanted to make a statement that they weren't getting out of core browser development altogether. Then again, the age of that bug just underscores one of the problems with WebKit. It took five and a half years to make a half-line fix! Now as a first commit it's a great one for the Opera team, since it lets them get the feel of the system and of course they had to write a few more lines of unit tests. But five years? Why so long to fix a trivial bug? Because fixing bugs doesn't make news.

Each release of Chrome or Safari generates excitement about new bleeding-edge features; nobody seems to worry about the stuff that's already (still!) broken. jQuery Core has more lines of fixes and patches for WebKit than any other browser. In general these are not recent regressions, but long-standing problems that have yet to be addressed. Opera probably doesn't have any more incentive to fix the common bugs than any of the other diners at the WebKit table -- especially when jQuery continues to cover up these mistakes. Instead, Opera will want to focus on their own bleeding-edge unique features, all while people complain about jQuery's "bloat".

When we started our jQuery 2.0 cleanup to remove IE 6/7/8 hacks, we were optimistic that we would also be able to remove some bloat from lingering patches needed for really old browsers like Safari 2. But several of those WebKit hacks still remain. Even when they have been fixed in the latest Chrome or Safari, older WebKit implementations like PhantomJS and UIWebView still don't have the fix. We've had to put back several of these as users reported problems with the beta. It's starting to feel like oldIE all over again, but with a different set of excuses for why nothing can be fixed.




Comments

But five years? Why so long to fix a trivial bug? Because fixing bugs doesn't make news.

No, because it was a corner case bug that didn't affect anybody much, and the specs weren't clear even if it was a bug in the first place.

Maybe try reading the discussion under the bug fix on the tracker page.
Anonymous said…
It is open-source software, so why did you wait five years until the bug was fixed?
Anonymous said…
Well-Written post.
Antoine Aubry said…
No offense, but maybe the time that was spent adding workarounds to jQuery for bugs in WebKit would have been better spent fixing those bugs. Now I understand that jQuery's goal is to provide a working solution *today* and not sometime in the distant future when some patch gets merged and becomes widely used. In the long run, however, fixing the actual bug would provide more value.
Maxim Khailo said…
If you are going to reference "Tragedy of the Commons", do it correctly by pointing out what a horribly simpleminded fantasy the whole fiction is.

The original paper by Garrett Hardin simply explored the idea. He did not use real data and it was not scientific in any way. It was a thought experiment. And generally proven wrong.

Why it it relevant to mention this? Because the article mentioned here about Webkit references it in some attempt to connect it to the idea that Open Source or Free Software is an example of Garrett's argument.

However, if anything, WebKit is a counter example in an interesting way. One typical example of given to TOC is global fishing. However, if anything, global fishing is an example of large corporations exploiting a resource owned by nobody (vs a resourced owned in common). In a similar fashion, WebKit might be an example of corporations exploiting code owned by nobody.

Incidentally, this is not the case for many Free Software projects (vs Open Source). Because Free Software projects ARE owned by a group of people in common. And typically the governing structure is less exploitative, and more cooperative than corporate controlled projects like WebKit.

Peter Kasting said…
I'm a Chromium developer. It's not clear from your blog post: are the majority of the bugs you're complaining about things that are still broken on the WebKit trunk? Or things that you have to hack around because of the number of out-of-date WebKit-based UAs? If the former, are there bugs on file at bugs.webkit.org?

I ask this because we spend a lot of time fixing bugs in each release, and if there are major problems we're missing, then I'd like to ensure they get triaged and investigated properly. But the complaint you write here isn't really actionable, because it's short on details.

Feel free to ping me directly -- pkasting@google.com -- and I will try to ensure someone takes a look at your issues.
Anonymous said…
Maybe we need a less-exciting ACID test. A test of useful but inconsistent functionality.

Personally I wish canvas mouse location handling was done more consistently.

But watch out, the last ACID test focused on functionality that was controversial, or less than important. Mozilla was right not to prioritize their effect to solving the acid test. They had their own tests.

Furthermore webkit pisses me off because webdevs think they aim for 1 platform. You can't. Please recognize the web is defined by standards, please adhere to them, and please respect your users. They don't use chromium, they don't use opera, they don't use safari, they don't use firefox, they don't use IE.
Unknown said…
As a long time web dev I've always been annoyed that all browser developers seem work on the sexy new tech and the mundane boring stuff I actually need to get my webapps done I have to lean on jQuery heavily for stuff that should be in the browser by now. Just look at HTML5, all the browser makers are demoing advanced sexy stuff like Real Time Communications, yet try to get a simple html5 input type=date working across the browsers you'll either get nothing or a very poor implementation just to cross it off the list as supported. Back to jQuery to make some simple forms actually work....
b_i_d said…
There's one line that already invalidates most of the text: "jQuery Core has more lines of fixes and patches for WebKit than any other browser."

WebKit isn't a browser, but a rendering engine, used by countless browsers. To compare an engine and other browsers seems like a dirty trick to exaggerate the numbers.

That said: Yeah, there still are many old bugs that need to be fixed. Most of them are corner cases, which don't affect too many users. But that makes it even worse, when you are one of those affected.

But even with that being true: This article isn't worth reading, even for a rambling.
Julien Couvreur said…
Maxim, are you claiming that there is no incentive problem, no tragedy of the commons, as ownership gets more diluted?
The example of the lake is simply a case of more dilution. Doesn't the lake belong to the people of the country?
Unknown said…
My biggest concern is not the webkit bugs, but the HUGE mistake of homogenization. If everyone is using the same browser engine, we now run into the same problem when IE took 90% of the browser market.

So now we have Safari, Chrome, Opera and other small players all using webkit. This is dangerous and it means the only big player left is Firefox to keep things dynamic. I can see it now, that Microsoft decides to change the browser core to webkit (since they are heading down to 15% share) and then we can really be in webkit hell.

I will stick with Firefox and encourage other to do the same to avoid this if at all possible.
Mike said…
I've spent hundreds, maybe thousands, of hours getting things to work in IE whereas working about inconsistencies between WebKit and Gecko is rarely more than a minor change (even including mobile support).

The biggest issues in my experience are poorly defined points of the specifications and the tendency to remove features from the specs if they decide they're not being implemented fast enough. To much design by committee goes on instead of just having someone in charge.

I'll agree with other comments that to often exciting big features get all the attention while nobody works on the small things that would actually be more useful to most developers. This happens as much at the spec level as at the code level.

The other issue I've had is that developers are unwilling to change the spec to add new features, or fixes to bad specs, without getting something pushed through as the actual spec. I can understand the hesitation but it makes it difficult to advance things that might be useful or at least worth exploring.

(One example: I've several times tried suggesting an option for the password field to make it hash the username, domain name, and password together and submit this hash instead of the plaintext to the web server. Seems this would be helpful in stopping most password security issues but every response I've got has been negative. And it could end the annoying feature of most websites where they require some idiot specific combinations of characters required. You could even have a single password used everywhere in that case as it'd be salted before submission.)
Unknown said…
Supporting client-side password hashingis a great idea, but has a few problems.

First, of course it doesn't prevent replay attacks on the same site if someone intercepts network packets.

Second, site names may not be fixed. A site might rebrand or be accessible under more than one domain name, or a login might work across different sites (aol.com/aim.com, hotmail.com/live.com/msn.com, google.com/gmail.com, etc.) So the sites need to help by providing the authoritative, constant site name to use, otherwise this would need to be omitted for salting purposes, which makes the username/pw combo no longer unique across sites (as many users reuse both their username and password).

Third, users may log in from different devices, all of which would need to support this standard, and use the same exact hashing function. Until virtually all browsers support it, it really can't be used at all.

It would be a great idea for individual sites to implement in javascript, but that might be asking a lot, as so many don't even get the basics right (storing passwords in plaintext, not using ssl, etc.)

Popular posts from this blog

Please Stop the jsPerf.com Abuse!

According to many of the tests on jsperf.com , jQuery is slow. Really slow. The jQuery team gets bug reports from web citizens who've discovered these egregious flaws via jsperf and want them fixed. Now, jsperf.com can be a great tool when used knowledgeably, but its results can also be misinterpreted and abused. For example: Why doesn't jQuery use DOM classList for methods like .addClass()? There are at least three good reasons. It doesn't make any practical performance difference given its frequency of use. It complicates code paths, since classList isn't supported everywhere. It makes jQuery bigger, which makes it load slower for everyone, every time. But this jsperf shows classList is much faster! How can you say that? Well it's possible that test is running afoul of microbenchmark issues , and not measuring what it is supposed to measure due to the increased sophistication of today's JavaScript compilers. This is a big problem with a lot of t

You Might Not Need Babel

Babel is great, and by all means use it if it makes it easier to develop your application. If you're developing a library on the other hand, please take a moment to consider whether you actually need Babel. Maybe you can write a few more lines of utility code and forego the need to pre-process. If you're only targeting some platforms, you may not need anything more than plain old ES6. At the very least, make sure you know what Babel is doing for you, and what it's not. Some developers believe that Babel is protecting us from a great demon of code complexity when, in truth, browsers and node are pretty easy to deal with on their own. Let's take a look at some of the strategies for not needing Babel. ES5 is pretty okay: In the days when we used tables for layout and the debugger was named alert() , we would have been so grateful if JavaScript had the features that ES5 has today. If you truly need Babel you are not only a weak programmer, but also an ingrate. Face