browser.js updates: Hotmail, Tuenti, AOL Webmail

Quick overview of browser.js updates during the last couple of weeks. …

Commenters on the article about Opera's site patching requested a browser.js changelog, so I've been thinking of a good way to do that. Here's an experimental blog post to see if such information suits a blog 🙂

Firstly, a word of warning: site patching is entirely about very small details. This isn't going to be spectacular stuff – it's mostly low-level nuts and bolts things. And it's slow. Please don't complain too much because we haven't patched the entire web yet ;), or that we've so far blatantly ignored a site or problem that is very important to you personally. I'd love to serve you all your important websites 100% compatibly wrapped up on a silver platter, but with the web being such an unruly beast this is a long-haul effort of patience and fine-tuning.

New files are likely going out tomorrow or so. So, here is a list of patches that were updated/added for desktop during the last two weeks. You will note that quite a few of these are for web sites in China and Japan – my colleagues over there had a special compatibility effort recently, testing many popular sites and analysing the problems.

  • GMail: browser blocking prevents chat feature from appearing – removed. GMail's new UI does not block Opera anymore. We've kept the patch active for a while to enable chat if people use UI=1 but I don't think it's worthwhile anymore. Yay! 😀
  • 9sky.com user registration conflicts with HTML5's "pattern" attribute – removed. 9sky.com fixed their script to avoid the conflict with HTML5. However, this shows how difficult it is for HTML and DOM development to move forward – what 9sky did was something like
    with(element){ pattern= ... }

    – since element.pattern is defined by HTML5 this script will behave completely differently in a HTML5 browser. It shows that there is a compatibility risk for every single property we add to elements.

  • Fake oncontextmenu support on Hotmail – you can now click-and-hold an E-mail to get the context menu. (This is of course a workaround against our lack of support for the oncontextmenu event – it is coming.. The oncontextmenu event is just one of the places where the "document" web and the "web applications" web conflict. One of the reasons it has taken us so long to get oncontextmenu is that resolving such conflicts isn't easy.)
  • Tuenti.com thinks images are not loaded if we don't send them a load event. Load events are only sent to visible images – not to display:none images added with innerHTML (because we don't i fact load them until they are needed). This hopefully fixes several problems with tuenti.com.
  • Asia-region Generic Patches – Ekisuupato's RosenzuASP Mapping API, Zenrin Datacom E-Map API and Netfly TrueEBook – new. This works around browser blocking inside JS libraries used on several sites in Japan.
  • Fixing TAM form element reference issue – fixes a submit button that doesn't work on tam.com.br. The site tries to look up an INPUT element with an ID by just referring to the ID – AND it tries to read a "checked" attribute from an input type=hidden. We follow IE very closely on when you can reference items by ID directly, but we changed our behaviour on reading <input type="hidden">.checked to make a submit button on tudou.com work. To put it this way: The fix in China made us run right into a script bug in Brazil. Do you still think site compatibility is easy?
  • Work around window.event getter bug – caller property is wrong for getter functions. We work around this bug to make China-pub.com's navigation menu work. Will be fixed.
  • Fix positioning after clicking map on buienradar.nl – this site breaks because we support "too many" things. We get into the "this is not IE" branch of their click handling, but since we for IE compatibility define Event.offsetX and offsetY and their mix of browser- and object-detection isn't very well implemented, they end up reading event.offsetX/Y and do calculations as if they had read Firefox's event.pageX/Y. If you take coordinates relative to an element and calculate as if you had read coordinates relative to the page, you're going to end up with very wrong results..
  • Set window.open's default URL to about:blank on rent.toyota.co.jp – fixes an error message when you try to book a car from Toyota in Japan
  • Make search suggestion dropdown work better on yandex.ru – fixes positioning and z-index issues with the search suggestion menu
  • Converting RGB to Hex confuses "high contrast mode" detection on webmail.aol.com – removes an annoying message when you load AOL's webmail. The reason is that they expect getComputedStyle() to return colour values in RGB format while ours return them in hex format. The real reason is that the getComputedStyle() specification doesn't define what's correct. Oh, how fun it is for JavaScript authors and browsers to try to be interoperable on the shaky foundation of incomplete specifications.. 😦

