1894228 - [X11] Webpage not scrollable with mouse wheel, still with arrow keys and middle click

Status: RESOLVED FIXED

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

Description

[Manuel Bucher [:manuel]]

Attachment: about:support.txt

I don't know how to debug. Second time this happened. First time I think was yesterday.

Scroll with mouse wheel works correctly in other applications (like Nautilus file manager). Only scroll up and scroll down doesn't have any effect. Scrolling with other keys (PageUp, PageDown, Space, ArrowUp, ArrowDown, Middle Click for Autoscroll) all still work normally.

Reporting new bug, because this is likely new. I still have the browser open, so if you know how to debug in the next few hours, I can try various things.

Comment 1

[Emilio Cobos Álvarez [:emilio]]

I assume this is similar to other bug you've seen open that has been closed or something? If so it'd be worth linking to it.

Comment 2

[Manuel Bucher [:manuel]]

I don't remember reporting similar bugs. I did submit some GTK related crashes:

• Bug 1782522
• Bug 1793922

I'll see if I can find some more related bugs reported by others.

Comment 3

[Manuel Bucher [:manuel]]

Bug 1863194 looks like it could have changed this behavior? (maybe not)

ctrl + mouse wheel still works for zooming in/out.
Edit: also alt + mouse wheel still scrolls through history.

Comment 4

[Hiroyuki Ikezoe (:hiro)]

I highly suspect this is a dup of bug 1877972.

Comment 5

[Botond Ballo [:botond]]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #4)

I highly suspect this is a dup of bug 1877972.

