Closed Bug 1480261 Opened 3 years ago Closed 3 years ago

scrollIntoView({ block: 'center' }) sometimes scrolls an unrelated container


(Core :: Panning and Zooming, defect, P3)




Tracking Status
firefox63 --- affected


(Reporter: birtles, Unassigned)




(1 file, 2 obsolete files)

Attached file Test case (obsolete) —
I'm having a really hard time creating a reliable reduced test case but I'm seeing this bug occur fairly often in an app I'm creating when running on a low-end Windows machine and on Fennec.

This test case sometimes produces a situation where it seems like the outer scroll frame gets scrolled leaving part of the page inaccessible.

There seems to be some race between the transform animation and scroll calculations.

The app where this is occurring is but that page will likely change over time. I _think_ the attached test case has all the right ingredients to reproduce but I'm not entirely sure.

I've never once been able to reproduce this on a higher-end Linux machine. Somedays it works fine on Fennec, and some days it is 100% reproducible on Fennec. On my lower-end Windows machine it happens about 30~40% of the time (but again, some days not at all, some days all the time). When it does happen, however, it makes the app entirely unusable so it's pretty severe.
Attached file Test case (obsolete) —
Add viewport scaling
Attachment #8996882 - Attachment is obsolete: true
Attached file Test case
Make height a little smaller
Assignee: nobody → bbirtles
Assignee: bbirtles → nobody
Attachment #8996885 - Attachment is obsolete: true
Yeah, that test case doesn't reproduce for me now on Fennec. But it does behave completely differently to desktop (not scrolling at all) so maybe it's related anyway.

To be clear, when it has reproduced, you'd find one of the top boxes cut-off and be unable to scroll to it.
I tried digging into this a little further. In the actual app, it seems like it is triggered by the background screen being scrollable (hence you won't be able to reproduce unless you create enough content for it to become scrollable).

Furthermore, I've noticed it has nothing to do with animation. I can disable the animation and still get the odd result.

I think all that is happening is that the default behavior for scrollIntoView is block: 'center', and it is being a bit too eager to meet that demand, so it is scrolling a parent container in a manner it probably shouldn't (the child is abspos so there's no kind of general scrolling that would produce the given result).

This might be invalid but it would be nice to get a reduced test case so we can check that.
Summary: scrollIntoView({ behavior: 'smooth' }) plus OMTA transform animations sometimes results in scrolling to the wrong place → scrollIntoView({ block: 'center' }) sometimes scrolls an unrelated container
I can repro different behaviour on FF desktop vs android. FF desktop behaves the same as Chrome, so I'm assuming it's Fennec's behaviour that needs fixing.
OS: Unspecified → Android
Priority: -- → P3
A lot of Fennec vs. desktop scrolling differences that have come up recently have been due to containerful vs. containerless scrolling. We have plans to get rid of containerful scrolling (bug 1459312), once we do that it's worth re-testing bugs like these to see if it fixes the issue.
No longer depends on: 1459312

Hey Brian, have you seen this recently (in 68 nightly or 67 beta)?

Flags: needinfo?(bbirtles)

No, but I changed the app quite some time ago to use { block: 'nearest' } and from memory that was less problematic.

Flags: needinfo?(bbirtles)

Thanks. I think it makes sense to close this as "WORKSFORME" until someone runs into it again.

Closed: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.