1363964 - focusout not fired when activeElement is focused

Status: UNCONFIRMED

(Core :: DOM: Events, defect, P5)

Description

[Evan Trimboli]

Attachment: raw.html

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.81 Safari/537.36

Steps to reproduce:

1) Run the attached test case.
2) Focus the text field using the mouse.
3) Type "abc".


Actual results:

The field is hidden after "c" is typed and the focusout event is not fired.


Expected results:

The focusout event should fire. It is fired in Edge/Chrome.

Comment 1

[Loic]

It's fired if you set the focus on another element (like the location bar) after you typed "c".

Comment 2

[Andrew Overholt [:overholt]]

Olli, do you know what's going wrong here? Is this under-specified or is Gecko just wrong?

Comment 3

[Evan Trimboli]

Sorry, I should have been more explicit. The event does fire correctly when moving the focus elsewhere, the issue exists when the activeElement is hidden (via display/visibility) or removed from the DOM.

In all 3 of the above cases, Chrome will fire the focusout event.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

Isn't this a dup of the bug where blur isn't fired when hiding an element?

This isn't spec'ed anywhere.

Comment 5

[nige]

(In reply to Olli Pettay [:smaug] from comment #4)
> Isn't this a dup of the bug where blur isn't fired when hiding an element?
> 
> This isn't spec'ed anywhere.

https://www.w3.org/TR/DOM-Level-3-Events/#event-type-focusout

"A user agent MUST dispatch this event when an event target is about to lose focus."

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

But input element doesn't lose focus here in Firefox.

Comment 7

[Evan Trimboli]

Sorry, I'm not clear what you mean by it doesn't lose focus. Can you elaborate? If I modify the test case slightly like so:

var foo = document.getElementById('foo');
foo.addEventListener('keyup', function(e) {
  if (e.key === 'c') {
    foo.parentNode.removeChild(foo);
    console.log(document.activeElement);
  }
});

The activeElement is now the body. Since it's no longer the activeElement, doesn't that mean it has lost focus?

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

In the original testcase if there is an interface checking what is the active element, it stays in input element.

And comment 7 is Bug 559561

Comment 9

[nige]

And focus should not stay on a hidden element. This makes it difficult to write accessible apps. They rely on focus always being in a predictable place, and on the app (or framework) being informed about focus.

If a hide of a focused element is completely silent, this is very difficult. And it's not how all other browsers work.

Comment 10

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.

Comment 11

[Thomas Wisniewski [:twisniewski]]

This is now causing the hovercards on GitHub's page to not hide properly if the user clicks on links to drill down into detail pages, as found at https://webcompat.com/issues/117240

Comment 12

[Dennis Schubert [:denschub][OOO, back Aug 11]]

It looks like GitHub might have fixed this according to https://github.com/webcompat/web-bugs/issues/117240#issuecomment-1436143410. Tom, can you verify that this is fixed on their end?

Comment 13

[Thomas Wisniewski [:twisniewski]]

Yes, although the specific code I was looking at hasn't changed, it no longer sees the conditions which triggered the bug, so they must have fixed it.

Comment 14

[Dennis Schubert [:denschub][OOO, back Aug 11]]

Awesome! Dropping the webcompat-priority flag then, as there is no more known breakage left.