Unable scroll Sidebar/Library window with turning the mouse wheel on scrollbar
Categories
(Toolkit :: UI Widgets, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
thunderbird_esr60 | --- | unaffected |
thunderbird_esr68 | --- | affected |
firefox-esr60 | --- | unaffected |
firefox-esr68 | --- | wontfix |
firefox67 | --- | wontfix |
firefox68 | --- | wontfix |
firefox69 | --- | wontfix |
firefox70 | --- | wontfix |
firefox71 | --- | verified |
People
(Reporter: alice0775, Assigned: bgrins)
References
(Regression)
Details
(Keywords: nightly-community, regression, ux-consistency)
Attachments
(2 files)
This bug reproduces not only on the Firefox but also on Thunderbird thread pane/folder pane etc.
Especially, the problem becomes noticeable when the sidebar is put on the right side of maximized browser. i.e, breaking Fitts's law.
Reproducible : always
Steps To Reproduce:
- Open sidebar or Library window
- Make sure that vertical scrolbar appears
- Move mouse pointer on the scrollbar.
- Scroll sidebar with turning the mouse wheel
Actual Results:
Nothing happens
Expected Results:
Should scroll with turning the mouse wheel
Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1657fe18be9bc445c7838e3b4e93a9bfc4f85e7f&tochange=a6606e85276716b93695029cb914a678beb51708
Regression by:
a6606e85276716b93695029cb914a678beb51708 Victor Porof — Bug 1523957 - Convert trees to custom elements, r=bgrins, mak, standard8, MattN
Victor, Your patch seems to cause thr regression, can you please look into this?
Reporter | ||
Updated•5 years ago
|
Reporter | ||
Comment 1•5 years ago
|
||
Reporter | ||
Updated•5 years ago
|
Reporter | ||
Updated•5 years ago
|
Reporter | ||
Updated•5 years ago
|
Comment 2•5 years ago
|
||
Brian, could you triage and prioritize this regression please? Thanks
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 3•5 years ago
|
||
I think what's happening is that the DOMMouseScroll event is firing on the scrollbar in the shadow root and not being retargeted to the parent (which is listening at https://searchfox.org/mozilla-central/rev/05a22d864814cb1e4352faa4004e1f975c7d2eb9/toolkit/content/widgets/tree.js#752). We could maybe use just the "wheel" event (which does get retargeted) instead, or add a listener to the scrollbar as well to call the same function.
Assignee | ||
Comment 4•5 years ago
|
||
Comment 5•5 years ago
|
||
Too late for 70 but happy to take this in 71.
Assignee | ||
Comment 6•5 years ago
|
||
I think I have a fix for this
Updated•5 years ago
|
Updated•5 years ago
|
Comment 8•5 years ago
|
||
bugherder |
Updated•5 years ago
|
Comment 9•5 years ago
|
||
Is this something we should consider uplifting to ESR68?
Updated•5 years ago
|
Comment 10•5 years ago
•
|
||
I've reproduce this issue with Fx 70.0a1 (2019-08-21) on Windows 10 x64.
The issue is verified fixed with Fx 72.0a1 (2019-11-03) and Fx 71.0b6 on Windows 10 x64, macOS 10.15 and Ubuntu 18.04 x64.
Is this something we should consider uplifting to ESR68?
If the case I will come back on this matter for ESR build. For now I will remove the qe+ and mark this issue as verified fixed.
Assignee | ||
Comment 11•5 years ago
|
||
(In reply to Ryan VanderMeulen [:RyanVM] from comment #9)
Is this something we should consider uplifting to ESR68?
We certainly could uplift it, but it's not clear to me how noticeable the bug is since it took 6 months or so until the first report. So I'd so let's not in order to limit changes to ESR, but I'm open to being talked into it if someone feels it meets criteria for an ESR uplift.
Comment 12•5 years ago
|
||
OK, calling ESR68 wontfix in that case. The TB folks can still uplift to their branch if they so desire.
Description
•