Scroll anchoring stops working when focusing an editable element
Categories
(Core :: Layout: Scrolling and Overflow, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox148 | --- | fixed |
People
(Reporter: marijnh, Assigned: hiro)
References
Details
Attachments
(3 files)
When content is inserted/deleted above the current viewport, Firefox will anchor the scroll position so that the visible content doesn't jump around. However, the anchoring seems to stop happening when the user focuses a contenteditable element. Attached HTML page demonstrates this—the view is stable initially, but starts shifting as soon as you focus the content.
See also https://bugzilla.mozilla.org/show_bug.cgi?id=1971861 , though that one seems to talk about anchoring within editable elements, and the problem here also occurs when content is inserted above the element. Focusing it seems to turn off anchoring altogether.
|
||
Comment 1•10 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Layout: Scrolling and Overflow' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
Assignee | |
Comment 2•10 months ago
|
||
It works for me.
|
||
Comment 3•10 months ago
|
||
The testcase reproduces the problem for me. Specifically, the content stays still on the page for me, until I click on the text to focus it, then the context steadily moves down.
|
|
Assignee | |
Comment 4•10 months ago
|
||
Yeah, I didn't click anything, I was just trying to scrolling it. :/
With the attached file, you don't need to click at all.
|
|
||
Comment 5•9 months ago
|
||
The severity field is not set for this bug.
:hiro, could you have a look please?
For more information, please visit BugBot documentation.
|
||
Updated•9 months ago
|
|
|
Assignee | |
Comment 6•6 months ago
|
||
This is due to overflow-anchor: none property on the contenteditable element so that any descendants of the element will never be the target of scroll anchoring.
The property was introduced in bug 1583135.
Masayuki do you have any idea to workaround this bug? Thanks!
|
|
Assignee | |
Comment 7•6 months ago
|
||
I am confused what bug 1583135 was.
There's a test case in bug 1583135 comment 5 and a STR in bug 1583135 comment 6.
But I can see the same behavior with/without the overflow-anchor: none for the contenteditable.
|
|
Assignee | |
Comment 8•6 months ago
|
||
FWIW what I am seeing is that no scroll position change happens when hit Enter key. It stays at the top.
|
|
Assignee | |
Comment 9•6 months ago
|
||
Okay I can see bug 1583135 on 2022-01-01 nightly. Now I am pretty sure that bug 1583135 can not be observed without overflow-anchor:none.
|
||
Comment 10•6 months ago
|
||
Something was changed after bug 1583135? If the style is not required anymore, we can just revert the patch.
|
|
||
Comment 11•6 months ago
|
||
Otherwise, we could put a stack only class into a Maybe instance which prevents the anchoring and emplace it after dispatching beforeinput and reset before dispatching input event.
|
|
Assignee | |
Comment 12•6 months ago
|
||
Even without overflow-anchor: none for contenteditable, I confirmed
bug 1583135 doesn't happen.
There's already a web platform test for this specific bug,
contenteditable-near-cursor.tentative.html is the one.
contenteditable-insert-line-at-top.tentative.html is a new test, but
its purpose is replicating a scenario of bug 1583135, it's not a test
testing that this change doesn't regress bug 1583135. As per a note
by Masayuki [1] when he tried to write an automated test for bug 1583135,
synthesized events didn't hit the condition causing the bug, thus this test
probably doesn't hit the exact condition either. So, this test is just
for a future reference.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1583135#c27
|
||
Updated•6 months ago
|
|
||
Comment 13•6 months ago
|
||
|
||
Comment 15•6 months ago
|
||
| bugherder | ||
|
||
Updated•6 months ago
|
Description
•