Sunday, 12. August 2007, 01:51:25
foxnews, compatibility
I come back from vacation to a piece of good news: the
Foxnews video player works in Opera again. Thanks,
David!
The issue that broke Foxnews was so weird that I've analysed it two or three times to be sure. On the face of it, the error was very obvious: the JavaScript console reports that the script tried to use an undefined variable. The hard question was: where was this variable supposed to be defined, and why wasn't it defined in Opera?
It turned out that not just one but a few undefined variables were meant to control the playback of adverts before and after the video contents, and these variables were only set by a certain script sent from the DoubleClick advertising server, and only read by the script embedding the video player. It seemed like DoubleClick had some sort of "bad browser, good browser" logic somewhere, so rather than send us the essential variables they sent a script that just added an old-fashioned ad to the page. I spent quite some time trying to guess the logic - was it user-agent sniffing or something else? - but couldn't quite get to the bottom of it. URLs for most ad-scripts are so hideously complex with tons of parameters - and any parameter, header or cookie might be the cause Opera received the wrong code. I still don't know exactly what caused it..
Browser.js patching appeared impossible, since the patch would have had to guess correct URLs for the video ads meant to run before and after the news.
I was wondering for a while why Foxnews did this. Why on earth make core functionality on your website depend on some random third-party ad server code? Finally the penny dropped: this must be an anti-ad-blocker architecture. If you block scripts from DoubleClick to avoid seeing adverts, the video player won't work..
Saturday, 7. July 2007, 11:08:40
prototype, compatibility, coding, decompile
Prototype 1.5.0 completely breaks CNN on certain mobile versions of Opera. All the text disappears.
We've dug up the source and it appears to be code from the common prototype.js that causes problems, CNN's
prototype.js is here:
Element.extend.cache = {
findOrStore: function(value) {
return this[value] = this[value] || function() {
return value.apply(null, [this].concat($A(arguments)));
}
}
};
Problem arises when the "value" argument is a function object. Then this[value] = this[value] requires decompilation, in order to create a string for the property name.
This is a bad idea because
- Decompilation support is an optional feature. We disable it on many limited platforms for performance
- Decompiling a function is in any case not a reliable way to create a unique hash key since functions can have exactly the same source code but live in different scopes or different closures, so this code as-is will create obscure bugs that are very hard to track down.
I hope the excellent Prototype devs can find a better approach. Unfortunately this code is still there in
the latest version.
(Due to impatient family members I can't bug it in their
tracker right now, post a link to the bug in comments if you do.)
Wednesday, 11. April 2007, 16:43:01
compatibility, date parsing, javascript, ecmascript
Besides the famous
getYear ECMAScript date parsing is so badly specified that it is full of quirks. Opera has a good share of them..
Some random testing in IE7, Firefox 2 and Opera 9 shows that a simple
new Date(somestring) dishes up several surprises:
- Opera seems to be the only one that tries to parse European date formats, though it defaults to U.S. format for ambiguous dates. Hence, "1/2/2008" is January 2nd while "30/10/2008" is October 30th in Opera.
- Greater than expected values for a specific part increases the whole date value in IE and Firefox. In other words, passing in January 32nd returns February first.
- ..but this is more thoroughly implemented in Firefox than IE, "1/1/2008 23:59:60" gives you January 2nd in the former and NaN in the latter.
- Opera defaults to values from current timestamp on computer for any input that doesn't make sense. In other words, if you pass in January 32nd on April 11th, January 11th is not-quite-expected outcome..
- The IE and Firefox parsers support both m-d-y and y-m-d formats. So if the input is ambiguous, how do they know which is which? Elementary, dear Watson: if the first integer is greater than 70 it is assumed to be a year. If it is less than 70 it is assumed to be a month. "69-1-1" is obviously a 1906 date while "70-1-1" is new year's day 1970. Ah, the magic of arbitrary heuristics.
- Speaking of the magic number "70", why can Firefox parse "1 january 70" but says "invalid date" for "1 january 69"??
- ..and why does Opera refuse to recognise single digits as valid years, just substituting the current year instead? Opera, pretending "1 january 9" is today's date is NOT the correct fix for those Y2K bugs..
- Finally, a quirk I'll leave my readers to ponder the inner workings of: if I tell Opera to parse "january 100 2007" on this very day, April 11th 2007 I get "Thu, 11 Jan 2007", which is consistent with the observation that it replaces out-of-range values with current values. Now, who can explain what Opera does if you parse "january 101 2007"?
Executive summary: good thing we're writing browsers and not time machines!
Saturday, 17. February 2007, 17:14:00
ie, coding, compatibility
Over at
basket.kde.org they are understandably Windows-averse. I guess their website is not exactly targeted at IE users, but even so some cross-browser testing would uncover bugs and errors in their JS. Snippet:
// Cross-browser implementation of element.addEventListener()
function addEventListener(element, type, expression, bubbling) {
bubbling = bubbling || false;
if (window.addEventListener) { // Standard
element.addEventListener(type, expression, bubbling);
return true;
} else if (window.attachEvent) { // IE
element.attachEvent('on' + type, expression);
return true;
} else return false;
}
Whoever wrote that obviously is confused about event bubbling versus event capturing (luckily it defaults to a sensible false!) but the main problem with this code is the line
if (window.addEventListener) { // Standard
Um, no, what you are seeing there is not the W3C standardised window.addEventListener
1. You're actually checking for the existence of this very function - the one we're inside when we hit that statement. Naturally IE chokes on the next line and no event handlers are added. (If you ask, it should read
if(element.addEventListener).)
So - a slick, good-looking production site that wasn't tested with IE - what a rarity!
Edit - note 1: well, actually W3C didn't specify addEventListener for window in the first place, it remains a Gecko extension like I've
complained about earlier so the comment "// Standard" is doubly wrong..
Wednesday, 7. February 2007, 17:38:50
getYear, coding, compatibility
The great thing about JavaScript's Date.getYear()? It makes reading source code fun again..
Read more...
Monday, 5. February 2007, 23:27:58
bookmarklets, Opera Mini, coding, orkut
...
A great thing about the web is how skilled users can subvert its complexity
http://fundubytes.blogspot.com/2006/11/mobile-orkutting.htmlRelying on bookmarklets to make a website usable shouldn't be necessary, but when sites take the quick-and-dirty approach with no concern for back- and forwards compatibility with oddly limited clients like Opera Mini, it's just so cool that the users
can fight back. Bookmarklets rule!
Friday, 12. January 2007, 00:53:29
ie, vbscript, microsoft, pie
...
Imagine a browser that doesn't support VBScript. Think of a site using VBScript to detect Flash. Think of users being annoyed when they are told their browser "does not have Flash" even though it does. Sounds familiar?
Well, this time we're not talking Opera! We're dealing with PIE - Pocket IE on Pocket PC... They've done some testing over there and realised that VBScript Flash detection is quite common. Hence, Microsoft now tells you to
avoid using VBScript plugin detection as it hurts interoperability!!
LOL. Priceless. And thanks for the URL,
malware.
Saturday, 23. December 2006, 19:39:36
addEventListener, compatibility, Firefox, event capture
Over at Mozilla.org they've been working on fixing their
load events capture bug. That's great news, because Opera has had lots of trouble with sites that used event capture when they didn't intend to do so. We had the correct, spec-compliant implementation. However, web developers don't read specs. They test in browsers. We suffered the incompatibility problems because sites were written for Firefox's
implementation. We've had ugly problems caused by this issue for years, on extremely important sites like AOL.com, and we've worked hard through
Open The Web,
information and even
site patching.
Inevitably, when Firefox fixes the bug they run into those badly coded sites. They start seeing the problems we've had all along. So what do they do?
They play chicken! They decide to tweak the spec to solve the problem their bugs created in the first place.
If they go for this solution, we have to follow them for compliance.
To be fair, I
do think that aligning a spec to the web can be a good solution, as long as it ensures interoperability and covers the use cases. And the DOM2 Events spec itself is vague. I guess the problem is a spec that attempts to be so language-generic that it avoids referring to even the all-important JavaScript
window object, it isn't clearly specified where the window object fits into the event capture/bubble model. They can and probably will argue that their implementation
is DOM conformant (and make sure the HTML5/web apps spec lands on their side?).
I'm still disappointed.
Showing posts 25 -
32 of 59.
WIDGETIZE