Firstly, I’m a Chrome user. In nearly every facet of my browsing habits, Chrome wins. But there are some smart people out there developing for other platforms and web browsers, and I’m completely alright with that, and with the people that choose to use them.

Opera is a pretty nice browser.  It doesn’t get much attention for just how good it really is, especially when compared to other random open source browsers that aren’t worth the disk space they use up.

Microsoft had a policy they spoke about when first demonstrating IE9: Same Markup.  The concept was that the same HTML, the same CSS, and the same Javascript should look the same in all browsers and on all platforms (nothing radical there).  They used that point to defend their continued support of their own rendering engines, as opposed to just switching IE to use Mozilla’s engine or Webkit.  If Microsoft was interested in making their pages render the same, why not just use the other engines?  (Typical open source mindset, by the way.  Open source junkies seem to generally abhor the thought that somebody make something on their own.)  Microsoft has the right to try their hand at their own engine, especially since they want to integrate hardware acceleration on their platform.  As long as it comes out looking alright, I’m fine with that.

Opera’s got a similar problem.  They use their own engines and, just like in IE, there are rendering differences at times.  For little stuff, it’s no big deal, but web developers have historically tried to sniff out Opera or IE (implicitly or explicitly) and disable access to their site on the grounds that something bad *might* happen.  Sometimes just having Opera report a different useragent string granted access.

So while developing a new site this week on my local webserver, Opera has this weird kink that won’t actually run the Javascript I wrote for some dynamic content.  While browsing around in Opera’s Dragonfly debugger/DOM inspector, I noticed a “Browser JS” entry, and examined it, surprised to see a “this belongs to Opera” comment at the top of the file.  It’s a file that silently patches a page’s javascript to operate the way Opera thinks it should operate.

At first I thought it was fairly harmless, but was curious how to disable the feature, to make sure that wasn’t the reason my local site was breaking down.  I found Opera’s page describing the feature and was completely shocked at how many pages get patched:  Many of the fixes try to remove browser sniffing against Opera, but many many more are arbitrary scripting hacks that make Opera’s engine appear to work better than it really does, including issues around layout.

Among the hacked sites are even Google’s various services, Yahoo, and many others.

On a fundamental level, this is not how to address defects in your browser.  If they aren’t following standards, fix the engines, not the sites.

Very rarely do I feel the need to boycott something based on a principle of belief, but BrowserJS pads the central issue of having a sub-par browser engine and encourages people to use that (secretly sub-par) product.  Further, it dissuades the Opera developers from fixing their core engine.  Actual progress is slowed.

To disable the magical feature, visit the configuration page in Opera: opera:config#Browser%20JavaScript and set the value to “0” instead of “2”.

Tagged with:

