-moz-user-focus handling is a mess.
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Tracking
()
People
(Reporter: emilio, Assigned: emilio)
References
Details
(Keywords: dev-doc-complete)
Attachments
(3 files)
-moz-user-focus: none should force the element not to be focusable. The current behavior is hilarious:
-moz-user-focus: none
is the default.-moz-user-focus: ignore
does something weird with events but otherwise behaves as none.-moz-user-focus: normal
forces the XUL elements to be tabbable, but gets ignored on HTML otherwise.- There are a bunch of other values that do nothing.
Proposal:
-moz-user-focus: normal
is the default.-moz-user-focus: none
prevents focusability.-moz-user-focus: ignore
should ideally be removed or aliased tonone
, but XUL uses it so might be tricky, we'll see.
Comment 1•1 year ago
|
||
Sounds reasonable to me, although it's used a lot in comm-central too.
(Oh, only overrides the tab index??)
Comment 2•1 year ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #0)
-moz-user-focus: ignore
should ideally be removed or aliased tonone
, but XUL uses it so might be tricky, we'll see.
In my understanding, none
element is not focusable, but clicking it makes no element has focus. However, clicking ignore
element does not make the focused element not blurred.
https://searchfox.org/mozilla-central/rev/648a427a0ffc4c62118dbb24bcd88a6b52f54d78/dom/events/EventStateManager.cpp#3522-3523
So, I think that it needs to be as-is.
Assignee | ||
Comment 3•1 year ago
|
||
(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #1)
(Oh, only overrides the tab index??)
Right, and that's super-confusing.
In my understanding,
none
element is not focusable, but clicking it makes no element has focus. However, clickingignore
element does not make the focused element not blurred.
https://searchfox.org/mozilla-central/rev/648a427a0ffc4c62118dbb24bcd88a6b52f54d78/dom/events/EventStateManager.cpp#3522-3523So, I think that it needs to be as-is.
Yeah I guess that the idea is that if you click on, e.g., a toolbar spacer, the urlbar isn't blurred? that's a bit weird compared to HTML, but sure, seems we need a hook for that, so fine to keep ignore.
Assignee | ||
Comment 4•1 year ago
|
||
If removing these were to become a compat issue in the wild, we could
alias them effortlessly. But honestly they're not even documented in MDN
so I'm pretty sure it should be safe to remove.
Assignee | ||
Comment 5•1 year ago
|
||
Make it be output-only, not having that confusing in-out tab-index
parameter that is special for XUL to become focusable with
-moz-user-focus: normal. Instead, do that explicitly in
nsIFrame::IsFocusable().
Also, call it IsFocusableWithoutStyle(), since that's what it is.
Depends on D195643
Assignee | ||
Comment 7•1 year ago
|
||
This is tested via the inert tests, effectively, but I can add more
explicit tests.
Remove rules that would otherwise change behavior (the other rules in
the tree apply to XUL elements and serve a purpose).
Assignee | ||
Updated•1 year ago
|
Comment 8•1 year ago
|
||
bugherder |
Comment 10•1 year ago
|
||
Comment 11•1 year ago
|
||
bugherder |
Updated•1 year ago
|
Assignee | ||
Updated•1 year ago
|
Comment 12•1 year ago
|
||
Comment 13•1 year ago
|
||
bugherder |
Assignee | ||
Comment 15•1 year ago
|
||
Sheriffs, can we back out https://hg.mozilla.org/mozilla-central/rev/d576a857df6f from beta for now while we decide on a way to address bug 1871745?
Comment 16•1 year ago
|
||
Backed out d576a857df6f from Beta as requested: https://hg.mozilla.org/releases/mozilla-beta/rev/b746eaca3b44cb1c2649d868cc61b8d32dbcea85
Updated•1 year ago
|
Comment 17•1 year ago
|
||
Actually, it's still fixed in 123, backout was only for beta 122.
Updated•1 year ago
|
Comment 18•1 year ago
|
||
MDN docs for this can be tracked in https://github.com/mdn/content/issues/31928 - affected by answer to https://bugzilla.mozilla.org/show_bug.cgi?id=1871745#c13
Updated•1 year ago
|
Description
•