1515255 - Overflow:auto from overflow:hidden in firefox is triggering a scroll event

Status: RESOLVED DUPLICATE of bug 1590247

(Core :: Layout, defect, P2)

Description

[akshay.kochhar3]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

Steps to reproduce:

https://stackoverflow.com/questions/53608738/overflowauto-from-overflowhidden-in-firefox-is-triggering-a-scroll-event


Actual results:

There was a scroll event in case we scrolled the contetnt a bit and the overflow is changed from hidden to auto in later cases

Comment 1

[akshay.kochhar3]

Any update on this issue?

Comment 2

[santroshg]

hello team is there any update on this defect?

Comment 3

[m@tias]

Hello dreamteam, any update on this issue?

Comment 4

[Emilio Cobos Álvarez [:emilio]]

Attachment: Test-case from the stackoverflow question

Comment 5

[Emilio Cobos Álvarez [:emilio]]

That test-case doesn't reproduce the issue anymore. Does anyone have a repro?

Comment 6

[m@tias]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #5)

That test-case doesn't reproduce the issue anymore. Does anyone have a repro?

Hi Emilio,
I do, but no willing to place it here as it's a live website and I'm working on a 'workaround'.
Can I send you through a more private channel? (email, discord, slack...)

Comment 7

[Emilio Cobos Álvarez [:emilio]]

It'd be great if you could create a test-case for the behavior you're seeing which could be made public, but if you definitely can't then sure, feel free to email it to me or what not.

Comment 8

[m@tias]

I know, I'll try to reproduce a use case for public knowledge.
In the meanwhile, I'm sending you a 'working' bug on a live site. (I'm not the owner therefore I'm avoiding making it public, hope you all understand)

Comment 9

[Peter Magyari (Desktop QA)]

Hi Matias,

Were you able to create a valid test-case for the issue/behaviour you are seeing?

Does the issue still occur on the live website ?
If so, please send it to me via email.

Thanks!

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:dholbert, since the bug has high priority and high severity, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 11

[Daniel Holbert [:dholbert]]

I was able to reproduce this with the attached testcase, in old Nightlies, but it's essentially fixed in current Nightlies, and was fixed with this pushlog (via bug 1590247 which makes sense):
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=d41beebcfe89dfac9ce39cdf1f4d6a2819b1e840&tochange=16504649f4893ace8dcc78da4900e546f610fe1f

--> Duping to bug 1590247 since that seems to have fixed things.

I can still reproduce a less-bad version of this bug when I scroll all the way to the end, but I can also reproduce that issue in Chrome as well, so I think that remaining issue is not a Firefox-specific.

[more details coming in a subsequent comment]

Comment 12

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (variety of widths)

Comment 13

[Daniel Holbert [:dholbert]]

I've got two sets of STR here for two different experiments. In all cases, you should first choose "Always show scrollbars" in Firefox Preferences (i.e. disable overlay scrollbars), so that so that scrollbars actually take up space and force relayout when you hover the testcase. Without that, we have an unfair advantage & might give expected-results for un-interesting reasons.

EXPERIMENT A (the original bug, I think):
(Make sure you have your browser configured to use traditional i.e. non-overlay scrollbars. ("always show scrollbars"))

1. Load the original testcase
2. Ctrl+Shift+K to open web console.
3. Click in the yellow box.
4. Press downarrow on your keyboard to scroll down a few lines. (Notice that "scroll is called" logging appears in your web console -- repeatedly, coalesced together with a count shown at the right.)
5. Hover/un-hover the yellow box.

ACTUAL RESULTS:
In step 5, the logging count goes up by 1 for each hover/un-hover action.

EXPECTED RESULTS:
Count shouldn't go up (i.e. we shouldn't be sending scroll events).

Chrome and recent Firefox versions (with bug 1590247's patches) give EXPECTED RESULTS in this experiment.
Older Firefox versions (before bug 1590247's patches) give ACTUAL RESULTS in this experiment.

---

EXPERIMENT B:
(Make sure you have your browser configured to use traditional i.e. non-overlay scrollbars. ("always show scrollbars"))

1. Load testcase 2
2. Ctrl+Shift+K to open web console.
3. Hover the first yellow box and mousewheel-scroll to the end.
   (Notice that "scroll is called" logging appears in your web console -- repeatedly, coalesced together with a count shown at the right.)
4. Un-hover the box. (And then try hovering and un-hovering again.)
5. Repeat steps 3 and 4 for the other boxes.

ACTUAL RESULTS IN FIREFOX:
For some boxes, in step 4, the "scroll is called" log-count goes up by 1 when you first un-hover after reaching the end. However, it doesn't go up any more on subsequent hover/un-hover actions.

ACTUAL RESULTS IN CHROME:
Same as Firefox (possibly for a different set of boxes), plus, the log-count continues going up as you hover/un-hover.

I think in Experiment B, the key thing that impacts whether a particular yellow-box triggers the 'actual results' or not is simply whether or not a linewrap gets triggered (whether text gets pushed off the end of the final line when space gets stolen for the scrollbar). When this happens, it means the scrollable height is larger when you're hovering, and shorter when you're not hovering. This happens for different yellow-boxes in Firefox vs. Chrome, due to differences in fonts / scrollbar-sizing. For the purposes of this experiment, you want to be using one of the boxes that does this line-rewrapping.

I think both "actual results" behaviors are reasonable, and they reflect the difference in "scroll anchoring" behavior, essentially.

Here's what I think is happening...
In both Firefox and Chrome:

• When you hover and scroll to the end, you end up with a large scrollTop (matching the larger hovered scroll-height)
• Then when you un-hover, the scrollable distance goes down (as the lines rewrap to a shorter height) and the scrollTop reduces. This produces a scroll event which the testcase logs (at the start of step 4).

Then when you hover again, the browser rewraps the lines to produce the larger scrollHeight, and then Firefox/Chrome differ slightly on what to do:

• Firefox preserves your scroll position as encoded in scrollTop; the newly created line gets pushed off the bottom. This means no scroll event is generated because the scroll position didn't change.
• Chrome preserves your scrolled-to-the-very-end status, i.e. they increase scrollTop so that the newly-created-line is fully visible at the bottom of your scrollport. This means they are changing scrollTop and so a scroll event gets generated.

Comment 14

[Daniel Holbert [:dholbert]]

I spun off bug 1777619 for what I think is the core difference that EXPERIMENT B is hitting.

(I think that's distinct from the originally-reported issue here, so I think we're still good to consider this closed/fixed.)