10 Responses to Why You Should Disable Opera’s BrowserJS

  1. Hi Tim,
    I’m one of the handful of people who maintain and contribute to browser.js.

    You raise some valid issues and interesting points. Let me address some of them..

    Firstly, let’s distinguish between site patches that are required because the site misbehaves, and “core” patches. We’ve just shipped a number of patches rewriting Amazon sites, because Amazon uses backend browser sniffing heavily and simply doesn’t send Opera all the required JavaScript. If we didn’t have the odd duct tape feature that is browser.js, we’d be unable to do anything but keep begging and waiting for Amazon’s fix.

    This is but one example of a negative spiral which Opera has always struggled with: sites don’t test in Opera because of low usage share, users stop using Opera because sites don’t work, usage share drops even lower, even fewer sites are concerned about Opera etc. The main tool we have to break the cycle is browser.js.

    Regarding patches for core Opera bugs, you state dissuades the Opera developers from fixing their core engine. Actual progress is slowed.

    Well, there is a reason why browser.js is maintained by the Opera quality assurance department. I can tell you that one of our worries from day 1 was that browser.js might become an excuse for not fixing core issues. So, we make absolutely sure that whenever we work around an Opera bug, there is a good and highly prioritised bug report about the issue for the core developers to work on.

    This process is actually working great. If you read through some posts on the Opera sitepatching blog, you’ll see that patches are constantly being removed due to core fixes. As a result, the number of lines in browser.js actually follows a nice downward trend through various Opera upgrades. And no developer yet tried to argue “it’s patched, so let’s lower the priority” – because that just won’t persuade QA ;-) If there is any effect, it’s more likely to be the opposite – we need to do some pretty thorough analysis for site patching, so those core bugs might be better understood and get fixed faster..

    Also, our worst compat problems are sometimes workarounds against our older bugs. If we can work around them ourselves rather than burden webmasters, we’ll have less legacy code to worry about in the future. That’s a win-win situation to me :)

    Finally, the world is not black and white. Sometimes I can’t really tell myself if the problem is more the site’s fault or ours.. Consider the site patch enabling the Flash uploaded in Google Docs, which went into browser.js yesterday or so. On mousedown, Docs moves the Flash OBJECT tag to another location on the page – in Opera, that means the plugin doesn’t detect the mousedown, not unlikely because we repaint so quickly that the plugin’s event handling area is painted somewhere else immediately..? Is that really our fault for having a “sub-par browser engine”, or is repainting the page quickly on DOM and layout changes a strength for a web browser? What about the NRG issue the second half of this post describes? I’d love to hear your thoughts about better ways than browser.js to resolve compatibility problems that are caused by Opera’s strengths and selling points..

    • Tim says:

      Thanks for this reply. Discussion is a healthy practice :)

      First I should make sure it’s clear that because I was a longtime Opera user in the past, (1) I recognize the extremely difficult catch-22 situation Opera is in, and (2) something obviously needs to actively be done to fix the problem.

      The objection to browser.js is one I make on principle, which is something I don’t quickly or frequently do. The reality is that it solves the problem with about as much grace as is possible to give its users and development team. It should be noted that I don’t think an appropriate response from someone like me would be to petition the Opera team to remove the JS patcher– I only argue for users to disable it and to eat their own dog food. Those unaware of the patcher are left out of this discussion because they don’t know/care one way or another, taking it for granted that the browser works great.

      Your points are well-founded and accurate, and really, what else can be done to fix the stated problems other than browser.js?

      My problem is that, as a web developer, it’s my job to be a control freak with my code, and there’s something unsettling about a JIT patcher potentially trying to fix problems that don’t exist. Obviously the explicit patches to certain sites present no risk, but it worries the developer in me to think that this thing makes an unspecified number of changes to code, and there’s nothing but a global kill-switch to control it.

      The saving grace in my eyes is that the script makes notes to the console when things get changed. This is exactly the right thing to do. And I take it as a sign of goodwill that (as noted on the official Browser JavaScript page) Opera respects the decision of the user.

      Ultimately browser.js just makes me squirm a little, and the number of sites listed in its hitlist are so numerous and prolific that I find it hard to believe that we’re talking about only a few old Opera bugs. If every site on the Internet needs a patch, the effort will utterly fail in the bigger picture. I will admit that I’m not familiar with Opera development patterns, but I would urge these things to be fixed in frequent development sprints.

      As much as this might make any of us cringe, IE faced this same high-level issue, and decided that the compatibility button was their best option. Sooner or later the next version of Opera should just be a clean break, and everything should be fixed up in a sweeping victory for Opera users and devs! It would obviously have to be a major milestone release.

      • it worries the developer in me to think that this thing makes an unspecified number of changes to code, and there’s nothing but a global kill-switch to control it.

        Indeed, and you’re of course absolutely right that the inconsistency browser.js can cause risks giving web developers headaches. Some of the specific patches make me squirm too – and I sure felt sorry for the very confused webdeveloper who once contacted us to ask why the #%#¤¤%¤ Opera would change navigator.userAgent if he included an external JavaScript called menu.js. Mea maxima culpa, Sir.. :(

        Unfortunately those are also the most effective patches – handling the popular “menu.js” library and other file names we target on thousands of websites. We’re still sometimes seeing bug reports about menus not working because those old scripts are used somewhere with a different file name.. so it doesn’t seem safe to believe that these have now faded away and we can stop working around them. :(

  2. (Sorry, one typo in previous comment:

    enabling the Flash uploaded in Google Docs

    should say “Flash uploader”.)

  3. Grey says:

    My problem is that, as a web developer, it’s my job to be a control freak with my code, and there’s something unsettling about a JIT patcher potentially trying to fix problems that don’t exist.

    You’re wrong. As a web developer, you have to be a control freak with your backend code. The frontend belongs to the users, anyway. The moment it reaches my computer, your website is mine. I can use UserCSS and UserJS (stylish and greasemonkey in FF) to completely change your site however I want to. You wouldn’t want to argue in favor of those who think users shouldn’t be allowed to right-click on their websites, right? My browser, my rules.

    And Opera has that same right, as long as they only do it to make your site more accessible for their users. If it causes you problems, I know they’re very responsive. I subscribe to the site-patching blog and I see how great the turnover for patches is. Maybe you should do the same; get a little more perspective on the matter. Hallvord’s blog deals with the same subject matter, and is also a much more interesting read.

    • Tim says:

      I’m not going to say that you’re wrong, but please be careful not to think that my commentary is unfounded and off the core topic, or that I’m not familiar with how all of this works. I’m working hard to be respectful and to have an interesting discussion. My opinions need not make us enemies, as if this is a blood feud.

      I indeed design and control the initial starting point for the frontend. By default a website does nothing at all; a blank HTML file doesn’t help anybody. No amount of UserCSS/JS makes a blank HTML file work magic just because it came from a popular website. So I design the frontend, and then turn it over to the users when they visit. The contract I make with them is that “this works”, and it’s no longer my problem if they go and break it somehow.

      With UserCSS, things could get messed up, but CSS is presentational in nature. UserJS serves an entirely different purpose. Javascript is functional, and UserJS of any kind is a different thing. I’m not saying that UserJS shouldn’t exist. Effectively there is a large market for browser extensions that are basically user-friendly JS hacks, like the RSS badge that floats over any page you visit, or the LastPass extensions. I’m not going to pretend like the user doesn’t have the right to modify the page I give them, but then that’s out of my hands, outside of the terms of the contract I made withthem. And that’s the control freak part. My job is to deliver something to your useragent that works. The problem that Opera is facing is that some web developers make assumptions about certain useragents, nebulously thinking that the Opera useragent can’t handle their site. This is a mistake, but this means that those specific developers (who are frequently just contracted thugs that carry these dirty assumptions with them from job to job) aren’t doing their job and aren’t being good citizens in the web development space, or at least aren’t giving due diligence.

      I believe that we see a trend for developers to detect browser characteristics, instead of the browser’s vender name. The jQuery library has long since deprecated their old browser identification code and replaced it with a module that can detect specific browser features, like a modern box model, or support for various types of JS or the like. This is the correct answer for developers. Make no assumptions about the web browser, because for all we know, they might visit in a weird version of Konqueror or some other non-standard browser. But if that browser can pass just a few tests about its rendering model and its JS engine, then it can run my code. If it doesn’t, I can either be a jerk and deny them access (might be a good idea if the site is something like and relies heavily on JS that has just been verified not to work), or I can at least give them a warning, or even a simplified version of the site (like did for its plain HTML version).

      And I recognize that training every developer in the world to be smarter isn’t practical, despite it being the right thing to do. So I understand browser.js needs to exist to combat these unfortunate circumstances. I dislike the circumstances more than the browser.js hack itself. And that is why I choose to fight this problem by teaching up and coming web developers how to code websites with grace, ones that degrade gracefully when things go wrong.

      I’m doing my part as best I can. Any developer or maintainer of Opera or browser.js is also doing their part. We want the same goal, and what we need is to work the problem from both sides so that it becomes a non-issue as soon as possible.

  4. Relgorka Shantilla says:

    Soooo….did browser.js have ANYTHING to do with your scripting issues? Or was it a red herring for some edge-case bug in Core that needs to be reported at so that everyone may well be rid of it for good?

    I do recall that the newest 12.x build tentatively claims 100% support for known cases of ES5.1-compliant scripting, and the upcoming Ragnarok parser hopes to achieve 100% HTML5 heirarchy compliance before it debuts in OperaNext; if OperaNext behaves better than stable Opera, then your problems may be gone very soon.

    One neat little gimmick: “Opera->Help->Report a site problem…” It’s even better when a developer files one of these cases, and if the bug lies with Opera they can put a fix into the queue. Some bugfixes were years in the making, and a few planned improvements may not land in the next six months because they require a major shift in the architecture. To my knowledge, both Chrome and (shudder) Firefox also have active site-specific fixes in their bug trackers; however the fixes are often pushed in a version update. But in Opera, these minor glitches can be fixed with just a few K of text, and fixes may be altered or rolled back without *yet another* 15MB download. This difference in methodology was also covered on the blog when they explained why DigiNotar could be blocked with a few checkboxes in their server-side trust manager.

    • Tim says:

      In the end, browser.js did not have any impact on the problem I was facing. I actually haven’t yet figured out what the problem has been on that page, because it was such a time consuming exercise.

      • Interesting. If you E-mail me a link or description (with some source code) I’d love to try to figure out what’s wrong :)

        • Tim says:

          Thanks for your interest. I’ll email the page to you sometime soon. There are some errors from the Twitter API usage that are polluting the console, which I’d like to clean up so as to remove any doubts about browser compatibility! This current issue is new and separate from the Opera issue I was having, I just want to nicely take care of this before I start crossing wires.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>