Closed Bug 1471415 Opened 6 years ago Closed 6 years ago

No longer able to scroll content area with mouse wheel while arrow panel pop-upped

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

59 Branch
x86_64
Windows 10
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla63
Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- verified
firefox61 --- verified
firefox62 + verified
firefox63 --- verified

People

(Reporter: alice0775, Assigned: emilio)

References

Details

(Keywords: regression)

Attachments

(1 file)

Reproducible: always

Steps To Reproduce:
1. Open any long page (e.g, https://www.mozilla.org/en-US/firefox/ )
2. Click on identify box  / Star icon / Library icon / Menu icon
3. Try scroll content area with mouse while

Actual results:
unable to scroll content area with mouse wheel

Expected Results:
able to scroll


Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9096413092d05a53cd5da66ffe8ed2dfd892fa6b&tochange=fceda645f5e3f6cb4f429d5c8efcdeb5a6913e40


Regressed by: fceda645f5e3	Emilio Cobos Álvarez — Bug 1423990: Move the last few attribute-related methods outside of nsIContent. r=bz


:emilio,
Your patch seems to cause the regression, can you please look into this?


(FYI, notification arrow panel such as webRTC-shareDevices-notification are not affected)
Flags: needinfo?(emilio)
Maybe also related to bug 1457085? There the event gets shipped to the outer list instead of the inner. I believe the scroll feature is quite important for TB users.
See Also: → 1457085
Welp... I'll take a look, yeah, thanks Alice.

(In reply to Jorg K (GMT+2) from comment #1)
> Maybe also related to bug 1457085? There the event gets shipped to the outer
> list instead of the inner. I believe the scroll feature is quite important
> for TB users.

As a TB user I agree :-). We'll see whether it's related or not.
Assignee: nobody → emilio
See Also: → 1471531
Yesterday I audited the patch carefully and I couldn't find anything, I'm checking out that revision and reverting, then partially re-applying to see which change introduces it.
Am stupid. Found it.
Flags: needinfo?(emilio)
Attachment #8988537 - Flags: review?(bugs)
Comment on attachment 8988537 [details]
Bug 1471415: Fix logic in nsXULPopupManager::ShouldConsumeOnMouseWheelEvent. r=smaug

Olli Pettay [:smaug] has approved the revision.

https://phabricator.services.mozilla.com/D1863
Attachment #8988537 - Flags: review+
Do we need this on branches?
Sadly it doesn't fix bug 1457085. There instead of scrolling the autocomplete popup list, the underlying list of recipients is scrolled, so clearly the wrong widget processes the scroll event :-(
(In reply to Jorg K (GMT+2) from comment #8)
> Sadly it doesn't fix bug 1457085. There instead of scrolling the
> autocomplete popup list, the underlying list of recipients is scrolled, so
> clearly the wrong widget processes the scroll event :-(

Was that regressed by the same patch? That looks like a way more recent regression according to the regression range there.

(In reply to Olli Pettay [:smaug] from comment #7)
> Do we need this on branches?

Presumably, yeah, though nobody noticed until now...
Pushed by emilio@crisal.io:
https://hg.mozilla.org/integration/autoland/rev/6c5c7f763b65
Fix logic in nsXULPopupManager::ShouldConsumeOnMouseWheelEvent. r=smaug
(In reply to Emilio Cobos Álvarez [:emilio] from comment #9)
> Was that regressed by the same patch?
No, it wasn't. It was regressed by this line:
https://hg.mozilla.org/mozilla-central/rev/63c152ad62b0#l4.12
when the autocomplete popup was switched from a tree to a list in bug 1427366. As a consequence two lists are now interacting badly: The popup and the list of recipients behind it. This switch exposed an ancient XUL bug that the event gets delivered to the wrong consumer, or the wrong XUL widget consumes it. Sadly TB seems to be the only Gecko application to use "list on top of list", so it's up to us to fix the underlying toolbox :-( - I was hoping that perhaps the fix to "something goes to the wrong consumer" in this bug might fix the issue, but that was wishful thinking.
https://hg.mozilla.org/mozilla-central/rev/6c5c7f763b65
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
Blocks: 1470777
Considered Bug 1470777, how hard would it be to uplift this?
Comment on attachment 8988537 [details]
Bug 1471415: Fix logic in nsXULPopupManager::ShouldConsumeOnMouseWheelEvent. r=smaug

Approval Request Comment
[Feature/Bug causing the regression]: bug 1423990
[User impact if declined]: See the description of this bug, bug 1470777, bug 1471531
[Is this code covered by automated tests?]: no
[Has the fix been verified in Nightly?]: yes
[Needs manual test from QE? If yes, steps to reproduce]: see STR of this bug.
[List of other uplifts needed for the feature/fix]: none
[Is the change risky?]: no
[Why is the change risky/not risky?]: one-character fix that restores the logic from pre-bug 1471531
[String changes made/needed]: none
Attachment #8988537 - Flags: approval-mozilla-release?
Attachment #8988537 - Flags: approval-mozilla-beta?
No longer blocks: 1470777
Comment on attachment 8988537 [details]
Bug 1471415: Fix logic in nsXULPopupManager::ShouldConsumeOnMouseWheelEvent. r=smaug

Trivial logic error fix, approving for 62.0b5 and 61.0.1.
Attachment #8988537 - Flags: approval-mozilla-release?
Attachment #8988537 - Flags: approval-mozilla-release+
Attachment #8988537 - Flags: approval-mozilla-beta?
Attachment #8988537 - Flags: approval-mozilla-beta+
Flags: qe-verify+
I've reproduced this issue on Firefox 63.0a1 (2018-06-26) under Windows 10 x64. 
This behavior no longer occurs on Firefox 63.0a1 (2018-07-04), Firefox 62.0b5 and Firefox 61.0.1 under Windows 10 x64, Ubuntu 16.04 x32 and macOS 10.12.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
Flags: in-qa-testsuite?
Flags: in-qa-testsuite? → in-qa-testsuite+
Comment on attachment 8988537 [details]
Bug 1471415: Fix logic in nsXULPopupManager::ShouldConsumeOnMouseWheelEvent. r=smaug

This appears to be working well on release, taking for ESR 60.2 also.
Attachment #8988537 - Flags: approval-mozilla-esr60+
This bug is no longer reproducible, also on 60.2.0esr (20180830204350)under Windows 10 x64, macOS 10.13 and Ubuntu 16.04 x64.
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.