Open Bug 1875627 Opened 1 year ago Updated 11 months ago

Can't scroll using the mouse after drag and drop a file inside firefox

Categories

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

Product:
Core
Component:
Panning and Zooming
Version:
Firefox 123
Platform:
x86_64
Linux
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
firefox-esr115 --- unaffected
firefox122 --- disabled
firefox123 --- disabled
firefox124 --- disabled

People

(Reporter: kcchouette+mozilla, Unassigned)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression)

Attachments

(3 files, 1 obsolete file)

about:support of the mozilla firefox
62.29 KB, text/plain
Details
mozregression using custom value "general.smoothScroll.msdPhysics.enabled=true"
110.08 KB, image/png
Details
MOZ_LOG=Widget:5,WidgetDrag:5,sync,timestamp
90.67 KB, text/plain
Details

Steps to reproduce:

  1. go on a website which accept drag and drop file (for eg discord)
  2. drag and drop a file

Actual results:

You can't anymore use the scroll wheel of your mouse

Expected results:

You can use the scroll wheel of your mouse

I'm under Manjaro OS (Linux) using Mozilla Firefox Nightly version (from the official website)

I try to do a bissection using mozregression,
build_date: 2023-12-03 is a good build,
build_date: 2023-12-04 is a bad build

Attached image mozregression.png (obsolete) —

2024-01-20T13:14:41.511000: DEBUG : Found commit message:
Bug 1662379, 1846935: apply code formatting via Lando

ignore-this-changeset

2024-01-20T13:14:41.511000: DEBUG : Did not find a branch, checking all integration branches
2024-01-20T13:14:41.512000: INFO : The bisection is done.
2024-01-20T13:14:41.513000: INFO : Stopped

The build I skipped is because they are unusable on my OS (eg not charging the website)

OS: Unspecified → Linux
Hardware: Unspecified → x86_64

The Bugbug bot thinks this bug should belong to the 'Core::Panning and Zooming' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Panning and Zooming
Product: Firefox → Core

Thanks for using mozregression.

I think that corresponds to this push

https://hg.mozilla.org/mozilla-central/pushloghtml?changeset=369922cc5c4efad6c87b13600325eb5a989cde81

What happens if you set general.smoothScroll.msdPhysics.enabled to false? (Is is true or false for you already?)

Flags: needinfo?(kcchouette+mozilla)

What happens if you set general.smoothScroll.msdPhysics.enabled to false? (Is is true or false for you already?)

it's true on my side (and it seems by default, it's true too)
If I set to false, and try to reproduce the problem, I do not have it
If I set it again to true, I have the problem

Flags: needinfo?(kcchouette+mozilla)
Keywords: regression
Regressed by: 1846935

:botond, since you are the author of the regressor, bug 1846935, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Flags: needinfo?(botond)

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Status: UNCONFIRMED → NEW
Ever confirmed: true

Marking as S3 since this is a nightly-only regression, but marking as blocking MSD physics riding the trains (bug 1760372).

I have not been able to reproduce this so far. Jeremy, would you be able to provide some more details to help me reproduce? For example:

  • What sort of page or view are you looking at in Discord when dropping the file (e.g. a channel? DM? something else?) and where are you dropping it (the text field for composing a message? do you have to actually send the file to trigger the bug?)
  • Does the type of file dropped matter?
  • Is Discord the site you were testing on in your mozregression run shown in comment 2? Do you have other examples of sites which are affected?
  • Does the inability to scroll with the mousewheel affect a particular scrollable element in Discord (e.g. the channel contents), or the entire tab, or the entire browser window including other tabs?

Thanks!

Severity: -- → S3
Flags: needinfo?(botond) → needinfo?(kcchouette+mozilla)
Priority: -- → P2

