Open Bug 1877972 Opened 1 year ago Updated 2 months ago

Mouse wheel occasionally stops working in content, works in chrome

Categories

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

Product:
Core
Component:
Panning and Zooming
Platform:
Desktop
Linux
Type:
defect

Tracking

()

Status:
ASSIGNED
Tracking Flags:
Tracking Status
firefox-esr115 --- unaffected
firefox123 --- disabled
firefox124 --- disabled
firefox125 --- disabled
firefox126 --- disabled

People

(Reporter: padenot, Assigned: botond)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: leave-open, regression)

Attachments

(3 files)

about:support
109.46 KB, text/plain
Details
Bug 1877972 - Add some logging related to sampling APZ animations. r=hiro,dlrobertson,ajakobi
48 bytes, text/x-phabricator-request
Details | Review
Simple page with non-passive wheel listener (test case for Julien's issue)
298 bytes, text/html
Details
Attached file about:support —

I'm not sure how to trigger this, but it has happened multiple times over the last few days, and has never happened before.

On linux / gnome-shell / latest up-to-date ubuntu, most recent version, sometimes I lose the ability to scroll using the mouse where in content, but e.g. scrolling the tab strip still works.

Let me know how I can diagnose this. Restarting the browser makes it works again.\

about:support is attached.

Has anything APZ related landed recently that could explain this? Also, I'm curious if you can scroll in parent process pages like about:preferences or so.

Off-hand I'd try logging with Widget:5, and maybe APZ logs, but I don't know what's best there.

A scattershot-style logging module list seems to be:

Widget:5,apz.child:4,apz.manager:4,apz.key:4,apz.controller:4,apz.axis:4,apz.checkerboard:4,apz.drag:4,apz.focusstate:4,apz.focustarget:4,apz.fling:4,apz.gesture:4,apz.manager:4,apz.inputstate:4,apz.inputqueue:4,apz.simplevelocitytracker:4,apz.helper:4,apz.displayport:4,apz.eventstate:4,apz.activeelement:4,apz.cc.chrome:4,apz.cc.remote:4,apz.displayport:4,apz.mobileviewport:4,apz.zoom:4,apz.paintskip:4,apz.displayport:4

Are there any particular sites this tends to happen on? When this happens are all following mousewheel events ignored?

The logging output from apz.controller:5 and apz.inputqueue:5 should be informative. It will be useful to know if the APZ controller is receiving the input events and if it is getting stuck in a particular state?

Dan, https://share.firefox.dev/49eKYxq shows this happening. I've left the screenshot so you can map my actions and the logging statements.

Essentially, it happened, went to about:logging and set the log modules you mentioned, went to about:preferences and did a few mouse wheel movements -- that did nothing, switched back to about:logging, and captured the logs.

If you're not familiar with logging to the profiler, the logging statements are in the Marker Table tab, on the thread of interest. I found some of the statements for the modules you mentioned in the parent process' main thread, alongside some stuff from widget, that I also had enabled because Emilio mentioned it.

If you prefer working with flat files, https://github.com/firefox-devtools/profiler/issues/4660#issuecomment-1582178907 has a bit of js you can paste in the devtools to write the log statements in the same format you'd have on the command line.

Let me know if I can help to narrow this further, this happens multiple time per day for me so whatever instruction you give me I can follow.

Flags: needinfo?(drobertson)

Important development: I did nothing except wait a bit and switch virtual desktop, and it now works again.

Thanks! I'm fairly certain this is an APZ issue. It looks like we receive the scroll wheel input InputQueue::ReceiveScrollWheelInput, and continually don't find a wheel block state that we can update, so we start a new wheel block state here and cancel the wheel animation here. The APZC does enter the WHEEL_SCROLL state, but we almost immediately cancel the animation.

(apz.controller) 7f42c3e40800(subframe scrollId=11): changing from state NOTHING to WHEEL_SCROLL
(apz.controller) 7f42c3e40800(subframe scrollId=11): running CancelAnimation(0x7) in state WHEEL_SCROLL
(apz.controller) 7f42c3e40800(subframe scrollId=11): running CancelAnimation(0x7) in state WHEEL_SCROLL
... this repeats for a very long time
Flags: needinfo?(drobertson)
Component: Layout: Scrolling and Overflow → Panning and Zooming

(In reply to Dan Robertson (:dlrobertson) from comment #6)

we start a new wheel block state here and cancel the wheel animation here

Note that this doesn't actually cancel the wheel scroll animation, because CancelAnimations is called with the ExcludeWheel flag (and we don't see a scrollId=11 [...] changing from state WHEEL_SCROLL to NOTHING message).

Few more things from the log:

  • scrollId=2 is the chrome document or some such, not scrollable
  • scrollId=11 is the main scrollable element on about:preferences, that's what should be scrolling
  • scrollId=12 is a shorter subframe on about:preferences (maybe from "Translations")

The log is showing:

D/apz.controller 7f42c3e40800 got a scroll-wheel with delta in parent-layer pixels: (0,192)

a bunch of times, and we have stuff like:

D/apz.controller 7f42c3e40800 scroll snapping near (0,128)
D/apz.controller 7f42c3e40800 scroll snapping near (0,256)
D/apz.controller 7f42c3e40800 scroll snapping near (0,384)
D/apz.controller 7f42c3e40800 scroll snapping near (0,512)

which suggests the destination of the wheel scroll animation is successfully being updated for each input event.

However, the displayports calculated for scrollId=11 always have s=(0,0), indicating that we haven't actually scrolled.

I compared the logs to the logs I get when I scroll about:preferences successfully, and what I don't see is a bunch of requesting content repaint messages between each wheel tick triggered by the animation being sampled on each vsync. It's as though WebRender just isn't asking for samples at all...

Paul, if it happens again, could you include the RenderBackend thread in the profile so we can get some more info about what WebRender is up to?

Flags: needinfo?(padenot)

It would also be interesting to know whether the problem occurs if "Use smooth scrolling" is unchecked in about:preferences.

Botond, I'll wait for this to repro, capture the logs you requested, then disable smooth scrolling and see what's going on.

Flags: needinfo?(padenot)

The last few comments sort of sound like it could be related to these recently filed bugs, bug 1877726, bug 1877515.

Interestingly, rendering seems to work well for me: if I hover elements with :hover, the style change is triggered appropriately as everything is as expected.

Botond, with the thread requested: https://share.firefox.dev/3UolOYU. I'll now disable smooth scrolling. Scrolling with the keyboard or scroll bar still works when this happens, by the way.

Flags: needinfo?(botond)

Unticking the "Smooth scrolling" box immediately fixes the issue for me, scroll starts working. If I re-tick the box, it stops working immediately.

(In reply to Paul Adenot (:padenot) from comment #14)

Botond, with the thread requested: https://share.firefox.dev/3UolOYU.

Interestingly, I do see the RenderBackend thread calling update_document on every vsync, suggesting that WebRender is generating frames (and I do more specifically see profiler samples in apz_sample_transforms for many frames, including a bunch of them during the period when we should be scrolling)... so it remains a mystery why the wheel animation doesn't seem to be sampled.

Flags: needinfo?(botond)
Assignee: nobody → botond
Status: NEW → ASSIGNED

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

it remains a mystery why the wheel animation doesn't seem to be sampled

My best idea for now is to add some more targeted logging to try to answer this question.

Assignee: botond → nobody
Status: ASSIGNED → NEW
Keywords: leave-open
Assignee: nobody → botond
Status: NEW → ASSIGNED
Pushed by bballo@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/8d09849aa4fe Add some logging related to sampling APZ animations. r=hiro

Paul, if it happens again with the most recent nightly, could you share a new profile and this time also include apz.manager:4 in the logs please?

Flags: needinfo?(padenot)

Yes, I'll update my nightly, re-enable smooth scrolling, and update this bug if it happens again.

Flags: needinfo?(padenot)

The severity field is not set for this bug.
:botond, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(botond)

I'm seeing an issue where scrolling works in some tabs (e.g. gmail) but not others (e.g. chat.mozilla.org or slack.com), and works in chrome popup windows but not in e.g. the tab strip.

Made a profile as guided by padenot: https://share.firefox.dev/3SPJAuv

(In reply to Julien Cristau [:jcristau] from comment #24)

I'm seeing an issue where scrolling works in some tabs (e.g. gmail) but not others (e.g. chat.mozilla.org or slack.com), and works in chrome popup windows but not in e.g. the tab strip.

Made a profile as guided by padenot: https://share.firefox.dev/3SPJAuv

Thanks for the profile. Based on the logs, something different is happening in your case than in Paul's (but still APZ related).

I'll post some analysis here anyways; we can split out this issue into a separate bug later as needed.

Here is a subset of the log that tells an interesting story about what happens to wheel events when we don't scroll in response to them:

D/apz.manager Hit-testing point (1164,833) with WR
D/apz.manager Examining result with guid { l=0x100000010, p=0, v=13 } hit info 0x5... 
D/apz.manager selecting as chosen result.
D/apz.manager Successfully matched APZC 7fa54ac28000 (hit result 0x5)
D/apz.inputqueue started new scroll wheel block 7fa54979ff20 id 1002 for target 7fa54ac28000
D/apz.inputqueue scheduling main thread timeout for target 7fa54ac28000
D/apz.inputqueue got a target apzc; block=1002 guid={ l=0x100000010, p=2, v=13 }
D/apz.inputqueue got a content response; block=1002 preventDefault=0
D/apz.inputqueue processing input from block 7fa54979ff20; preventDefault 0 shouldDropEvents 0 target 0

The initial hit test succeeds and finds an APZC with identifier v=13 and address 7fa54ac28000. We enqueue the wheel event into the input queue, creating a wheel block whose initial target APZC is the one we found via the hit-test (7fa54ac28000), and then send a message to the content process to confirm that this is what should be scrolled.

We get the requisite responses from the content process ("got a target apzc", "got a content response"). The target APZC confirmed by the content process is the same one (v=13).

When we deqeueue the event to process it, though... we now have target 0, i.e. the target APZC is null, so the event is dropped. Oops.

So what happened here?

The value being printed as null is InputBlockState::mTargetApzc. This is set initially when the input block is created, and we can see from the message "started new scroll wheel block 7fa54979ff20 id 1002 for target 7fa54ac28000" that its initial target is not null.

The only place where mTargetApzc is modified is in InputBlockState::UpdateTargetApzc. This has a few call sites but the only one applicable in this situation is InputBlockState::SetConfirmedTargetApzc, called when we get the "got a target apzc" message from the content process.

However, based on the message "got a target apzc; block=1002 guid={ l=0x100000010, p=2, v=13 }", the new target APZC is also non-null.

How is this possible? It turns out that WheelBlockState overrides SetConfirmedTargetApzc, and the overriden implementation can replace the new target with the result of calling BuildOverscrollHandoffChain()->FindFirstScrollable() on the new target.

Based on what we're seeing, what must be happening is that FindFirstScrollable() call returns null, and so that's what we update the target APZC to.

Flags: needinfo?(botond)

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

D/apz.manager Hit-testing point (1164,833) with WR
D/apz.manager Examining result with guid { l=0x100000010, p=0, v=13 } hit info 0x5... 
D/apz.manager selecting as chosen result.
D/apz.manager Successfully matched APZC 7fa54ac28000 (hit result 0x5)
D/apz.inputqueue started new scroll wheel block 7fa54979ff20 id 1002 for target 7fa54ac28000
D/apz.inputqueue scheduling main thread timeout for target 7fa54ac28000
D/apz.inputqueue got a target apzc; block=1002 guid={ l=0x100000010, p=2, v=13 }
D/apz.inputqueue got a content response; block=1002 preventDefault=0
D/apz.inputqueue processing input from block 7fa54979ff20; preventDefault 0 shouldDropEvents 0 target 0

Though the place where you looked at might be different from what I am looking at now, at 3.990s I do see

(apz.controller) 7fa54ac28000 scroll snapping near (0,1089)

which is just before we got a content response. So I suppose the root scroll container had reached to the bottom edge, thus we in FindFirstScrollable() return nullptr?

It's totally unclear to me that how the scroll position was changed from the log though.

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

Based on what we're seeing, what must be happening is that FindFirstScrollable() call returns null, and so that's what we update the target APZC to.

Thinking about this some more, these observations are consistent with what we'd expect to happen if you're scrolled to the end of the page and trying to wheel-scroll further down (or the beginning of the page and trying to wheel-scroll further up).

And looking at the metrics, the scroll frame in question is indeed scrolled to the bottom (we have scroll offset = (0,1089), viewport height = 1862, and scrollable rect height = 2951). It looks like the page in question is slack.com, where the main scrollable view being scrolled to the bottom is the default state. So, if you were trying to scroll down in that state, the observed results are expected. If you were trying to scroll up, then something's going wrong.

Unfortunately we don't have a log statement that logs the wheel events' scroll delta to see the direction of the attempted scrolling. (We have such a log statement in AsyncPanZoomController::OnScrollWheel, but the event is dropped before reaching that.)

Julien, if you can remember, can you confirm that you were definitely trying to scroll upwards on Slack and it didn't work?

Flags: needinfo?(jcristau)

I think i scrolled up and down, but I couldn't swear to it.

Flags: needinfo?(jcristau)

Botond, new one from me with the same problem (the original one that I opened this for, not :jcristau's) and a recent build, with the logs you requested: https://share.firefox.dev/48xs7g9. I attempted to scroll in PID 138837 (chat.m.o).

Flags: needinfo?(botond)

(In reply to Paul Adenot (:padenot) from comment #29)

Botond, new one from me with the same problem (the original one that I opened this for, not :jcristau's) and a recent build, with the logs you requested: https://share.firefox.dev/48xs7g9. I attempted to scroll in PID 138837 (chat.m.o).

Thanks for the updated profile!

The new logs I added in comment 19 are showing that the wheel scroll animation remains alive and is sampled on every frame, but sampling it does not produce any changes to the scroll offset, as though the animation was computing 0 pixels as the amount of progress it should make on each frame.

This is making me suspect that the issue is related to the new MSD scrolling physics that we enabled on Nightly in bug 1846935. While I don't have a concrete guess for how such a scenario might arise, if for some reason the MSD physics were coming up with 0 pixels of progress on each frame, the results would be consistent with what we're observing (I verified this by making some local changes to get the MSD physics to deliberately produce bad results like this).

(If the MSD physics is indeed the culprit, that's slightly reassuring in that it's a Nightly-only change, so it would mean this bug isn't affecting the release population.)

Paul, if you're down to do a short experiment the next time this happens, we could confirm whether the MSD physics is the culprit as follows:

  • When the problem occurs, go to about:config and set general.smoothScroll.msdPhysics.enabled to false
  • To interrupt the previous never-ending wheel animation, drag the scrollbar of the affected scrollable element (the pref is only checked when a new animation is constructed)
  • See if wheel-scrolling now works
  • (Optionally, see if setting the pref back to true breaks it again)

In the meantime, I'll add some additional logging to the MSD physics implementation so that if it is the culprit, we have some information to go on to try to figure out what goes wrong.

Flags: needinfo?(botond) → needinfo?(padenot)

Will do, thanks.

Flags: needinfo?(padenot)

To circle back to Julien's issue: I read through the implementation of FindFirstScrollable() to see if there is any plausible reason why it may not be returning the scrollable element found by the hit test besides "it's already at the end of its scroll range", and I didn't see anything else that would be applicable to this scenario. So, my best idea at this point is to log the wheel deltas earlier in the pipeline so we can see the direction of the attempted scroll, and hopefully those will help focus our investigation in future reports.

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

Paul, if you're down to do a short experiment the next time this happens, we could confirm whether the MSD physics is the culprit as follows:

  • When the problem occurs, go to about:config and set general.smoothScroll.msdPhysics.enabled to false

This makes the problem go away immediately, no need to touch a scrollbar, simply switching away from about:config to a regular web page makes the scroll using the mouse wheel work again.

  • (Optionally, see if setting the pref back to true breaks it again)

It does, it breaks it immediately, and I can switch from broken state to working state at will by flipping the pref.

Unfortunately I was running a slightly older build so it probably doesn't have any additional logging.

Flags: needinfo?(botond)

(In reply to Paul Adenot (:padenot) from comment #33)

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

Paul, if you're down to do a short experiment the next time this happens, we could confirm whether the MSD physics is the culprit as follows:

  • When the problem occurs, go to about:config and set general.smoothScroll.msdPhysics.enabled to false

This makes the problem go away immediately, no need to touch a scrollbar, simply switching away from about:config to a regular web page makes the scroll using the mouse wheel work again.

  • (Optionally, see if setting the pref back to true breaks it again)

It does, it breaks it immediately, and I can switch from broken state to working state at will by flipping the pref.

Thanks! This confirms that we're seeing a regression from bug 1846935 (enablement of MSD physics on the nightly channel).

I'll mark this as blocking the feature riding the trains (bug 1760372).

Unfortunately I was running a slightly older build so it probably doesn't have any additional logging.

I also haven't added the logging yet :-). I'll add it today and hopefully the next time it happens we can find out more.

Blocks: 1760372
Flags: needinfo?(botond)
Keywords: regression
Regressed by: 1846935

Marking as S3 since this is a nightly-only regression.

Severity: -- → S3
Priority: -- → P2

Is this worth backing out MSD physics by default from nightly?

Set release status flags based on info from the regressing bug 1846935

status-firefox123: --- → affected
status-firefox125: --- → affected
status-firefox-esr115: --- → unaffected

(In reply to Dan Robertson (:dlrobertson) from comment #36)

Is this worth backing out MSD physics by default from nightly?

I'm hoping it's rare enough (and with another round or two of logging we can fix it quickly enough) that we don't need to.

However, I'm open to opinions to contrary.

Depends on: 1883981

The added logging has now landed (in bug 1883981).

Paul, if it happens again, if you could share a profile with the following additional log modules also enabled, that would be great!

apz.scrollanimation:4
apz.msd:4
Flags: needinfo?(padenot)

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

(In reply to Dan Robertson (:dlrobertson) from comment #36)

Is this worth backing out MSD physics by default from nightly?

I'm hoping it's rare enough (and with another round or two of logging we can fix it quickly enough) that we don't need to.

However, I'm open to opinions to contrary.

I don't understand why, but this happens more rarely than it used to. I'm waiting for this to repro to catch it with your new logs.

Flags: needinfo?(padenot)

Set release status flags based on info from the regressing bug 1846935

status-firefox126: --- → affected
See Also: → 1894228

mouse scroll stopped working for me again on slack.com and chat.mozilla.org.
Profile from slack: https://share.firefox.dev/3KisK3K
That should include attempts at scrolling up and down both on the channel list and inside a channel, with log modules apz.controller:5,apz.inputqueue:5,apz.manager:4,apz.scrollanimation:4,apz.msd:4.

From the log;

LogMessages — (apz.controller) user-multiplied delta is (27,0) (deltaType 0, line size (9 x 19), page size (1437 x 1817))
LogMessages — (apz.controller) overridden delta is (54,0)
LogMessages — (apz.controller) 7f90143ab800(subframe scrollId=3): CanScroll: event delta is (54,0)
LogMessages — (apz.controller) cannot scroll with wheel (disregarded direction is <Nothing>):{ [cb=(x=0, y=0, w=1454, h=1862)] [sr=(x=0, y=0, w=1454, h=2972)] [s=(0,1110)] [dp=(x=0, y=-1, w=1405, h=1863)] [rcs=(1920 x 2043)] [v=(x=0, y=1110, w=1454, h=1862)] [z=(ld=1.000 r=1.000 cr=1 z=1 t=1 )] [u=(0 608)] scrollId=3 }

It somehow tried to scroll horizontally. That's odd.

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

It somehow tried to scroll horizontally. That's odd.

I'm seeing a mixture of wheel events with horizontal deltas and ones with vertical deltas (and a mixture of both directions for each one).

This is also what we saw in bug 1894228 (which I suspect may be the same issue that Julien is seeing here).

I checked, and a mixture of events like this is what I see as well in the following scenario:

  • I'm scrolling using the touchpad of my Linux laptop
  • I'm running in an X11 session with MOZ_USE_XINPUT2=0 (so that the touchpad generates ScrollWheelInput rather than PanGestureInput)
  • I'm scrolling "up and down" (as Julien said), but without my finger leaving the touchpad between the "up" and "down" phases
    • in this situation, there are brief periods when you are transitioning from "up" phase to the "down" phase, where the touchpad detects that the direction of movement is horizontal and produces a wheel event with a horizontal delta

Ah, I see what you mean now. I was looking at this log statement, which shows a mixture of horizontal and vertical deltas. But by the time we get to here, they are all horizontal!

I do note that we have a mechanism that can sometimes swap the x and y deltas of wheel events (see WheelDeltaAdjustmentStrategy, in particular the eHorizontalize and eAutoDir strategies).

However, I don't quite see how these could explain the observed behaviour:

  • eHorizontalize is handled in APZInputBridge, so the horizontalization would already be reflected in the "Received wheel input" log message
  • eAutoDir is handled in OnScrollWheel (and in CanScroll), so at the point of the "user-multiplied delta" log, it should not be applied yet

Maybe this FindFirstScrollable call with aFirstInput in WheelBlockState::SetConfirmedTargetApzc is the cause of the horizontal delta.

If

10.188s LogMessages — (apz.manager) Received wheel input at (313,762) with delta (-3.000000, 0.000000)

this is a FirstInput, then we got

10.189s LogMessages — (apz.manager) Received wheel input at (313,762) with delta (0.000000, 3.000000)

then

10.189s LogMessages — (apz.inputqueue) got a target apzc; block=564 guid={ l=0x100000019, p=2, v=6 }

and

10.189s LogMessages — (apz.controller) user-multiplied delta is (-27,0) (deltaType 0, line size (9 x 19), page size (475 x 1912))

Yes, I think you're onto something! Here is an interesting log sequence:

(apz.manager) Received wheel input at (1007,991) with delta (3.000000, 0.000000)
(apz.inputqueue) started new scroll wheel block 7f900f96b660 id 531 for target 7f90143ab800
(apz.manager) Received wheel input at (1007,991) with delta (0.000000, -3.000000)
(apz.inputqueue) received new wheel event in block 7f900f96b660
(apz.manager) Received wheel input at (1007,991) with delta (-3.000000, 0.000000)
(apz.inputqueue) started new scroll wheel block 7f900f96b660 id 532 for target 7f90143ab800
(apz.manager) Received wheel input at (1007,991) with delta (0.000000, -3.000000)
(apz.inputqueue) received new wheel event in block 7f900f96b660
(apz.manager) Received wheel input at (1007,991) with delta (3.000000, 0.000000)
(apz.inputqueue) started new scroll wheel block 7f900f96b660 id 533 for target 7f90143ab800
(apz.manager) Received wheel input at (1007,991) with delta (0.000000, -3.000000)
(apz.inputqueue) received new wheel event in block 7f900f96b660
(apz.manager) Received wheel input at (1007,991) with delta (-3.000000, 0.000000)
(apz.inputqueue) started new scroll wheel block 7f900f96b660 id 534 for target 7f90143ab800
(apz.manager) Received wheel input at (1007,991) with delta (0.000000, -3.000000)
(apz.inputqueue) received new wheel event in block 7f900f96b660
(apz.manager) Received wheel input at (1007,991) with delta (3.000000, 0.000000)
(apz.inputqueue) started new scroll wheel block 7f900f96b660 id 535 for target 7f90143ab800
(apz.manager) Received wheel input at (1007,991) with delta (0.000000, -3.000000)
(apz.inputqueue) received new wheel event in block 7f900f96b660
(apz.manager) Received wheel input at (1007,991) with delta (-3.000000, 0.000000)
(apz.inputqueue) started new scroll wheel block 7f8fd38ba7e0 id 536 for target 7f90143ab800
(apz.manager) Received wheel input at (1007,991) with delta (0.000000, -3.000000)
(apz.inputqueue) received new wheel event in block 7f8fd38ba7e0
(apz.manager) Received wheel input at (1007,991) with delta (3.000000, 0.000000)
(apz.inputqueue) started new scroll wheel block 7f9003dd1f20 id 537 for target 7f90143ab800
(apz.manager) Received wheel input at (1007,991) with delta (0.000000, -3.000000)
(apz.inputqueue) received new wheel event in block 7f9003dd1f20

What we see here is:

  • the incoming wheel events are alternating between horizontal and vertical deltas
  • the vertical deltas are all negative
  • the horizontal deltas are alternating between positive and negative
  • events with horizontal deltas all start new wheel blocks
  • events with vertical deltas are added as new events to the existing block

Since SetConfirmedTargetApzc consults the first event in the input block to determine which APZC the input block will scroll, and since the first event always has a horizontal delta, none of the input blocks cause scrolling.

I was able to reproduce the bug, very intermittently, by loading the attached test page in a slow build (e.g. a debug build, or running under rr), and scrolling diagonally on my touchpad (with XInput2 disabled).

The diagonal scroll causes the touchpad to produce a mixture of horizontal-delta and vertical-delta wheel events.

In my case, the first event in the touchpad gesture starts a new input block, and subsequent events in the gesture are added to the same input block. (This is a bit different from what we see in Julien's profile, but the resulting failure mode seems to be the same.)

If we are unlucky that the first event happens to have a horizontal delta, it does inhibit the entire wheel block's ability to cause any scrolling (because nothing is scrollable in the horizontal direction).

The presence of the non-passive wheel listener is important because otherwise, we enter the target-confirmed block when creating the WheelBlockState, and in the case of a horizontal-delta event, we end the wheel transaction here, causing the next (vertical-delta) event to start a new wheel block which can then cause scrolling.

So I think a potential fix could be to add a similar EndTransaction() call to WheelBlockState::SetConfirmedTargetApzc().

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

So I think a potential fix could be to add a similar EndTransaction() call to WheelBlockState::SetConfirmedTargetApzc().

I'm going to pursue the fix in bug 1894228, since in this bug we have another issue to track (the Nightly-only issue related to MSD physics which Paul has run into).

Yeah, it's still a mystery how MSD physics causes scrolling stuck. And now I realized the profile result in comment 42 doesn't include any MSD physics related logs since it didn't have logging on RenderBackend thread.

Julien if you see this bug again, please check the RenderBackend option on our profiler setting page. Thanks!

FWIW I am not using a touchpad, so not sure how there would be horizontal scrolling. I'll try using evtest next time this happens to see what comes out of the kernel.

See Also: → 1908257
See Also: → 1926830
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: