focusout not fired when activeElement is focused
Categories
(Core :: DOM: Events, defect, P5)
Tracking
()
People
(Reporter: evan.trimboli, Unassigned)
References
(Depends on 1 open bug)
Details
Attachments
(1 file)
568 bytes,
text/html
|
Details |
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.
Updated•7 years ago
|
It's fired if you set the focus on another element (like the location bar) after you typed "c".
Comment 2•7 years ago
|
||
Olli, do you know what's going wrong here? Is this under-specified or is Gecko just wrong?
Reporter | ||
Comment 3•7 years ago
|
||
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•7 years ago
|
||
Isn't this a dup of the bug where blur isn't fired when hiding an element? This isn't spec'ed anywhere.
(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•7 years ago
|
||
But input element doesn't lose focus here in Firefox.
Reporter | ||
Comment 7•7 years ago
|
||
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•7 years ago
|
||
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
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•3 years ago
|
||
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•1 year ago
|
||
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
Updated•1 year ago
|
Comment 12•1 year ago
|
||
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•1 year ago
|
||
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•1 year ago
|
||
Awesome! Dropping the webcompat-priority flag then, as there is no more known breakage left.
Description
•