1483700 - Mousewheel intermittently not scrolling

Status: RESOLVED INVALID

(Core :: Panning and Zooming, defect)

Description

[Katelyn Gadd (:kael)]

I'm looking at a sqlite page and intermittently mousewheel events are not scrolling. It only seems to apply to this page, and it persists if I restart FF. "Intermittently" because if I spin the wheel, it will not scroll and then suddenly start scrolling, then stop again. Mousewheel scrolling is working fine in every other tab.

I don't see anything in the page's css to explain this. It does have an embedded iframe, but it doesn't seem like my cursor position has any impact on whether it scrolls. Focus doesn't seem to matter either.

Comment 1

[Katelyn Gadd (:kael)]

Attachment: Screen recording

Attaching a screen recording. In this video I am spinning the mousewheel constantly, and then once it actually finishes scrolling I reverse directions. You can see the scrolling randomly stops even though there is no obvious reason for it to stop - I am spinning in the correct direction to continue scrolling, and it eventually resumes.

This problem persists even if I make the window wide enough to eliminate the duplicate (iframe?) scrollbar. So maybe it is a nested iframe problem. Maybe the size computation is wrong in the logic that handles scrolling? The visible scrollbar looks right.

Comment 2

[Botond Ballo [:botond]]

The behaviour depicted in the video is expected. It's an interaction between the somewhat odd page structure, and Firefox's "transaction" model for mouse wheel processing.

The page contains an iframe whose height (not the height of the content inside the iframe, but the height of the iframe element itself) is taller than the browser window. As a result, the browser window is scrollable, so that you can see the entire iframe element by scrolling.

The content inside the iframe is itself taller than the iframe element, so the iframe is itself scrollable. As a result, you get two nested scrollable elements: the browser window, and the iframe.

(The part that's "odd" about this is that making the iframe taller than the browser window doesn't seem to serve any purpose. On the other hand, it creates an awkwardly tall scrollbar, and unnecessarily introduces a nested scrollable element. A more usual arrangement would be to size the iframe to take up the available vertical space in the browser window, so that only the iframe, and not the browser window, is scrollable.)

In the video, your mouse starts above the top edge of the iframe element. On the first mouse-wheel event at this location, Firefox does a hit-test to see which scrollable element should be scrolled. At that time, only the browser window is under the cursor, so it is selected, and we scroll that.

Subsequent mouse-wheel events are grouped into the same "wheel transaction" as the first one, so no separate hit-test is performed for them, and we continue scrolling the browser window.

Once we reach the bottom of the browser window, the browser notices that the wheel events are no longer causing scrolling, and starts a timer to "time out" the wheel transaction. The timeout is 1.5 seconds long, during which time nothing is scrolling.

Once the transaction is "timed out", the next wheel event triggers another hit-test. By this time, the scrolling of the browser window has moved the iframe such that it is now under the cursor. So there are two scrollable elements under the cursor: the iframe, and the browser window. We prefer the innermost one that is scrollable in the given direction, which in this case is the iframe. Therefore, a new wheel transaction is started, and subsequent wheel events scroll the iframe, until you reach the bottom.

When you switch the direction of scrolling, a new transaction is again started, and the iframe is again chosen as the scroll target, so subsequent wheel events scroll the iframe upwards, until it reaches the top. Note, at this time the browser window is still scrolled to the bottom, so you don't actually see the top of the iframe.

At this point, the wheel transaction again takes 1.5 seconds to time out, at which point we do another hit-test, choose the browser window as the scroll target (since the iframe is not scrollable further in that direction), and scroll the browser window upwards.

If you pay attention to which of the two scrollbars is moving at a given time, it's fairly easy to see what is happening. The "pause" is always when movement switches from one scrollbar to the other.

The wheel transaction timeout has been around for a very long time, and it's a deliberate design choice. The motivation is so that if you're e.g. scrolling a textbox and the surrounding content is also scrollable, and you get to the end of the textbox, the scroll isn't immediately handed off to the surrounding content (since you probably intended to just get to the beginning/end of the textbox).

Note that waiting 1.5 seconds is not the only way to time out a wheel transaction; moving the mouse also accomplishes it, so if you were to move the mouse at the beginning of the "pause" periods, the pause will no longer occur.

To sum up, I don't believe there's anything to fix here. Using a more typical page structure (e.g. making the iframe fit into the browser window height so there's only one scrollable element on the page, as suggested above) will result in more typical scrolling behaviour.