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
>

Reply via email to