Making focused element not focusable does not cause blur
Categories
(Core :: DOM: UI Events & Focus Handling, defect, P3)
Tracking
()
People
(Reporter: masayuki, Unassigned)
References
Details
(Keywords: parity-chrome)
When making focused element non-focusable, e.g., removing tabindex attribute or contenteditable attribute, Gecko does not dispatch blur event and keep Document.activeElement as the focused element. Chrome sets active element to <body>.
data:text/html,<div tabindex="0"></div><script>const div = document.querySelector("div"); div.focus(); div.removeAttribute("tabindex"); alert(document.activeElement?.tagName);</script>
data:text/html,<div contenteditable></div><script>const div = document.querySelector("div"); div.focus(); div.removeAttribute("contenteditable"); alert(document.activeElement?.tagName);</script>
Enn: Is this intentional?
|
Reporter | |
Comment 1•3 years ago
|
||
This causes that it's harder to manage IME state and selection limiter set by HTMLEditor when focused editing host becomes not editable.
|
||
Comment 2•3 years ago
|
||
We don't currently attempt to remove focus when an element becomes unfocusable. We have several bugs filed on issues similar to this (like 559561 and 570835).
|
||
Comment 3•3 years ago
|
||
We do cause a blur, just async (because focusability depends on style changes), what am I missing? This is controlled by the dom.focus.fixup pref, which is currently nightly-only but we should probably enable on release. See bug 1740989 and https://github.com/whatwg/html/issues/8225.
|
|
Reporter | |
Comment 4•3 years ago
|
||
(In reply to Neil Deakin from comment #2)
We don't currently attempt to remove focus when an element becomes unfocusable. We have several bugs filed on issues similar to this (like 559561 and 570835).
Thank you. If it's not intentional behavior, perhaps, we should fix it at least for editable state changes because it's hard to maintain HTMLEditor to work with ancestor editable elements.
(In reply to Emilio Cobos Álvarez (:emilio) from comment #3)
We do cause a blur, just async (because focusability depends on style changes), what am I missing?
Oh, really? I just tested it with HTMLEditor and IMEStateManager behavior, but I don't find blur event with:
data:text/html,<div tabindex="0"></div><script>const div = document.querySelector("div"); div.addEventListener("blur", () => alert("blur")); div.focus(); div.removeAttribute("tabindex");</script>
This is controlled by the dom.focus.fixup pref, which is currently nightly-only but we should probably enable on release. See bug 1740989 and https://github.com/whatwg/html/issues/8225.
Thanks. I'll check them.
|
|
||
Comment 5•3 years ago
|
||
(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #4)
Oh, really? I just tested it with
HTMLEditorandIMEStateManagerbehavior, but I don't find blur event with:data:text/html,<div tabindex="0"></div><script>const div = document.querySelector("div"); div.addEventListener("blur", () => alert("blur")); div.focus(); div.removeAttribute("tabindex");</script>
I do get a blur event there on Nightly?
|
|
Reporter | |
Comment 6•3 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #5)
(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #4)
Oh, really? I just tested it with
HTMLEditorandIMEStateManagerbehavior, but I don't find blur event with:data:text/html,<div tabindex="0"></div><script>const div = document.querySelector("div"); div.addEventListener("blur", () => alert("blur")); div.focus(); div.removeAttribute("tabindex");</script>I do get a blur event there on Nightly?
Ah, I got it. I see the alert when I do reload the page, but I don't see it if I type Enter in the URL bar. (It's the restriction of focus stealing from chrome to content, so it's intentional.) I'll consider how this should be treated after I'm back.
Description
•