Focus lost from slotted element on slot wrapper reorder in shadow DOM
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr115 | --- | unaffected |
| firefox-esr140 | --- | unaffected |
| firefox150 | --- | wontfix |
| firefox151 | --- | wontfix |
| firefox152 | --- | fixed |
People
(Reporter: serguey.kulikov, Assigned: emilio)
References
(Regression)
Details
(Keywords: nightly-community, regression)
Attachments
(2 files)
Steps to reproduce:
Reproduction: https://codepen.io/web-padawan/pen/dPOYdJa or see .html attached
Problem: when a slotted element is focused, reordering its slot wrapper in shadow DOM causes document.activeElement to be moved to <body> without a blur event.
Possibly related to https://bugzilla.mozilla.org/show_bug.cgi?id=2037008
Actual results:
Focus silently moves to <body> without firing blur / focusout events.
Expected results:
Focus should remain on the slotted element and document.activeElement should not change to <body>.
|
||
Comment 1•8 days ago
|
||
Regression window:
https://hg-edge.mozilla.org/integration/autoland/pushloghtml?fromchange=bf5bbc20f02b71cbd077340160f525d4b152d871&tochange=93b9cf7d4f69cd2322c7d9289508ba6b23665ae9
|
|
||
Updated•8 days ago
|
|
||
Comment 2•8 days ago
|
||
:emilio, since you are the author of the regressor, bug 1996182, could you take a look? Also, could you set the severity field?
For more information, please visit BugBot documentation.
|
Assignee | |
Comment 3•8 days ago
|
||
So this changed behavior but I think the new behavior is more consistent with other DOM moves isn't it?
You're reordering the <slot> by moving them around, the fact that that didn't blur seems like a bug? You're removing the thing you're slotting into.
The behavior change is because I tweaked this line to use the flat tree.
I'm curious about the use case for this (isn't moveBefore() a better API for what you want to do anyways?).
The spec is woefully undefined here... I guess you could argue that the <input> is still in the dom and in this case it happens to still be in the flattened tree before the focus fixup runs...
|
|
Assignee | |
Comment 4•8 days ago
|
||
|
||
Updated•8 days ago
|
|
Reporter | |
Comment 6•8 days ago
|
||
Thank you for taking a look. For the record, the original issue manifested in our web component that re-assigns slot attribute on child elements when re-rendering. IMO if the element that has focus remains in the DOM, the fact that it's losing focus is somewhat unexpected, but I agree it's an edge case. If this is considered wontfix, we'd have to stick to a workaround to re-focus it.
|
||
Updated•8 days ago
|
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/59708 for changes under testing/web-platform/tests
|
||
Comment 9•7 days ago
|
||
| bugherder | ||
Upstream PR merged by moz-wptsync-bot
|
|
||
Comment 11•7 days ago
|
||
The patch landed in nightly and beta is affected.
:emilio, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
- If no, please set
status-firefox151towontfix.
For more information, please visit BugBot documentation.
|
|
Assignee | |
Comment 12•7 days ago
|
||
Relatively late in the beta cycle for something regressed in 146, IMHO.
Description
•