miscoded

Understanding other people's workarounds can be simply impossible. Take this example from the popular creative forum deviantART: if a member tries submitting a new entry from Opera, it will appear impossible to upload files because the "Choose" button does nothing when clicked. (Tabbing to it and pressing enter will work, but who'd think of that..)

The reason is buried deep inside this JS file:

if (window.browser && (browser.isGecko || browser.isOpera)) {
     uploadForm.onmousedown = function () { return false; }; // firefox only - screws up other browsers
}

So this "Firefox only" workaround against an unspecified problem I can't begin to understand is also applied to Opera - with the fatal result that we ignore any mouse clicks inside the upload form because the script cancels mousedown. I'm not sure who's deviating from what here..

(As an aside, code like this makes me pretty curious - what will show up in the site if I throw in a small user JS to set deviantART.pageData.i_am_super_privileged to true?

// most awesome hack ever
if (!path[1] && whoosh[0] == 'Fan Art' && deviantART.pageData && deviantART.pageData.i_am_super_privileged)

source)

Back then when we added the browser.js feature I heard some sceptical voices saying that fixing broken sites automatically was a bad idea because then the site had no incentive for fixing it themselves. The risk was that the web might become even more fragmented, with even worse examples of incompatible code because Opera would automagically fix things and cloak the faults of the webmasters.

Now call me an optimist, but we have about half a year's experience with browser.js and I'm seeing evidence of the opposite. Three good examples are allmusic.com, shockwave.com and atomfilms.com - they all had long-standing issues with Opera, they were patched successfully with browser.js and a few months after the patch, each site was fixed by the webmaster!

So perhaps, perhaps site patching does exactly what we hoped: increases Opera's ranking in site statistics by making previously unusable sites available to Opera users, thereby making webmasters more concerned about Opera compatibility (because such decisions are often based on browser stats) and eventually creating a more compatible web.

Of course it also helps that we always contact the website before or while we patch it.

It is no accident that browser.js is a simple text file written in readable and reasonably well commented JavaScript and that it always outputs some text in the JavaScript console when it does something. We could have done things differently, we considered pre-compiling the script somehow for performance - but in the end, it was most important to keep the whole feature as open for inspection as possible. And that pays off: we hear from web developers who sit down and read through the section of browser.js that is used on their website, for to-the-point, updated information about where in their site there are problems and scope for improvements. Thus browser.js itself becomes a way of communicating directly to the web developers we need to reach!

Hey, some of the fixes in browser.js can even be cut and pasted into the site to solve the problem

Yes, I think site patching works - and every patch I can remove from browser.js is a vote for that conclusion.

I have a picture of thousand words, it speaks volumes about the unjust web.

Watch the animated comparison between the code Opera gets from Yahoo Mail and the code IE gets. See the full dinner of HTML and JavaScript that is sent to IE versus the meagre crumbs and tap water they serve Opera. Yahooooo for blatant browser discrimination!

Coming soon to a screen near you!

New software drama, Standards compliance victim, starring:

• The browser who got it right
• The Spec
• The browser who got it wrong
• The site that got it totally wrong but thinks everything is ok

Question of the day is: why does the "news slideshow" on AOL's front page run ten times too fast in Opera?

Because FireFox's implementation of DOM2Events has serious shortcomings, as I've mentioned earlier. AOL.com is the latest and most high-profile site that has run into this problem so far.

On AOL's main page the small "slideshow" runs much faster than it is supposed to, the "play/pause/next" buttons do not work, you get strange alerts about content not being available, and the whole page makes Opera use a lot of CPU resources. This is all because they use a capturing "load" event listener when they meant to use a non-capturing one.

It works in FireFox because it does not support capturing event listeners. It fails in Opera because we follow the spec.

I've written a couple of pages to show the difference. Try these in FireFox and Opera:

• FireFox doesn't get it 1: capturing listeners should not fire on target
• FireFox doesn't get it 2: loading progress bar demo

Since I have written the test cases, could someone do me a favour and make sure there is a Bugzilla report on the second issue? I know bug 235441 covers the former.