Element.focus() should scrollIntoView with block/inline set to "center" when a scroll is needed
Categories
(Core :: Layout: Scrolling and Overflow, task, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox117 | --- | fixed |
People
(Reporter: dlrobertson, Assigned: dlrobertson)
References
(Regressed 1 open bug)
Details
Attachments
(3 files)
Summary
When Element.focus() is used, the element should be scrolled into view such that the element is centered when the scroll completes
Steps to reproduce
- Navigate to the attached test case
- Click the "Focus" button
- Observe the position of the red element
Expected results
The red element should be in the center of the viewport
Actual results
The red element is at the very bottom of the viewport
Discussion
This is technically allowed by the spec, as dom-focus states:
... block flow direction position set to an implementation-defined value, and inline base direction position set to an implementation-defined value.
However, both chrome and safari both use block: "center"
and inline: "center"
. This might make it worthwhile to update to the same behavior as chrome and safari. In particular Element.focus()
is used in some web-platform-tests. It may be that we fail or pass for invalid reasons due to our behavior here.
Comment 1•2 years ago
|
||
This will some impacts where documents depend on our current behavior.
Comment 3•2 years ago
|
||
I think we should do this in this release cycle, wdyt? It'd be bad shipping inconsistent behavior between keyboard and regular .focus()
, in particular because script focus is commonly used by pages to implement custom keyboard / mouse behavior.
Assignee | ||
Comment 4•2 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #3)
I think we should do this in this release cycle, wdyt?
Yeah, I can try to get this done. There were quite a few tests that expect the current behavior of Element.focus()
, but that makes this a reasonable background task to work on. If I don't make it to the top of the try highscores chart, I'll be disappointed :p
It'd be bad shipping inconsistent behavior between keyboard and regular
.focus()
, in particular because script focus is commonly used by pages to implement custom keyboard / mouse behavior.
Is this severe enough to warrant feature gating or backing out the current fix for keyboard scrolls?
Comment 5•2 years ago
|
||
(In reply to Dan Robertson (:dlrobertson) from comment #4)
Is this severe enough to warrant feature gating or backing out the current fix for keyboard scrolls?
I think we should avoid shipping the inconsistent behavior yes.
Comment 6•2 years ago
|
||
At a glance try doesn't seem that unhappy:
- https://treeherder.mozilla.org/jobs?repo=try&revision=68a0a4e7c8cad02fa5e29e0ab830d6d991738040
- https://treeherder.mozilla.org/jobs?repo=try&revision=768d27c9738c805ae992e0eafa8ecea971218b8b (a more complete try run)
I can take this I guess, if you're busy with other stuff.
Comment 7•2 years ago
|
||
Assignee | ||
Comment 8•2 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #6)
I can take this I guess, if you're busy with other stuff.
I have time to work on it and I have an old revision that also changed the behavior of Element.focus()
and fixed some of the tests... Most of them were reasonably easy fixes.
Comment 9•2 years ago
|
||
Ah, alright then! Feel free to steal :)
Updated•2 years ago
|
Assignee | ||
Comment 10•2 years ago
|
||
Element.focus() now centers an element in the block and inline
directions when the element should be scrolled into view. Update tests
to account for this.
Comment 11•2 years ago
|
||
Comment 13•2 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/f02a0e3200b0
https://hg.mozilla.org/mozilla-central/rev/7ffbd7298f7b
Description
•