|
||||
|
|
|||
The Event.type property of a DOMFocusIn event is now 'focusin' instead of 'DOMFocusIn' (and likewise for DOMFocusOut).
Apparantly the Chromium (or Webkit?) team has implemented Internet Explorer's non-standard event (though ground-breaking, IE had focusin/out before any standard event model browser had DOMFocusIn/Out).
Most likely for augmented compatibility with IE oriented Javascript.
But it seems that the developers made a shortcut so that DOMFocusIn and focusin events effectively get the same type.
Observed in Google Chrome 5.0.375.17 dev, reported to the chromium developer team as DOMFocusIn thinks it's focusin, DOMFocusOut thinks it's focusout - wrong Event.type.
By the way, Firefox supports neither DOMFocusIn/Out nor focusin/out – unless you use a Javascript framework, like ZZ.
[2011-10-18]No such issue any more - the chromium team probably fixed it ages ago.
When a user does a drag – and thus possibly also a drop – it's crucial that observers may be notifyied unambiguously when the dragging comes to an end.
If dragend fires before drop then the outcome of the dragging – the actual drop, effectively a data transfer – is prone to be ignored because observers will lose interest at the dragend.
The HTML5 specification (don't go there in anything but Chrome unless you like browser crashes ;-) doesn't concisely mention the sequence of events.
But the whole principle (at least Event.dataTransfer) was originally
invented by MS, and they say on the ondrop event, 4th block, "Remarks":
"The ondrop event fires before the ondragleave and ondragend events.".
Observed in Google Chrome 3.0.195.27, and reported to the chromium developer team as drag-n-drop: dragend event fires before drop event.
[2010-03-08]The chromium team has merged the issue reported by me with a later (2009-12-29) ;-) reported issue, Drag and drop events are fired in the wrong order
[2010-03-23]The chromium team marks the issue fixed.
However I can't verify it in current Chrome release (they have to roll it out first, of course).
Yep, they fixed it – kudos chromium developer team (tested in version 5.0.375.29 dev).
Observed in Internet Explorer 7 or 8 (?).
The issue may seem a little exotic, but it actually makes a big difference when you do apply() dynamically. If you do apply within a function, and use an Array|undefined|null argument of that function as arguments for the apply, like:
function(obj, func, args) {
func.apply(obj, args);
}
for IE you have to do:
function(obj, func, args) {
if(args) { func.apply(obj, args); }
else { func.apply(obj); }
}
The EcmaScript 262 specification says:
"15.3.4.3 Function.prototype.apply (thisArg, argArray)
The apply method takes two arguments, thisArg and argArray (...).
If argArray is null or undefined, the called function is passed no arguments."
Confirmed in Internet Explorer 8 (8.0.6001.18702)
Apparantly, deletion (of an immediate property) during iteration is reflected in all browsers (Gecko, Webkit, IE).
However if you add a property, only Internet Explorer will 'see' the new property within the current iteration.
Cool, IE7 supports 24-bit PNG – the practically lossless bitmap format which for plain web work first of all enables true transparency.
But, Internet Explorer 7 does not support css:opacity (in ie lingo: filter:alpha...) for png-24. Well, okay it does support opacity, but transparency goes completely haywire when you attach the opacity property to a png-24 image.
It actually ends up looking far worse than the good old border pixelation on gifs/png-8's placed upon a background that doesn't match picture perfect with the image's transparency matte.
So if you wanna fiddle with opacity, like create a hover effect, you gotta revert to the 8-bit formats – at least in your fix-the-mess alternative stylesheet for IE...
Firefox (Gecko's) focus handling is notoriously buggy. Calling form.element.focus() is destined to fail when there's other DOMxJavascript events happening around the same time.
Spend ages figuring out that Firefox did _not_ crash for me because I:
a) used delayed focus (example, page-down, kaled)
b) traversed the document nodes (upwards, checking if the element to be focused actually still was visible [it's visibility not being influenced by a parent element])
Nope, the problem was far simpler: the focus was called for right after an alert had been triggered. The string of events were as follows:
1) a dialogue box (an html layer) containing a form shows up
2) when the dial box opens, a text field immediately gets focus (no problem here)
– the text field has an unblur event listener added (old-school wise, onblur="...",
not addEventListener)
3) user clicks on the dial box' "close" button...
4) ...thus triggering the text field's unblur event (~ clicking other thing, "you" left "me")
5) the function called upon the the unblur decides that the user's input is invalid,
and the function commands:
i pop alert(), to tell the user about the input blunder
ii put focus back on the text field, so that the user may get right on to fixing the input
6) user reads alert box, and closes it – Bang!, Firefox goes down
Apparently Gecko couldn't figure out where the f... focus is at the moment, and how to move it.
Ended up using another html dial box as alternative to alert(). Good bye alert()...
– anyways, you're damned ugly and obtrusive, so maybe I won't miss you...
...turned out that Internet Explorer didn't like the chain of events either.
ie is not willing to set focus on something invisible – and that I guess does makes pretty much sense.
So in the end I created a focus() alternative that checks visibility before executing a focus call. And that's applied to all browsers now, instead of the straightforward, but unchecked, focus function.