Let me know in the comments if posting such information about browser.js once in a while is worthwhile! Also, if there is a site you need fixed and you have some JavaScript skills, don't forget that we welcome browser.js contributions! All it takes is filing a bug report with a little writeup about the problem and a user script that will solve it.

Edit: Oops, I forgot to give credit where credit is due..the Tuenti patch was contributed by d.i.z. and originally appeared here. Thanks, d.i.z.

Advertisements

45 thoughts on “browser.js updates: Hotmail, Tuenti, AOL Webmail

  1. Nice to see what Opera is up to when it comes to site patching, might even shut a few people up.Speaking of Buienradar, how come other browsers render the rainclouds on the map with a slight transparency while Opera does not?

  2. Originally posted by hallvors:

    Zotlan: tried comparing to Firefox and Safari and I don't really notice any difference.

    I must have better eyes then ;)It's not very transparent but just enough to make spotting the cities under the clouds a bit easier.

  3. Let me know in the comments if posting such information about browser.js once in a while is worthwhile!

    Sure. I am all for more information. And although I know little bout js and stuff I love reading your posts.

  4. Thanks for the changelog hallvors! I'm always interested in the work that's going on with browser.js!I'm glad to see that support for the oncontextmenu event is coming. 😀

  5. Originally posted by Galileo:

    These fixes apply to snapshots of Opera 10 beside 9.64?

    Certainly, to the extent they are relevant. As far as I remember the Tuenti one isn't necessary for the very latest and greatest 10 builds because we've improved our "fake load events on images we won't load until we need to see them" implementation.Originally posted by Zotlan:

    I must have better eyes then

    Guess so 🙂 I'll try to remember to look at it again.

  6. @buienradarYou can see landborder through clouds in FF. The animated gif is supposed to be rendered partially transparent.span style="float:left;filter:alpha(opacity=85);-moz-opacity:.85;"We can't expect Opera to support -moz-opacity though.Error from buienradar.nl.Opera users are getting b-grade weatherinfo, hell, another rainy day in Amsterdam!

  7. Originally posted by JanGen:

    The animated gif is supposed to be rendered partially transparent.span style="float:left;filter:alpha(opacity=85);-moz-opacity:.85;"We can't expect Opera to support -moz-opacity though.

    indeed, i guess that solves the mystery, it works without the -moz- bit.I guess crap like that is to be expected of a site with inline styling.:rolleyes:

  8. Originally posted by hallvors:

    Here's an experimental blog post to see if such information suits a blog

    IT IS! :up:

  9. Thanks a lot for all the info. I just have some questions concerning some of it:Originally posted by hallvors:

    This is of course a workaround against our lack of support for the oncontextmenu event – it is coming.. The oncontextmenu event is just one of the places where the "document" web and the "web applications" web conflict. One of the reasons it has taken us so long to get oncontextmenu is that resolving such conflicts isn't easy.

    Can you elaborate on the conflicts? What's making this so difficult (and take so long)? Is it programmatically difficult or is it something else entirely different?

  10. Originally posted by remcolanting:

    It's all in the details

    Along those lines, I've noticed that you store the values at the top of the document and rarely use them:

    (function(opera){
      ...
      var hostname = location.hostname; // caching some strings for performance
      var href = location.href;
      var pathname=location.pathname;
  11. Anonymous writes:"One of the reasons it has taken us so long to get oncontextmenu is that resolving such conflicts isn't easy."How come everyone else is able to resolve them then?

  12. They didn't resolve them afaik. oncontextmenu allows the site to hijack the browsers right click menu, and Opera has never allowed that.There is a site for instance that blocks Opera because blocking right click with javascript doesn't work by default.

  13. I get an error erupting in browser.js like the following on virtually every site visited:

    JavaScript - http://[..]
    User Javascript thread
    Error:
    name: TypeError
    message: Statement on line 2097: Type mismatch (usually non-object value supplied where object required)
    stacktrace:   Line 2097 of User JS script 
        			if(self==top)postError.call(opera, 'Opera has modified the JavaScript on '+hostname+' (noscript content shows on sfc.jp). See browser.js for details');
      Line 18 of User JS script 
        (function(opera){
    

    ETA: Firstly observed using bjsversion=' Opera 10.00, Desktop, July 23, 2009 ', the previous version did not produce these errors to my knowledge.

  14. Originally posted by fearphage:

    Can you elaborate on the conflicts? What's making this so difficult (and take so long)? Is it programmatically difficult or is it something else entirely different?

    It's a combination. To put it this way: if oncontextmenu was seen as important at an earlier point in time, it would likely not be so difficult to implement it today.Handling user input (generally keys, mouse) is perhaps the main difference between a "web document" and a "web application". Most browsers originate from the "web document" age and implemented stuff to let users navigate documents – shortcut keys, right-click menus, back/forward button. As the web gradually expanded into application-ness, scripts need control of more and more user input – and each time we hand over such control it comes at a cost, making handling of user input potentially more confusing and giving the user less control, while we gain possibilities for cool web applications and effects.In Opera's transition from document browser to application platform, oncontextmenu is perhaps the last point of resistance. It's been abused for right-click blocking for so many years, and now when serious web apps have started using it and we actually want to implement it, it turns out that a lot of code has evolved around the assumption that Opera is entirely in control of the right-click and menu, and it takes quite some work to get it right.

  15. Oops. That error was indeed silly and will be fixed. (Not my patch but I do feel stupid for not noticing..) Luckily it's near the end of the file so only two patches are broken due to the error, and apart from the annoying spam in the error console it's not that severe. I'll get some new files out over the weekend..

  16. Originally posted by fearphage:

    I've noticed that you store the values at the top of the document and rarely use them

    Hostname is used by just about every site-specific patch ;)Anyway, it's a minor performance tweak to use local variables rather than looking up "location" on the crowded window object and "hostname" on the location object every time. The others are indeed less used, perhaps superfluous – but a few patches use them.

  17. (That said, the work is already done. It's just unfortunately not possible to include it in Opera 10, but once Desktop moves on to a newer core engine version it will arrive.)

  18. Oops, I forgot to give credit where credit is due..the Tuenti patch was contributed by d.i.z. and originally appeared here. Thanks, d.i.z. Edited post to add this 🙂

  19. Anonim writes:"It's a combination. To put it this way: if oncontextmenu was seen as important at an earlier point in time, it would likely not be so difficult to implement it today."problem is, that every other browser knew that it is important ten years ago. Opera was and is the ONLY browser that deemed it not needed.Why so late? Why Opera wanted to swim upstream? This alone thing made my colegues and myself to stop taking care about Opera. "if they know better, then.. okay". So in intranets I did other browsers have right click functionality, while Opera hasnt. I know, that I'm not alone on that. Why? WHY it took so long for you to understand, that going upstream while being a VERY small fish HAS to end in a disaster? You are now ignored, just because it isn't possible to do otherwise.So, WHY Opera?

  20. Current browser.js status: enabled. Target version and time stamp of the active browser.js file is Opera 10.00, Desktop, July 27, 2009 .It is live 🙂

  21. Anonim writes:"Probably because it is hardly ever used at all"Like on google maps, gmail and countless other popular sites?

  22. wut writes:A couple of Google sites where no one is using the custom context menu anyway does not "countless other popular sites" make.

  23. Anonim writes:"If Opera had the luxury of free compatibility that other browsers get"like safari, that we all know dervies straight from internet exploer and netscape, right?other browsers somehow manage to both cope with broken-world-wide-web and do 'more stuff'maybe Opera simply wastes too much time on unnecessary things like Unite or widgets? Maybe different teams have different goals – ok. so then disband one team and move that workforce to another..

  24. Anonim every browser now has some sort of feature to try to fix pages that break for some reason in their browser even IE

  25. Chas4 wrote "every browser now has some sort of feature to try to fix pages that break for some reason in their browser even IE"I think you got that in reverse. It isn't "even IE". It's "mainly IE". It's probably the only feature in IE I both like and dislike at the same time: its ability to make right what web authors code wrong.

  26. Anonim writes:remember that industry-standard is more important than web-standard. why? because w3c standards are partial, muddy, full of gray areas etc and sometimes plain contradictory. If standards arent precise, then a vendors should go with their implementation along the lines others already drawn. Opera like to go their own way, and end as the only browser that doesn't work with something. It is a stupid way of neglecting reality and believing that everything 'good' is 'good'. In case of w3c standards that are VERY badly written, it is better to go with the crowd.I still remember the firs version of user made userJS that fixed GMAIL. More than half fixes were for opera' errors, not gmail ones. And most of these Opera errors were 'going upstream just for the sake of being different'.

  27. Anonymous writes:dont confuse reality with 'would be' alternative worldw3c standards are badly written and to make them work for every one vendors need to cooperate and the lesser players conform to majority. Opera is a lesser player, and in many cases – like with oncontextmenu – swam upstream. and then 'the world is bad, we have to deal with bad code'. nope, it was Opera' concious decision to try and convince others, that Opera knows best. nobody couldnt care less about browsers with 1.x share, so it was ignored. no responsible person will ignore industry standards. and it is not about IE6, but about common implementation of certain gray areas between 'modern' and 'standards compliant' browsers.w3c 'standards' are so bad, that even such basic stuff like double click events are described in a way, that allows EACH browser, to interpret and implement them differently. and they all are standards compliant. but browsers doing other than industry standards are going to not work with most pages.be reasonable about standards and you'll go far, be orthodox and you'll soon start repeating meaningless mantras loosing focus of what you really mean. try to understand what 'industry standard' is, with open mind. dont get confused.

  28. I'm surprised my.opera.com doesn't offer the mobile site 1st to WAP browsers. I can't access it at all on my Nokia. (Was trying to check blog actually looked ok to mobile surfers.) Keep getting 'No Response' pop up on phone. Will report it when bug report wizard is working.=o}

  29. Originally posted by anonymous:

    w3c 'standards' are so bad, that even such basic stuff like double click events are described in a way, that allows EACH browser, to interpret and implement them differently. and they all are standards compliant.

    LOL. The last bullet point in the blog post is one example of a standard not defining stuff it really should cover. Some of the W3C standards aren't very good, luckily some are much more comprehensive.

  30. Anonymous writes:yes, some are good. but not all of them. and responsibility for a latecomer or a minor player is to conform to majority, when it comes to implementing gray areas.were Opera developers checking what other vendors did to that RGB spec you are telling about? were their intention to make it like others did (and make Opera work with pages designed to 'industry standards', or to make it Opera way, and then wait until all others change their implementation?the first way is the correct one, but I'm almost certain that Opera for some strange reason follows the second one almost to the point.Am I right?

  31. The return value for getComputedStyle really would have benefited being covered by the spec. I was recently tripped up by Safari returning rgba(0,0,0,0) for background-color: transparent

  32. Originally posted by anonymous:

    were Opera developers checking what other vendors did to that RGB spec you are telling about?

    You're assuming that Opera implemented getComputedStyle() later than the other browsers. Let's have a history lesson!Specification was done on November 13, 2000.As far as I can tell, Mozilla was the first browser to implement getComputedStyle() support in May 2000, but this implementation handled only a sub-set of the CSS properties (notably not "color"), and apparently their implementation isn't finished yet, 9 years later? (Perhaps they just forgot to mark bug 42417 fixed, of course..) Along the way they obviously added support for "color", but when that happened I've not been able to figure out.Opera's implementation was first seen in Opera 7, developed during 2002 and released as a final version early 2003.KDE (ancestor of WebKit/Safari/Chrome browser family) implemented it in February 2004In 2003, the CSS WG was still discussing how these details should work while browsers were shipping implementations (DOM2 Styles was considered a stable spec, after all, even without the details) – traces of the discussion can be seen in funny bug comments like this one.So, with all this uncertainty – being only the second browser to implement an incomplete spec (and perhaps the first to implement "color" support) – how did Opera decide what to do?Funny fact: by looking at this early draft by Ian Hickson for spec text on how browsers should decide canonical values for CSS properties. The sentence that years later confused AOL webmail is:

    Colours (other than system colours, see below) are canonicalized to the six-hex-digit #RRGGBB syntax if their alpha component is exactly 1.0, and the rgba(r, g, b, a) syntax with integer arguments if the alpha component is less than 1.0

    That's how haphazardly incomplete specs get implemented.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s