Consider enabling the focus fixup rule on release.
Categories
(Core :: DOM: UI Events & Focus Handling, task)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox110 | --- | fixed |
People
(Reporter: emilio, Assigned: emilio)
References
Details
(Keywords: dev-doc-complete)
Attachments
(1 file)
|
Assignee | |
Comment 1•1 year ago
|
||
While the spec issue and PR are not closed, there seems to be rough
consensus on our approach and timing, and I believe the current behavior
is better than what we're shipping on release.
So perhaps we could let this ride the train, and do minor tweaks in the
future if needed?
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/27e88caf4ca4 Let the focus fixup rule ride the trains. r=smaug
|
|
Assignee | |
Updated•1 year ago
|
|
||
Comment 3•1 year ago
|
||
| bugherder | ||
|
||
Comment 4•1 year ago
|
||
MDN docs for this can be tracked in https://github.com/mdn/content/issues/25496
Emilo, what were you expecting to be documented? I had a read of the changes and existing docs and I put a summary of what I think this is all about and what perhaps needs to be updated in https://github.com/mdn/content/issues/25496#issuecomment-1477313325 - would appreciate your comments
Essentially I think this means that blur event is not emitted if you remove a node with focus, but that blur() (probably) will be sent if you change the style such that the element is present but no longer focusable. This is important because developers might otherwise assume the focus-lost events will always be sent.
- It isn't clear whether focusout is emitted in the removal case
- It isn't clear what other change events are might not be sent in the removal case
- it isn't clear (to me) what gets the focus? It sounds like it's the document viewport, but I'm not sure what that means w.r.t. where the focus events get sent, or if they are sent at all.
Would you be able to have a look at https://github.com/mdn/content/issues/25496#issuecomment-1477313325 and confirm whether I am in the right "ballpark" and what you think needs to happen.
|
|
Assignee | |
Comment 5•1 year ago
|
||
Essentially I think this means that blur event is not emitted if you remove a node with focus, but that blur() (probably) will be sent if you change the style such that the element is present but no longer focusable. This is important because developers might otherwise assume the focus-lost events will always be sent.
That's right, but before these changes we wouldn't even update the focus when styles made something unfocusable.
It isn't clear whether focusout is emitted in the removal case
I don't think so. But behavior on removal isn't changed by this.
it isn't clear (to me) what gets the focus? It sounds like it's the document viewport, but I'm not sure what that means w.r.t. where the focus events get sent, or if they are sent at all.
The same happens as if you do element.blur(). The viewport / body gets the focus.
Would you be able to have a look at https://github.com/mdn/content/issues/25496#issuecomment-1477313325 and confirm whether I am in the right "ballpark" and what you think needs to happen.
Yeah, that sounds right. This change makes the behavior more compatible with other browsers (but over-all things are still a bit messy in Chromium). So not sure a BCD entry is warranted, it's... tricky :)
|
|
||
Comment 6•1 year ago
|
||
Thanks @Emilio!
I've added an MDN release note and noted these cases of focus loss in the blur event docs - see https://github.com/mdn/content/pull/25670/. If you have any feedback, that would be welcome.
For BCD I take your point, but would prefer not to lose the version data in which this change happened. So I added a note and let's see what BCD team say https://github.com/mdn/browser-compat-data/pull/19242
Description
•