1926830 - Scrolling stops working on unrelated pages after drag&drop image into FaviconSwitcher Addon

Status: NEW

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

Description

[Manuel Bucher [:manuel]]

Similar to Bug 1894228, but with (potential) reliable steps to reproduce. I could reproduce 2 out of 2 times. However, I didn't have time to investigate much.

STR:

1. Install faviconSwitcher via addons.mozilla.org
2. Click on the FaviconSwitcher Addon in the toolbar. Enter some pattern (e.g. bugzilla.mozilla.org), click on "Upload image".
3. Drag and drop some image into the popup window
4. close the window
5. scrolling with the mouse wheel is now broken on any website and any tab

Expected result:

Scrolling continues working.

Additional note:

• Slack was looked like it was in the state as if I was still dragging/dropping stuff. So might be wrong component (could be d&d, GTK, popus, or Addons as well). Slack looked normal after reloading, but scrolling still didn't work. I had to restart firefox to get my normal scrolling behavior back.

System:
Firefox 133.0a1 (2024-10-23) (64-bit)
Arch Linux
Gnome 47, X11
FaviconSwitcher: 0.4.0

Comment 1

[Botond Ballo [:botond]]

Thanks for the report!

I tried the steps but unfortunately was not able to reproduce (I'm also on X11 Linux, though using a different distro and KDE).

Would you be able to reproduce again with the following log modules enabled in about:logging, and share the resulting logs?

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

Comment 2

[Manuel Bucher [:manuel]]

(In reply to Botond Ballo [:botond] from Bug 1635512 comment #6)

(In reply to Manuel Bucher [:manuel] from Bug 1635512 comment #5)

I tried to record a RR trace for Bug 1926830, hit this crash instead.

Perhaps you could comment out this assertion, allowing you to reproduce bug 1926830 in RR?

I tried (that day, but didn't have time to comment) further and hit another crash that might also be the cause: Bug 1921769 comment 3, because it also caused similar other bugs (IIRC, but couldn't figure out if really related) Bug 1874084 comment 4. It seems like a bad timestamp is coming from GTK and we don't handle that gracefully. I couldn't reproduce today (I've hit yet another MOZ_ASSERT, need to open a bug for that too Assertion failure: mAsURIData && mDragUris, at /home/user/dev/gecko3/widget/gtk/nsDragService.cpp:416). Will try tomorrow again, then with debug assertions disabled to hopefully get a clean repro for Bug 1926830.

(Edit: Opened Bug 1930912 for that new assert)

Comment 3

[Botond Ballo [:botond]]

If getting an RR trace is proving to be tricky, the logs indicated in comment 1 would still be helpful to move the investigation of this forward in the interim.

Comment 4

[Botond Ballo [:botond]]

(Whoops, didn't mean to set priority/severity flags.)

Comment 5

[Manuel Bucher [:manuel]]

I can't reproduce anymore, sorry. Not sure if something underlying changed. Sorry, should have captured the log on the same day :/.

Comment 6

[Botond Ballo [:botond]]

No problem; I'll mark this as an S3 for now, and we can re-evaluate if we have another repro.

Comment 7

[Manuel Bucher [:manuel]]

Attachment: log.txt-main.75589.moz_log

I'm encountering scroll stopping to work after d&d occasionally (without the pop-up window). This is a log for that case. Might be same bug.

Comment 8

[Botond Ballo [:botond]]

(In reply to Manuel Bucher [:manuel] from comment #7)

Created attachment 9442986 [details]
log.txt-main.75589.moz_log

I'm encountering scroll stopping to work after d&d occasionally (without the pop-up window). This is a log for that case. Might be same bug.

Thanks for the logs! A quick look at them suggests that you're running into the same issue Paul was seeing in bug 1877972, related to the MSD scroll animation. This is actually the first time someone has reproed this since I added more detailed logging in bug 1883981, which is great.

I'll have a more detailed look at the logs in a bit, but in the meantime, if you need a workaround, setting general.smoothScroll.msdPhysics.enabled to false in about:config should fix it.

Comment 9

[Botond Ballo [:botond]]

It looks like ScrollAnimationMSDPhysics::SimulateUntil is always early-exiting here, and so the MSD animation never makes any progress.

Comment 10

[Manuel Bucher [:manuel]]

Due to this working on timestamps, and bad time stamps coming from Nautilus (GTK). I think this might be related (Some insights in Bug 1921769 comment 3). Setting See Also flag.

Comment 11

[Manuel Bucher [:manuel]]

I can confirm that setting general.smoothScroll.msdPhysics.enabled to false is a workaround to get scrolling to work again after drag&drop from nautilus. Enabling the pref again makes scroll break again.

Comment 12

[Botond Ballo [:botond]]

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

It looks like ScrollAnimationMSDPhysics::SimulateUntil is always early-exiting here, and so the MSD animation never makes any progress.

The two timestamps being compared in the early-exit condition come from two different sources: aTime is the current time / the time of the current vsync, and mLastSimulatedTime, which was set in Update(), comes from the timestamp of the last event with which the animation was updated.

So, if for some reason we get an event with a timestamp that's in the future, the animation will stall until the current time catches up to it. I don't think we can tell from the logs how far into the future the bad event timestamp is, but from the observations it seems to be at least as long as the entire period for which logs were taken.

I'm thinking that, in addition to any changes to the widget layer to address the issue of the future timestamp, we should probably guard against the scenario in APZ in some way.