Scroll position incorrect/stuck after reparenting scrollable element
Categories
(Core :: Panning and Zooming, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox-esr78 | --- | unaffected |
firefox80 | --- | wontfix |
firefox81 | --- | wontfix |
firefox82 | --- | wontfix |
firefox83 | --- | wontfix |
firefox87 | --- | wontfix |
firefox88 | --- | wontfix |
firefox89 | --- | wontfix |
firefox90 | --- | fixed |
People
(Reporter: brzezbugzilla, Assigned: kats)
References
(Regression)
Details
(Keywords: regression)
Attachments
(3 files, 1 obsolete file)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:79.0) Gecko/20100101 Firefox/79.0
Steps to reproduce:
- Scroll down to the very bottom of the scrollable element you're going to reparent.
- Reparent the element.
3a. Try clicking on the children of the reparented container and observe which elements triggered click events.
3b. Try scrolling down with the mousewheel on the scrollable, reparented container.
Actual results:
4a. Click handler is tiggered on a different element than currently visible and the one user clicked on.
4b. Can't scroll down.
Expected results:
5a. Click handler should have been triggered on the element the user has clicked on.
5b. Users should be able to scroll down.
Managed to reproduce on Firefox versions 79, 80, 81 in Windows 10. Also reproduced in Windows , Browserstack.
Seems like internally the scrollable element scrolls to the top on reparenting, and
a) The container is not redrawn, and the Browser visually still presents the old scroll position.
b) Sometimes the content does get redrawn, but the scrollbar is stuck in a botton position and you're unable to scroll down, unless you scroll up first.
Codepen:
https://codepen.io/barbrzez/pen/dyMzqLG
Steps to reproduce in codepen: scroll down on the LHS element, click 'Reparent' button. Try clicking on an element in reparented container. An alert should be triggered with text from the element clicked.
It's either incorrect, or if it's correct - you may not be able to scroll down with mouse wheel.
Reporter | ||
Comment 1•4 years ago
|
||
Also, I cannot reproduce it when Developer Tools are open.
Comment 2•4 years ago
|
||
Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=78301c2498bf22f4f19ae78a4e07ed9861e0931b&tochange=cc8881b3128c07537ad0c9c0a0dd35b0d9ce8a99
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 3•4 years ago
|
||
Assignee | ||
Comment 4•4 years ago
|
||
Whoops, uploaded the wrong file last time.
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 6•4 years ago
|
||
This is fixed in Nightly now, but I'll use this bug to land a test for the scenario.
Updated•4 years ago
|
Assignee | ||
Comment 7•4 years ago
|
||
Finally getting around to this. I rolled back my m-c clone to before bug 1662013 landed, and wrote the test, verifying that it fails (locally):
https://github.com/staktrace/gecko-dev/commits/test_bug1662379
And that it passes after rebasing it on top of bug 1662013 (again, locally):
https://github.com/staktrace/gecko-dev/commits/test_bug1662379-fixed
Now I'm gonna rebase it back to master and ensure it passes reliably.
Assignee | ||
Comment 8•4 years ago
|
||
Assignee | ||
Comment 9•4 years ago
|
||
The events being listened for here are mouse events, all of which
go through both the bubble and capture phases. It's not clear to
me why I originally added this listener in the capture phase; it
is more useful in the bubble phase because then it resolves the
promise after the event has triggered listeners registered on the
target element, rather than before.
Note also that prior to the promis-ification of this function, the
callback was called inside a setTimeout(0) wrapper, which would
automatically have deferred the callback to after the event dispatch
was completed. So technically the promis-ification of this function
introduced a functional change because now the promise can get
resolved before the event dispatch is complete, and in particular,
before listeners on the target element get run. This didn't affect
anything in practice because none of the existing callers actually
have such a listener on the target element. The next patch adds
one though, and exposed this behaviour difference when I rebased it
across the promis-ification change..
This patch removes the capture:true listener option, causing the
listener to get registered in the bubble phase.
Assignee | ||
Comment 10•4 years ago
|
||
Depends on D112500
Comment 11•4 years ago
|
||
Comment 12•4 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/8320808e8552
https://hg.mozilla.org/mozilla-central/rev/74717197a43a
Updated•4 years ago
|
Description
•