Hello
I can reproduce with any page which have a scrollbar;
Here an example:

  1. I have a file file_.txt that contains dddd inside
  2. go to https://www.file.io/
  3. you see the page has a scroll bar at the right, you can use the scroll wheel of your mouse to go up and down
  4. drag in the page the file file_.txt
  5. the url is now the file file:///home/xxx/file_.txt and show the content
  6. click on the "back one page" button
  7. so you're now on https://www.file.io/
  8. you cannot use the scroll wheel of your mouse to go up and down
  • I think it answer the first point
  • For the second point, no idea, I only use text file right now
  • To be honest I use https://www.file.io/ (as nothing is needed, so I can test quickly)
    For me because of this new way of reproducing, I can reproduce on any website
  • The inability to scroll with the mousewheel affect the entire browser window including other tabs
    I need to close the browser and open again to have the ability to scroll with the mousewheel
Flags: needinfo?(kcchouette+mozilla)

Thanks. I have followed the steps from comment 9 closely but I cannot reproduce the bug.

I will think about some next diagnostic steps, but in the meantime, if anyone else reading this bug has a moment to try the steps from comment 9, I would be interested to get additional data points on who can reproduce the problem.

I can't reproduce either on my Linux with Wayland. I tried on a nightly (2024-01-02) and v121 release.