In that bug, we added some logging to help diagnose the underlying issue further (but we haven't had a reproduction of the issue in that bug since the latest logging was added).

Manuel, if the issue occurs again, could you enable the following log modules in about:logging:

apz.controller:5,apz.inputqueue:5,apz.inputstate:5,apz.manager:4,apz.scrollanimation:4,apz.msd:4

and take a profile while trying to scroll the affected tab?

That would be really helpful for tracking this issue down!

Comment 6

[Simon]

I have the same problem, but not on all web pages.
For example, doing a google search for "turnip", the search results are NOT scrollable with the mousewheel, but are with the cursor keys or dragging the scroll bar. https://www.google.com/search?channel=fs&client=ubuntu-sn&q=turnip
But many other pages, such as https://www.bbc.co.uk/ or https://stackoverflow.com/ work just fine.

The problem is present in debug mode, and also on a recent Firefox Nightly version.

Running Ubuntu 23.10 Gnome desktop, with Ubuntu kernel 6.5.0-28-lowlatency #29.1-Ubuntu SMP PREEMPT_DYNAMIC

Comment 7

[Manuel Bucher [:manuel]]

@Simon, if you can still reproduce. Can you do steps outlined in comment 5 recording a log and attaching it to this bug?

Comment 8

[Simon]

The problem is consistently reproducible for me; in that regard it looks to be different from bug 187792.
I will try and enable the logging as per comment 5 , bear with me...

(In reply to Simon from comment #6)

I have the same problem, but not on all web pages.
For example, doing a google search for "turnip", the search results are NOT scrollable with the mousewheel, but are with the cursor keys or dragging the scroll bar. https://www.google.com/search?channel=fs&client=ubuntu-sn&q=turnip
But many other pages, such as https://www.bbc.co.uk/ or https://stackoverflow.com/ work just fine.

The problem is present in debug mode, and also on a recent Firefox Nightly version.

Running Ubuntu 23.10 Gnome desktop, with Ubuntu kernel 6.5.0-28-lowlatency #29.1-Ubuntu SMP PREEMPT_DYNAMIC

Comment 9

[Simon]

Attachment: log.txt-main.129729.moz_log

as requested, per comment 5.

• Updated to latest Nightly version
• Set Debug mode
• Opened private window
• Entered "turnip" in google search field
• opened new tab, (blank page), entered about:logging.
• set log modules: apz.controller:5,apz.inputqueue:5,apz.inputstate:5,apz.manager:4,apz.scrollanimation:4,apz.msd:4
• Set Log file
• Clicked Start logging
• Clicked on tab containing turnip search results
• moved to blank area to right of text and did a down-scroll then an up-scroll with my mouse wheel - no visible response.
• tapped down-arrow key twice, then up-arrow twice - page scrolled as expected
• clicked on about:logging tab and stopped logging
• attached log file

Comment 10

[Manuel Bucher [:manuel]]

Thanks Simon for creating the log. Botond, do you gain useful information from the log or do you need more information?

Comment 11

[Botond Ballo [:botond]]

The log in comment 9 suggests that what's happening is similar to Julien's issue in bug 1877972 (as discussed in bug 1877972 comment 25 and bug 1877972 comment 27). (And different from Paul's issue in bug 1877972, which is the one related to MSD scroll physics.)

For every wheel event, I'm seeing a sequence of log messages like this:

[Parent 129729: Main Thread]: D/apz.manager Received wheel input at (1632,631) with delta (0.000000, 3.000000)
[Parent 129729: Main Thread]: D/apz.manager Hit-testing point (1632,631) with WR
[Parent 129729: Main Thread]: D/apz.manager Examining result with guid { l=0x100000023, p=0, v=2 } hit info 0x5... 
[Parent 129729: Main Thread]: D/apz.manager selecting as chosen result.
[Parent 129729: Main Thread]: D/apz.manager Successfully matched APZC 75be1820c800 (hit result 0x5)
[Parent 129729: Main Thread]: D/apz.inputqueue got a target apzc; block=310 guid={ l=0x100000023, p=2, v=2 }
[Parent 129729: Main Thread]: D/apz.inputstate 75be1737fba0 replacing unconfirmed target 75be1820c800 with real target 0

• The hit result 0x5 tells us the input block will wait for a target confirmation from the main thread
• The got a target apzc line tells us the target confirmation arrives, and the confirmed target matches the initial one (v=2)
• However, the unconfirmed target ... with real target 0 tells us that the actual target retained on the input block has been swapped out for null

As discussed in bug 1877972 comment 25, this can happen if BuildOverscrollHandoffChain()->FindFirstScrollable() returns null, which can happen if APZ thinks nothing under the cursor is scrollable in the direction the wheel event is trying to scroll.

At this time, the page is scrolled to the top, so this outcome is expected for an upward wheel scroll, but unexpected for a downward wheel scroll.

However, I see wheel scrolls in both directions in the log, i.e. both with a positive vertical delta of 3 as above, and with a negative vertical delta:

[Parent 129729: Main Thread]: D/apz.manager Received wheel input at (1632,631) with delta (0.000000, -3.000000)

and both lead to the same outcome, suggesting that for some reason APZ thinks the page is not scrollable downward, either. It's not clear to me from the log why that might be.

Leaving needinfo on me while I think of next diagnostic steps.

Comment 12

[Botond Ballo [:botond]]

As an aside, I also see messages like this:

[Parent 129729: Main Thread]: D/apz.manager Received wheel input at (1633,631) with delta (3.000000, 0.000000)

and

[Parent 129729: Main Thread]: D/apz.manager Received wheel input at (1632,631) with delta (-3.000000, 0.000000)

suggesting APZ is also getting wheel events with horizontal deltas.

That's a bit odd, as a typical mouse wheel can't produce those, unless you have Shift held down.

But anyways, for these events, being dropped is the expected outcome since the page is not scrollable horizontally.

Comment 13

[Botond Ballo [:botond]]

Simon, this is a bit of a shot on in the dark but do you have any custom mousewheel-related preferences?

Two places to check are:

• In about:support, in the section titled "Important Modified Preferences", are there any with "mousewheel" in their name?
• In about:config, if you type "mousewheel" into the search box, and scroll through the list of prefs with that in the name, are there any in bold?

Comment 14

[Simon]

(In reply to Botond Ballo [:botond] from comment #13)

Simon, this is a bit of a shot on in the dark but do you have any custom mousewheel-related preferences?

Two places to check are:

• In about:support, in the section titled "Important Modified Preferences", are there any with "mousewheel" in their name?
• In about:config, if you type "mousewheel" into the search box, and scroll through the list of prefs with that in the name, are there any in bold?

In about:support, there is no text containing "mouse" at all.
In about:config, none of the "mousewheel" options are bolded.

As an experiment, I tested on a mouse-scroll-failing page whether it made any difference if I held the shift key down while attempting to scroll - it didn't.

Comment 15

[Simon]

(In reply to Simon from comment #14)

(In reply to Botond Ballo [:botond] from comment #13)

Simon, this is a bit of a shot on in the dark but do you have any custom mousewheel-related preferences?

Two places to check are:

• In about:support, in the section titled "Important Modified Preferences", are there any with "mousewheel" in their name?
• In about:config, if you type "mousewheel" into the search box, and scroll through the list of prefs with that in the name, are there any in bold?

In about:support, there is no text containing "mouse" at all.
In about:config, none of the "mousewheel" options are bolded.

As an experiment, I tested on a mouse-scroll-failing page whether it made any difference if I held the shift key down while attempting to scroll - it didn't.

I also clicked on various parts of the page before trying to mouse-scroll. No difference.
But please note that the cursor up- and down-arrow keys, and also the PgDn and PgUp keys, work as expected.

Comment 16

[Botond Ballo [:botond]]

We discussed this in today's APZ meeting. As the symptoms are fairly severe we are marking this an S2.

I'm at a bit of a loss as to how the failure mode discussed in comment 11 can arise, but we can put in place some more logging to help narrow down the issue further.

Comment 17

[Botond Ballo [:botond]]

Attachment: Bug 1894228 - Add some logging to the functions that calculate whether a given wheel event can scroll an APZC. r=hiro

Comment 18

[Botond Ballo [:botond]]

I posted a patch which adds some logging. Once this makes it into a nightly, I will ask anyone who can reproduce the issue to test again.

By the way, Simon, is this something you only see in Firefox Nightly, or did you see it in the release version as well?

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a75ead8dedac
Add some logging to the functions that calculate whether a given wheel event can scroll an APZC. r=hiro

Comment 20

[Aron Cseh]

https://hg.mozilla.org/mozilla-central/rev/a75ead8dedac

Comment 21

[Simon]

(In reply to Botond Ballo [:botond] from comment #18)

I posted a patch which adds some logging. Once this makes it into a nightly, I will ask anyone who can reproduce the issue to test again.

By the way, Simon, is this something you only see in Firefox Nightly, or did you see it in the release version as well?

It's in the released version too - "123.0.1 (64 bit) Mozilla Firefox snap for Ubuntu canonical-002 - 1.0"

Comment 22

[Botond Ballo [:botond]]

Thanks. The latest nightly version (2024-05-09) contains new logging I've added to try to narrow down the issue. If you're able to reproduce it using this nightly, could you please share an updated set of logs, taken the same way as in comment 9?

Comment 23

[Simon]

Well, blow it - the fault has disappeared! I can't make it happen on any of the Firefox versions and web pages that were failing before, the mousewheel does exactly what one would expect!

There was a routine Ubuntu system update that required a reboot, and this is not inconsistent with the disappearance of the fault.

Are there any /var/log/apt files that would be useful to attach? Shall I proceed with the repeat of the previous test anyway?

Comment 24

[Botond Ballo [:botond]]

(In reply to Simon from comment #23)

Shall I proceed with the repeat of the previous test anyway?

I don't think the logs will tell us anything interesting if the issue isn't actually occuring.

The logging will remain in the code though, so if/when the issue does happen again, attaching logs should help us diagnose it further.

(Manuel, likewise for you, if it happens again please do share logs.)

Comment 25

[Botond Ballo [:botond]]

(Bumping this to S3 until we get a new reproduction and log.)

Comment 26

[Botond Ballo [:botond]]

We did get a new reproduction and log (see bug 1877972 comment 42, and subsequent analysis in comments 43-50), and I believe we have enough information to proceed with a fix.

I will use this bug for the fix, and bump it back to an S2.

Comment 27

[Botond Ballo [:botond]]

While trying to write a test for this, I realized that the diagnosis in bug 1877972 comment 49 was incomplete.

Getting a mixture of wheel events with horizontal and vertical deltas (as might be produced by a diagonal motion on a touchpad), on a page with a non-passive wheel event listener, in and of itself is not sufficient to trigger the bug.

If the target confirmations from the main thread are interspersed with the events, e.g.:

1. Receive wheel event with horizontal delta
2. Confirm target of wheel event
3. Receive wheel event with vertical delta
4. Confirm target of wheel event

Then we avoid the bug by hitting this code at step (2), which ends the transaction, allowing the second wheel event at step (3) to start a new transaction and successfully trigger scrolling at step (4).

Rather, the bug only occurs if the main thread is kind of slow to respond, and the sequence of events is more like:

1. Receive wheel event with horizontal delta
2. Receive wheel event with vertical delta
3. Confirm target of first wheel event
4. Confirm target of second wheel event

Now, at step (2) we've already added the second wheel event to the existing transaction started by the first wheel event. When we then determine the target of that wheel transaction at step (3) based on the direction of the first event to be null, we end up dropping all the events in the transaction.

This does mean that only wheel events that arrive prior to the confirmation of the first event get dropped, which makes the bug harder to trigger (and probably explains the low reproduction rate I experienced on my testcase, which doesn't have anything slowing the main thread down).

This also means that the fix approach described in bug 1877972 comment 50 is not going to work -- by the time we get that first confirmation, it's too late to end the transaction because the events that we want to cause scrolling have already been added to the transaction.

Comment 28

[Botond Ballo [:botond]]

(In reply to Botond Ballo [:botond] from comment #27)

This also means that the fix approach described in bug 1877972 comment 50 is not going to work -- by the time we get that first confirmation, it's too late to end the transaction because the events that we want to cause scrolling have already been added to the transaction.

Here's a different solution idea: rather than determining the target of a wheel block based on the first event only, continue checking subsequent events in the block until we find one which will scroll something.

Comment 29

[Botond Ballo [:botond]]

Attachment: Bug 1894228 - Change the aOutFirstInput parameter of InputQueue::FindBlockForId() from a pointer to an iterator. r=dlrobertson

This allows the caller to iterate the input queue to look at events
beyond the first event in the block, if desired.

To avoid a circular dependency between InputBlockState.h and InputQueue.h,
a class InputQueueIterator is introduced which hides the concrete type
of the iterator.

Comment 30

[Botond Ballo [:botond]]

Attachment: Bug 1894228 - Consider all events in a wheel block when determining its target APZC. r=dlrobertson

If the first event is in a direction where no APZC is scrollable, consider
subsequent events (which may have a different direction) to choose the target.

Depends on D212977

Comment 31

[Botond Ballo [:botond]]

(In reply to Botond Ballo [:botond] from comment #28)

Here's a different solution idea: rather than determining the target of a wheel block based on the first event only, continue checking subsequent events in the block until we find one which will scroll something.

This approach seems to work, I've written it up along with a test.

Comment 32

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e0e8173848fa
Change the aOutFirstInput parameter of InputQueue::FindBlockForId() from a pointer to an iterator. r=dlrobertson
https://hg.mozilla.org/integration/autoland/rev/0859a936d262
Consider all events in a wheel block when determining its target APZC. r=dlrobertson

Comment 33

[Cristina Horotan [:chorotan]]

https://hg.mozilla.org/mozilla-central/rev/e0e8173848fa
https://hg.mozilla.org/mozilla-central/rev/0859a936d262