2015-01-24 23:27 GMT+01:00 Mats Palmgren <m...@mozilla.com>: > On 01/08/2015 11:38 AM, Rob Wu wrote: > > The spec of the focusing algorithm [1] is not explicit about > > removed/hidden nodes. It seems to allow the change / blur / focusout > > events to be dispatched when an element becomes hidden or is removed > > from the document. > > > > All non-WebKit-based users agents (Trident, Gecko, Presto) do NOT > > follow this behavior. I.e. upon node removal, the change/blur/focusout > > events are not dispatched. WebKit and Blink deviate from the other UAs, > > they do trigger these events ( crbug.com/439484). > > > > This discrepancy became even more significant when Blink started to > > match other UA's behaviors and focus anchor elements upon click ( > > crbug.com/388666#c10). Now, out of all browsers that focus an <a> > > element upon click, Blink is the only one that triggers the blur event > > when a node is hidden/removed. This difference has caused some broken > > websites and bug reports. > > > > There are two options here: - Dispatch change / blur / focusout when an > > element is unfocused, regardless of whether the element is still in the > > document. - Ignore hidden / removed elements in the focusing algorithm; > > i.e. do not dispatch these events. > > > > I'm inclined to vote for the second option, because the majority of > > the distinct user agents already follow this behavior. What do you > > think? > > > If by "hidden" you mean "an element styled with display:none", then > I think you're mistaken. I tested IE11, Chrome41, Firefox38 and Safari8, > and they all dispatch blur, although slightly differently. IE and Chrome > blurs directly at the style change (per spec); Firefox and Safari leaves > the element focused even after it's "display:none" but blurs it later when > a new element is focused. Not sending a blur event at all in this case, > as you suggest, would be incompatible with the existing behavior of all > four UAs. >
It appears that onblur is indeed triggered (eventually) when an element is hidden. Test case https://robwu.nl/s/chromium/bug439484/ ("onfocus = hidden=true") - Chrome 40: onblur is immediately triggered upon hiding the element. - Firefox 37 / IE 11 / Safari 8 / Opera 12 (Presto): onblur is triggered only after focusing another element (or unfocusing the page) Node removal, on the other hand, behaves like I described: Only WebKit triggers onblur (same test page): Test case ("onfocus = remove()"): - Chrome 40 / Safari 8: onblur is triggered upon node removal. - Firefox 37 / IE 11 / Opera 12 (Presto): onblur is NOT triggered upon node removal. I'm also seeing a different result than you in the case when the focused > node is removed from the document - both IE and Chrome dispatch a blur in > this case. It appears that IE suppresses the blur if the removal is done > inside the removed element's own 'onfocus' (as in your test). > I cannot confirm your observation for IE 11. In your test case, onblur is SOMETIMES fired when the node is removed in IE11 (upon document load). I cannot get onblur to fire in any other situation (see my previous test case, and also https://robwu.nl/s/chromium/bug439484/onblur-and-remove.html ). > I think the intention is that Firefox will change to be compatible with > other UAs and the spec[1] for node removal: > https://bugzilla.mozilla.org/show_bug.cgi?id=559561 > (My tests are in that bug) > > Personally, I think what the HTML spec says in this area makes sense and > since IE / Chrome is already compatible with it (mostly), I'd rather see > Firefox changed to match the spec. > IE is not compatible with that behavior. Only WebKit-based browsers (always) dispatch onblur upon node removal. > > /Mats > > > > > > > Kind regards, Rob https://robwu.nl > > > > [1] > > https://html.spec.whatwg.org/multipage/interaction.html# > focus-fixup-rule-one >
