Open Bug 1672784 Opened 4 years ago Updated 2 years ago

Autoscroll stops responding to mouse movements when cursor is over another iframe

Categories

(Firefox :: General, defect)

Firefox 84
defect

Tracking

()

Tracking Status
firefox-esr78 --- wontfix
firefox83 --- wontfix
firefox84 --- wontfix
firefox85 --- fix-optional

People

(Reporter: gwarser, Unassigned)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0

Steps to reproduce:

  • Enable "Use autoscrolling" in Preferences -> General.
  • Load page with two iframes (test attached)
  • Middle click (or press and hold) over one (top) iframe
  • Move mouse cursor down, to slowly and steadily scroll down
  • Wait until next iframe moves under the cursor
  • Move cursor up, to change scroll direction

Actual results:

Nothing happens, page is scrolling down without user control.

Expected results:

Scroll direction should change.

From what I see 78, 82, 83 and 84 are affected. 72 seems to be good.

With mozregression tabs are crashing again and again - even recent versions. Why this might be?

Component: Untriaged → DOM: UI Events & Focus Handling
Product: Firefox → Core

89:54.47 INFO: Running autoland build built on 2019-12-20 21:31:20.778000, revision 2fa2cb1f
90:07.00 INFO: Launching /tmp/tmps40zf_pi/firefox/firefox
90:07.00 INFO: Application command: /tmp/tmps40zf_pi/firefox/firefox -profile /tmp/tmp9xxb1zbr.mozrunner
90:07.02 INFO: application_buildid: 20191220200211
90:07.02 INFO: application_changeset: 2fa2cb1fe36bc4e85ae8920c366ef2749f182ffc
90:07.02 INFO: application_name: Firefox
90:07.02 INFO: application_repository: https://hg.mozilla.org/integration/autoland
90:07.02 INFO: application_version: 73.0a1
Was this integration build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', 'back' or 'exit' and press Enter): good
90:29.64 INFO: Narrowed integration regression window from [5af78a6c, 2c56e1bf] (3 builds) to [2fa2cb1f, 2c56e1bf] (2 builds) (~1 steps left)
90:29.64 INFO: No more integration revisions, bisection finished.
90:29.64 INFO: Last good revision: 2fa2cb1fe36bc4e85ae8920c366ef2749f182ffc
90:29.64 INFO: First bad revision: 2c56e1bfbff982873521af50eb62c7bf8f300cf1
90:29.64 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=2fa2cb1fe36bc4e85ae8920c366ef2749f182ffc&tochange=2c56e1bfbff982873521af50eb62c7bf8f300cf1

This was painful, tab crashed all the time because of new version of glib in my system (bug 1660901).

Has Regression Range: --- → yes
Regressed by: 1597765

I was able to confirm bisection without tab crashes by running:

 mozregression --bad 82 --pref general.autoScroll:true security.sandbox.content.level:0

This is also broken with fission, when test page is run directly from bugzilla attachment (but not from local server or from file). Note that, when run from bugzilla, iframes fails to load because of mixed content.

And it looks even more complicated with fission, because all seems fine after reload. It's only first load in new tab when it fails.

Flags: needinfo?(surkov.alexander)

no longer involved into the fission project, sorry, redirecting ni? request to Neil

Flags: needinfo?(surkov.alexander) → needinfo?(enndeakin)

(Given it is a regression of bug 1597765, switch to the same component as bug 1597765)

Component: DOM: UI Events & Focus Handling → General
Product: Core → Firefox
Severity: -- → S3

There are two codepaths taken. The APZ version handles subframes and works fine with the testcase above. The toolkit version does not.

Which codepath is used is determined by the return value of nsIRemoteTab::StartApzAutoscroll. However, this sometimes returns true and sometimes return false. Sometimes reloading the page switches what value will be returned. Sometimes, just clicking the mouse and trying another autoscroll will switch whether StartApzAutoscroll returns true or not. That seems odd to me.

I tested using mac with fission enabled and disabled.

Flags: needinfo?(enndeakin)
Status: UNCONFIRMED → NEW
Ever confirmed: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: