miscoded

(Warning: this post documents a very obscure and technical quirk. I won't even try to explain it in popular terms. ECMAScript geeks only. )

Opera can not enter the KLM website. The reason is a peculiar ECMAScript interpretation corner case quirk.

The issue is code like the excerpt below:

function (){
  var arguments;
  arguments['foo']='bar';
}

Now, Opera allows overwriting the function's arguments property with a local variable set to undefined. For some reason, FF and IE both ignore the "var arguments;" statement. This makes Opera throw an exception because "arguments" is the value undefined when you reach the line where you add properties, the others luckily escape this error and the site works for them.

Who is right? Most likely Opera. According to the ECMAScript spec you can overwrite the "arguments" array inside a function. It works cross-browser to say "var arguments=foo;", it is just overwriting it with nothing that seems to be incorrectly implemented in FireFox and IE.

I guess we may have to follow them and be bug-compatible.

For KLM the simple fix would be to say

var arguments={};

instead, because that's what they actually meant.

Popup blocking has been a bit of an arms race. Browsers have added more and more advanced heuristics to distinguish "wanted" and "unwanted" popups, and popup script authors have worked hard to find useful exceptions to the browser rules.

Most of the holes popup users have found in the previous popup blocking approaches have been fixed in the most recent browser versions. Opera's popup blocking has been vulnerable to Flash-trickery but that will be history in Opera 9.

However, some users have been curious why the page http://www.popupcheck.com/freescan/popup/popup_test_standard.asp appears to show several popups that evade the blocker. Analysing this issue throws light on some interesting quirks and browser differences.

There is one immediately obvious aspect of a good popup blocker: it should be good at separating "wanted" popups from "unwanted". Opera fails this popup test because you did ask for the popups - you clicked a link to start the test. In other words, Opera is better at detecting what popups you do want than whatever browser this test was tested with.

Another and more technical aspect is whether the script should be able to detect that the popup it tried to open was blocked. Opera goes further to avoid "popup blocker detection" than the others do: we return a dummy window object to the script. A popup blocking return object demo shows that most other popup blockers simply return null. Hence, even if this test started as an "unwanted" action it would be unable to detect that the popups were blocked.

The test simply makes too many assumptions about the popup blocker(s) it will be tested against.

In IE you can sometimes click "through" an element and activate something that is underneath. We've been pondering for a while what the exact behaviour is (and so have the Mozilla devs).

After several test files and experiments, I think I've nailed it - here are IE's event transparency rules. If I have missed anything or you notice a scenario that isn't according to these rules please let me know.

General rules

IE considers an area of an element "transparent" if

a) the computed style of the "background-color" is "transparent"
AND
b) the computed style of "background-image" is "none"
AND
c) it is outside the inline boxes generated by element contents (not counting line-height)
AND
d) it is outside the element's borders (including invisible table borders)

OR

e) it is outside a CSS clip rectangle

OR

f) if "visibility" is "hidden"

Event processing

When a mouse event occurs above a transparent area of the initial target, IE checks the elements in stacking order.

While the current event target area is transparent according to the rules above and is not BODY, IE examines the element below.

If current event target is BODY the topmost element gets the event.

If current event target area is not transparent it will get the event if the event is within a content box or on a border. Otherwise, the event goes to the initial target.



Special cases that are transparent to events:

PNG with alpha channel and the AlphaImageLoader filter applied - the fully transparent areas

IFRAME with attribute allowtransparency and contents with style background: transparent applied

Transparent parts of OBJECT with wmode=transparent

Notes

Clipping does make the clipped region transparent even if the element has backgrounds/background images

Opacity filters and background-position/repeat have no effect on transparency for event handling purposes.

If the event does not reach the BODY element because the target point is positioned outside the BODY, it will go to the bottom-most element, normally HTML.

Line-height does not affect transparency - the extra space inbetween the lines is transparent to events

Table elements are never transparent to events