The problem does not occur on the platform Windows 10 :(

How can I give you more detailed information about my env?

(In reply to Jeremy from comment #12)

How can I give you more detailed information about my env?

Two things that would be useful:
(1) First, see if it reproduces in a fresh browser profile -- since you're on Linux, you can run the following from the terminal to start Firefox with a temporary fresh profile (where $NIGTHLY-DIR is wherever you've extracted your Firefox Nightly tarball):

mkdir /tmp/test-profile; $NIGTHLY-DIR/firefox -profile /tmp/test-profile

(2) If it does reproduce there, then:

  • capture about:support data from that fresh-browser-profile Firefox session -- just type about:support in the URL bar there and hit enter, and then click "Copy raw data to clipboard"
  • Back in your main Firefox session (where you're logged in to bugzilla), go to this bug page and then click "Attach new file" and paste in all of that raw data in the "File" field at the top, and type something in the "Description" field, and hit Submit.

(You could also jump straight to about:support with your regular profile, but it helps to capture about:support data from a fresh profile -- if it reproduces there -- since that will remove a bunch of unrelated information [your various nondefault settings/addons] that could otherwise muddy the waters or lead to wild goose chases.)

Thanks!

(Also, for what it's worth: https://www.dropzone.dev/ might be a better test-site here than https://www.file.io/ since https://www.file.io/ doesn't seem to actually accept the dragged file; Firefox just directly opens the file, as you noted. Could you check whether this reproduces with https://www.dropzone.dev/ as an example of a site that actually accepts the file-drop?)

For what it's worth, I tested comment 9 in Ubuntu 22.04 on my desktop machine, with Xorg and Wayland (chosen at login screen), and was unable to repro any scrollbar issues in either config.

Hello
I'm sorry, it seems I don't have the issue anymore today.
I tried to use an older nightly version, to try if it's the new build which is good, but I cannot reproduce it
Maybe it was a package bug, but this is weird as I only upgraded vscode and some dotnet packages

Hello

Today I have the problem again, I'm trying to find a way to reproduce it at 100%

I reproduce using

mkdir /tmp/test-profile; $NIGTHLY-DIR/firefox -profile /tmp/test-profile

I uploaded a xml file (450 Ko)

This is really weird, I can reproduce it at 100% using my comment 9 (and the file_.txt) today, but yesterday it was not the case

One thing I'm noticing locally on Ubuntu 22.04: when I'm actively dragging something, my scrollwheel has no effect (which makes some sense). Perhaps whatever OS-level thing applies that suppression must perhaps be getting stuck in that state after your drag operation completes, for some reason.

Question for you: when you've got Firefox into this broken state (while Firefox is still open and in that broken state), does mousewheel-scrolling continue to work in other apps, e.g. gedit or your terminal for example?

(It may be interesting to capture some MOZ_LOG logging to see what sort of event callbacks we're getting from the system when the drag operation completes and when scrolling is attempted, when this is working vs. not-working. But I think we need to add a little more logging to make that useful, so I filed bug 1876609 to do that. Once that's in Nightly (maybe in a few days) maybe we can try to capture some logging here.)

(ni=reporter for "Question for you" in comment 21)

Flags: needinfo?(kcchouette+mozilla)

When you've got Firefox into this broken state (while Firefox is still open and in that broken state), does mousewheel-scrolling continue to work in other apps, e.g. gedit or your terminal for example?

Hello
Yes the mousewheel-scrolling continue to work except in the firefox which have the problem.
If I open a "new private window", the mousewheel-scrolling does not work in this "new private window" and in the normal window

This problem has no incident on other softwares

Flags: needinfo?(kcchouette+mozilla)

Thanks.

I anticipate that my just-landed https://phabricator.services.mozilla.com/D199663 will make it into tomorrow's Nightly. If you can reproduce the bug tomorrow (~24h from now), it would be useful if you could perform your comment 9 in an up-to-date Firefox build at that point with relevant MOZ_LOG logging -- something like this:

export MOZ_LOG=Widget:5,WidgetDrag:5,sync,timestamp
mkdir /tmp/test-profile
$NIGHTLY-DIR/firefox -profile /tmp/test-profile 2> /tmp/test-log.txt

(where NIGHTLY_DIR is your firefox Nightly directory, and /tmp/test-profile and /tmp/test-log.txt are a new folder/file generated by this command)

And then post /tmp/test-log.txt as an attachment here -- I'm particularly curious whether your scrollwheel-movement (after the drag/drop operation as signaled in the log by nsDragService::EndDragSession I think) will show up as OnScrollEvent logging (which is the logging that I've just added), vs. if it doesn't show up at all after that point.

(I suspect it probably will show up, if this was working for you in older builds, but if it happens not to, then that would be a signal of something interesting getting stuck per my first paragraph in comment 21.)

If anyone else has ideas for useful logging to capture or diagnostics to capture, please chime in! I'm not seeing any logging that could be opted-in-to in https://searchfox.org/mozilla-central/rev/1e726a0e49225dc174ab55d1d0b21e86208d7251/layout/generic/ScrollAnimationMSDPhysics.cpp but maybe we should/could add some to help identify where things are falling over (assuming its msd-physics-related per comment 4).

(note, I just edited comment 24 to add timestamp to the MOZ_LOG environmental variable which will be useful when filtering out what-happened-when; please use the command as shown on the Bugzilla website in comment 24 here, rather than the original version from your bugzilla email. Thanks! :) )

I'd like Jeremy to do mozregression again but with general.smoothScroll.msdPhysics.enabled=true. Given that the issue is not 100% reproducible, the result may be unreliable though.

Hello Hiroyuki, I don't understand your comment

If general.smoothScroll.msdPhysics.enabled=false, I do not have the problem (see comment 5)

And yes, it seems the issue is not 100% reproducible, it's why when I reproduce it I gave the about:support and other infos (as tomorrow is another day)

(In reply to Jeremy from comment #27)

Hello Hiroyuki, I don't understand your comment

If general.smoothScroll.msdPhysics.enabled=false, I do not have the problem (see comment 5)

That's the reason why I asked you to try it again with general.smoothScroll.msdPhysics.enabled=true. The change you found by mozregression is basically just changed the default value from false to true, thus I suspect there should be the real culprit before the default value change.

That's the reason why I asked you to try it again with general.smoothScroll.msdPhysics.enabled=true. The change you found by mozregression is basically just changed the default value from false to true, thus I suspect there should be the real culprit before the default value change.

Ah, thanks for your answer, I get it now

Looks like 2022-04-07 is "good" and 2022-04-08 is "bad" then.

mozregression --good 2022-04-07 --bad 2022-04-08 yields this pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b8732a1c1fa931fc3cc5369e31a64db459f60c83&tochange=0671f5ff7249d3d7c458a29a4099a093c01f0ac1

I'm not seeing anything obviously relevant in that pushlog, though... hiro, do you see anything? (Maybe this could've somehow been bug 1756903? But it's not clear why there'd be a MSD-physics-only relevancy there.)

Jeremy, could you check whether mozregression gives you a pushlog URL like the one that I pasted in comment 31 somewhere at the end of the run? (I want to make sure that I'm not somehow getting different-revision Nightlies from the one that mozregression is using for you....)

No. There's nothing to related the MSD physics pref. Moreover there's nothing specific to scrolling. I start suspecting something did happen on the Jeremy's environment when he changed the pref, or this issue might have been solved by flipping random pref values.

Jeremy, could you check whether mozregression gives you a pushlog URL like the one that I pasted in comment 31 somewhere at the end of the run? (I want to make sure that I'm not somehow getting different-revision Nightlies from the one that mozregression is using for you....

I use the GUI of mozregression
If I click on the "bad" one of 2022-04-08 I have this:

app_name: firefox
build_date: 2022-04-08
build_file: /home/user/.mozilla/mozregression/persist/2022-04-08--mozilla-central--firefox-101.0a1.en-US.linux-x86_64.tar.bz2
build_type: nightly
build_url: https://archive.mozilla.org/pub/firefox/nightly/2022/04/2022-04-08-21-44-49-mozilla-central/firefox-101.0a1.en-US.linux-x86_64.tar.bz2
changeset: 0671f5ff7249d3d7c458a29a4099a093c01f0ac1
pushlog_url: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0992c635a8c53621810151649a24429836987fd6&tochange=0671f5ff7249d3d7c458a29a4099a093c01f0ac1
repo_name: mozilla-central
repo_url: https://hg.mozilla.org/mozilla-central

and for the "good" one of 2022-04-07:

app_name: firefox
build_date: 2022-04-07
build_file: /home/user/.mozilla/mozregression/persist/2022-04-07--mozilla-central--firefox-101.0a1.en-US.linux-x86_64.tar.bz2
build_type: nightly
build_url: https://archive.mozilla.org/pub/firefox/nightly/2022/04/2022-04-07-21-29-10-mozilla-central/firefox-101.0a1.en-US.linux-x86_64.tar.bz2
changeset: b8732a1c1fa931fc3cc5369e31a64db459f60c83
pushlog_url: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b8732a1c1fa931fc3cc5369e31a64db459f60c83&tochange=0671f5ff7249d3d7c458a29a4099a093c01f0ac1
repo_name: mozilla-central
repo_url: https://hg.mozilla.org/mozilla-central

Those revisions match what I've got in comment 31. Just to be extra sure, could you try running this from command-line mozregression (if you've got that available), just to launch and test each build as a one-off?

Please confirm that this one is "good"
mozregression --pref "general.smoothScroll.msdPhysics.enabled:true" --launch 2022-04-07

and this one is "bad":
mozregression --pref "general.smoothScroll.msdPhysics.enabled:true" --launch 2022-04-08

(This will run with a fresh profile with the msdPhysics pref already flipped.)

Based on your GUI run, we'd expect the -07 one to be "good" and the -08 one to be "bad", but per comment 32 - comment 33 that also doesn't make a lot of sense, so it'd be good to double-check.

Thanks!

(In reply to Daniel Holbert [:dholbert] from comment #35)

Those revisions match what I've got in comment 31. Just to be extra sure, could you try running this from command-line mozregression (if you've got that available), just to launch and test each build as a one-off?

Please confirm that this one is "good"
mozregression --pref "general.smoothScroll.msdPhysics.enabled:true" --launch 2022-04-07

and this one is "bad":
mozregression --pref "general.smoothScroll.msdPhysics.enabled:true" --launch 2022-04-08

Sorry for the delay, yesterday I haven't the bug
I confirm that 2022-04-07 is good and 2022-04-08 is bad (I launched the two commands above)

(In reply to Daniel Holbert [:dholbert] from comment #24)

If you can reproduce the bug tomorrow (~24h from now), it would be useful if you could perform your comment 9 in an up-to-date Firefox build at that point with relevant MOZ_LOG logging -- something like this:

export MOZ_LOG=Widget:5,WidgetDrag:5,sync,timestamp
mkdir /tmp/test-profile
$NIGHTLY-DIR/firefox -profile /tmp/test-profile 2> /tmp/test-log.txt

I'm uploading that for you

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

Attachment

General

Creator:
Created:
Updated:
Size: