W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2015

Re: [whatwg] Should onblur be triggered for hidden nodes?

From: Mats Palmgren <mats@mozilla.com>
Date: Sat, 24 Jan 2015 22:27:58 +0000
Message-ID: <54C41C6E.9090800@mozilla.com>
To: Rob Wu <rob@robwu.nl>, whatwg@whatwg.org
Cc: Olli Pettay <olli@pettay.fi>
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.

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 think the intention is that Firefox will change to be compatible with
other UAs and the spec[1] for node removal:
(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.


 > Kind regards, Rob https://robwu.nl
 > [1]
Received on Saturday, 24 January 2015 22:28:34 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:32 UTC