'focusin' event fires after element receives focus and 'focus' event fires
Categories
(Core :: DOM: UI Events & Focus Handling, defect, P5)
Tracking
()
People
(Reporter: hunterheard516, Unassigned)
References
()
Details
(Keywords: dev-doc-needed)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:94.0) Gecko/20100101 Firefox/94.0
Steps to reproduce:
I made a page with an input which logs focus events and tells if the element is in focus at the time of the event being handled.
<!DOCTYPE html>
<html>
<body>
<input id="i1" onfocus="f(event)" onfocusin="f(event)" onfocusout="f(event)" onblur="f(event)">
<script>
const i = document.getElementById('i1');
function f(event) {
console.log(event.type + (document.hasFocus(i) ? ': focused' : ': NOT focused'));
}
</script>
</body>
</html>
Actual results:
Here are the log results from clicking into, then out of, the input:
focus: focused
focusin: focused
blur: focused
focusout: focused
Expected results:
As per the W3C UI Events specification (https://w3c.github.io/uievents/#event-type-focus), the 'focusin' event should fire BEFORE an element is given focus, and the 'focus' event should fire AFTER the element is given focus. So not only was the element given focus before 'focusin' was fired, 'focusin' fired AFTER 'focus'.
Here are what should have been the log results:
focusin: NOT focused
focus: focused
focusout: focused
blur: NOT focused
(Chrome seems to have the same issue. Internet Explorer gets the order of the events themselves correct, though document.hasFocus(i) still returns true on all of the handlers)
|
Reporter | |
Comment 1•3 years ago
|
||
So I made an error in the code experiment.
Instead of 'document.hasFocus(i)', I should have used 'document.activeElement === i'.
When I change it, the new log results are:
focus: focused
focusin: focused
blur: NOT focused
focusout: NOT focused
However, the events are still not in the right order, and "focus" and "focusout" should be the events where the element was not in focus at the time of their handling. So, the bug report's main point still stands.
I can't seem to edit the bug's main body.
|
||
Comment 2•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: UI Events & Focus Handling' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
|
||
Updated•3 years ago
|
|
|
||
Comment 3•3 years ago
|
||
Firefox:
"focus: focused"
"focusin: focused"
"blur: NOT focused"
"focusout: NOT focused"
Chrome:
"focus: focused"
"focusin: focused"
"blur: NOT focused"
"focusout: NOT focused"
Safari:
"focus: focused"
"focusin: focused"
"blur: NOT focused"
"focusout: NOT focused"
|
|
||
Updated•3 years ago
|
Yeah, I should go and update https://github.com/w3c/uievents/pull/290. Thanks for CCing.
|
|
||
Comment 5•3 years ago
|
||
Thank you! Could you handle this (at least Priority/Severity)?
The existing behavior is already correct, we only want the spec to be updated. Hence lowest p/s, but it doesn't mean this issue is wrong! Thank you for filing this 👍
|
|
Reporter | |
Comment 7•3 years ago
|
||
(In reply to Kagami :saschanaz from comment #6)
The existing behavior is already correct, we only want the spec to be updated. Hence lowest p/s, but it doesn't mean this issue is wrong! Thank you for filing this 👍
I thought the W3C spec was the 'grand authority' on all web browsers, and browser devs followed their spec, is that incorrect?
Are we not going to have an event which fires just before focus is shifted?
And is Mozilla going to update the description on its own website for these events?
https://developer.mozilla.org/en-US/docs/Web/API/Element/focusin_event
In 2021 it's more like the formal interoperable description of browser behaviors. If browsers are already interoperable and the spec says otherwise, it's the spec that should be fixed.
Are we not going to have an event which fires just before focus is shifted?
AFAICT no such plan exists. You can file an issue on https://github.com/w3c/uievents/issues with a good potential use case that focus/focusin cannot fulfill.
And is Mozilla going to update the description on its own website for these events?
Oh, thank you for noticing that, I guess someone should update it. Adding dev-doc-needed for that. Specifically "The focusin event fires when an element is about to receive focus." should instead say "after an element received focus", and should probably also say that it fires after "focus" event.
Description
•