User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/118.0

Steps to reproduce:

1. Set general.autoScroll to false in the about:config
2. Open the the testcase.html
3. Middle click the button.

Actual results:

Nothing happened.

Expected results:

Alert dialog should be shown.

Regression window:

2023-08-13T17:44:50.558000: INFO : Narrowed integration regression window from [281695eb, 92ad9c74] (3 builds) to [728f4a4d, 92ad9c74] (2 builds) (~1 steps left)
2023-08-13T17:44:50.575000: DEBUG : Starting merge handling...
2023-08-13T17:44:50.575000: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=92ad9c748611fc9b5be547415a651f136a27346f&full=1
2023-08-13T17:44:50.575000: DEBUG : redo: attempt 1/3
2023-08-13T17:44:50.575000: DEBUG : redo: retry: calling _default_get with args: ('https://hg.mozilla.org/integration/autoland/json-pushes?changeset=92ad9c748611fc9b5be547415a651f136a27346f&full=1',), kwargs: {}, attempt #1
2023-08-13T17:44:50.583000: DEBUG : urllib3.connectionpool: Resetting dropped connection: hg.mozilla.org
2023-08-13T17:44:53.829000: DEBUG : urllib3.connectionpool: https://hg.mozilla.org:443 "GET /integration/autoland/json-pushes?changeset=92ad9c748611fc9b5be547415a651f136a27346f&full=1 HTTP/1.1" 200 None
2023-08-13T17:44:53.850000: DEBUG : Found commit message:
Bug 1792110 - Make no common ancestor between mouseup and mousedown when the input control type is different r=edgar

Depends on D180379

Differential Revision: https://phabricator.services.mozilla.com/D182383

2023-08-13T17:44:53.850000: DEBUG : Did not find a branch, checking all integration branches
2023-08-13T17:44:53.855000: INFO : The bisection is done.
2023-08-13T17:44:53.858000: INFO : Stopped

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

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

For more information, please visit BugBot documentation.

Odd, I don't reproduce this with the secondary button (the right button)...

I have some confusions. We don't fire the click event because it's prevented at https://searchfox.org/mozilla-central/rev/da1e39f50ef43145623938141c970437b226da9e/toolkit/actors/AutoScrollChild.sys.mjs#379-382.

We used to be able to fire the event before bug 1792110 because I believe there was a bug in our code, such that the old code used mLastRightMouseDownContent for middle click at here, and used mLastMiddleMouseDownContent at here for middle click. So the above preventClickEvent() didn't work as expected.

Masayuki, do you know if this is expected?

(In reply to Sean Feng [:sefeng] from comment #4)

I have some confusions. We don't fire the click event because it's prevented at https://searchfox.org/mozilla-central/rev/da1e39f50ef43145623938141c970437b226da9e/toolkit/actors/AutoScrollChild.sys.mjs#379-382.

Yes, but the first step of the STR is:

Set general.autoScroll to false in the about:config

Chrome fires auxclick if auto-scroll is not available.

We used to be able to fire the event before bug 1792110 because I believe there was a bug in our code, such that the old code used mLastRightMouseDownContent for middle click at here, and used mLastMiddleMouseDownContent at here for middle click. So the above preventClickEvent() didn't work as expected.

Ah, yeah, that looks like a bug. Does preventClickEvent() is called in the testcase? If so, something is wrong in AutoScrollChild.sys.mjs.

I do have general.autoScroll = false.

And yeah preventClickEvent() is called in the testcase.

The regressing change was reverted for 117.0b9 - setting the status for that release accordingly.

(In reply to Sean Feng [:sefeng] from comment #6)

And yeah preventClickEvent() is called in the testcase.

Oh... The pref checked at:

• https://searchfox.org/mozilla-central/rev/d81e60336d9f498ad3985491dc17c2b77969ade4/browser/actors/ClickHandlerChild.sys.mjs#20
• https://searchfox.org/mozilla-central/rev/d81e60336d9f498ad3985491dc17c2b77969ade4/toolkit/content/widgets/browser-custom-element.js#1332

I guess that the pref should be checked here too:
https://searchfox.org/mozilla-central/rev/d81e60336d9f498ad3985491dc17c2b77969ade4/toolkit/actors/AutoScrollChild.sys.mjs#340
Otherwise, it consumes the click even if the feature is disabled.

Although _scrollable will be cleared if general.autoscroll is set
to false, AutoScrollChild could receive the mouseup event before
it clears out, so we need to check general.autoscroll when mouseup
occurs.

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

:sefeng could you please nominate this for beta uplift when ready?

Comment on attachment 9349590 [details]
Bug 1848540 - Check general.autoscroll in AutoScrollChild for mouseup r=#dom-core,masayuki

Beta/Release Uplift Approval Request

• User impact if declined: auxclick may not be working properly when 'general.autoScroll' is set to false
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The change is trivial
• String changes made/needed:
• Is Android affected?: Unknown

Comment on attachment 9349590 [details]
Bug 1848540 - Check general.autoscroll in AutoScrollChild for mouseup r=#dom-core,masayuki

Approved for 118.0b2

I've reproduced this issue in Nightly 118.0a1 (2023-08-13) following the STR from Comment 0 on Windows 10 x64 .
Verified as fixed on the latest Nightly 119.0a1 , Firefox 118.0b2 and Firefox 117.0 versions under same configuration where the alert dialog is triggered when middle-clicking on the button.