browser.js updates: Hotmail, Tuenti, AOL Webmail
Thursday, 23. July 2009, 16:57:13
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.
WIDGETIZE
Zotlan # 23. July 2009, 17:59
Speaking of Buienradar, how come other browsers render the rainclouds on the map with a slight transparency while Opera does not?
Hallvord R. M. Steen # 23. July 2009, 18:22
Galileo # 23. July 2009, 18:27
Zotlan # 23. July 2009, 18:41
Originally posted by hallvors:
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.
Pallab De # 23. July 2009, 18:58
Sure. I am all for more information. And although I know little bout js and stuff I love reading your posts.
Groovy # 23. July 2009, 19:19
Charles Schloss # 23. July 2009, 19:45
http://www.opera.com/docs/browserjs/
Kyle Baker # 23. July 2009, 22:33
I'm glad to see that support for the oncontextmenu event is coming.
Anonymous # 23. July 2009, 22:54
This makes an interesting post in my opinion.
Hallvord R. M. Steen # 23. July 2009, 23:16
Originally posted by Galileo:
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:
Guess so
Omega Junior # 24. July 2009, 08:10
Remco Lanting # 24. July 2009, 11:47
One of the options in there is to compare different (versions of) files with eachother, so once this update goes live you'll be able to easily see what exactly changed.
JanGen # 24. July 2009, 12:54
You 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!
Zotlan # 24. July 2009, 14:22
Originally posted by JanGen:
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.
Groovy # 24. July 2009, 15:38
Martin Rauscher # 24. July 2009, 19:34
Originally posted by hallvors:
IT IS!
Phred # 24. July 2009, 21:07
Originally posted by hallvors:
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?Remco Lanting # 25. July 2009, 00:36
It's all in the details
Phred # 25. July 2009, 05:18
Originally posted by remcolanting:
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;
Anonymous # 25. July 2009, 08:53
"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?
Remco Lanting # 25. July 2009, 09:55
There is a site for instance that blocks Opera because blocking right click with javascript doesn't work by default.
XenoAntares # 25. July 2009, 10:27
ETA: Firstly observed using bjsversion=' Opera 10.00, Desktop, July 23, 2009 ', the previous version did not produce these errors to my knowledge.
Hallvord R. M. Steen # 25. July 2009, 11:35
Hallvord R. M. Steen # 25. July 2009, 11:52
Originally posted by fearphage:
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.
Hallvord R. M. Steen # 25. July 2009, 12:07
Hallvord R. M. Steen # 25. July 2009, 12:14
Originally posted by fearphage:
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.
Hallvord R. M. Steen # 26. July 2009, 10:20
Hallvord R. M. Steen # 27. July 2009, 08:43
Anonymous # 27. July 2009, 13:03
"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?
Charles Schloss # 27. July 2009, 14:26
Target version and time stamp of the active browser.js file is Opera 10.00, Desktop, July 27, 2009 .
It is live
Omega Junior # 27. July 2009, 21:44
Anonymous # 28. July 2009, 13:43
"Probably because it is hardly ever used at all"
Like on google maps, gmail and countless other popular sites?
Anonymous # 28. July 2009, 14:18
A couple of Google sites where no one is using the custom context menu anyway does not "countless other popular sites" make.
Anonymous # 30. July 2009, 16:54
"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..
Charles Schloss # 30. July 2009, 17:00
Omega Junior # 31. July 2009, 10:22
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.
Charles Schloss # 31. July 2009, 14:57
http://my.opera.com/core/blog/show.dml/3130540
The other thing I have not seen from Microsoft why no page about why web-standards code is better than IE only.
Anonymous # 1. August 2009, 06:48
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'.
Charles Schloss # 1. August 2009, 14:21
http://www.webstandards.org/learn/
Anonymous # 1. August 2009, 19:40
dont confuse reality with 'would be' alternative world
w3c 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.
53north # 2. August 2009, 05:36
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}
Hallvord R. M. Steen # 2. August 2009, 17:12
Originally posted by anonymous:
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.
Anonymous # 3. August 2009, 07:29
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?
andrew walker # 4. August 2009, 12:47
Hallvord R. M. Steen # 4. August 2009, 21:54
Originally posted by anonymous:
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 2004
In 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:
That's how haphazardly incomplete specs get implemented.
Anonymous # 14. August 2009, 15:16
Where opera in the best.?
Anonymous # 16. August 2009, 06:46
wayOfTheBastard - please, do not get involved in discussions you do not understand