Consider using WhereToScroll::Center consistently for focus.
Categories
(Core :: Layout: Scrolling and Overflow, defect)
Tracking
()
People
(Reporter: emilio, Unassigned)
References
Details
Attachments
(1 file)
|
224 bytes,
text/html
|
Details |
I don't understand why bug 1818126 only changed the keyboard case? Chromium seems to do this also for .focus() and so on, see test-case.
I think if we do this, we should do it consistently? In particular, .focus() sometimes is used by pages to emulate keyboard scrolling, and it's super-weird having inconsistent behavior there when the page handles the key event itself vs. not.
|
||
Comment 1•1 year ago
|
||
I think this is a dup of bug 1842679? There's some talk in https://phabricator.services.mozilla.com/D182930 about why this was separated, but I didn't dig into it much.
|
Reporter | |
Comment 2•1 year ago
|
||
Pushed to try here. There may be more failures due to the change in behavior for Element.focus(). Long term, it is probably a good idea to use WhereToScroll::Center for Element.focus() as well as tab scrolls, but if we'd like to slowly transition to this, that might limit the churn in tests
Ah, sorry, I did miss that discussion. I think we should not ship the inconsistent behavior tho.
|
||
Comment 3•1 year ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #2)
Pushed to try here. There may be more failures due to the change in behavior for Element.focus(). Long term, it is probably a good idea to use WhereToScroll::Center for Element.focus() as well as tab scrolls, but if we'd like to slowly transition to this, that might limit the churn in tests
Ah, sorry, I did miss that discussion. I think we should not ship the inconsistent behavior tho.
That's my bad. I probably should have mentioned something here. The discussion happened in the last evening standup.
Description
•