1575485 - Unable scroll Sidebar/Library window with turning the mouse wheel on scrollbar

Status: VERIFIED FIXED

(Toolkit :: UI Widgets, defect, P2)

Description

[Alice0775 White]

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:

1. Open sidebar or Library window
2. Make sure that vertical scrolbar appears
3. Move mouse pointer on the scrollbar.
4. 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?

Comment 1

[Alice0775 White]

Attachment: Screenshot

Comment 2

[Pascal Chevrel:pascalc (PTO until April 26)]

Brian, could you triage and prioritize this regression please? Thanks

Comment 3

[Brian Grinstead [:bgrins]]

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.

Comment 4

[Brian Grinstead [:bgrins]]

Attachment: Bug 1575485 - Listen to legacy mouse scroll events on <tree> shadowRoot instead of the host element

Comment 5

[Liz Henry (:lizzard) (relman/hg->git project)]

Too late for 70 but happy to take this in 71.

Comment 6

[Brian Grinstead [:bgrins]]

I think I have a fix for this

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e6ddee7b827e
Listen to legacy mouse scroll events on <tree> shadowRoot instead of the host element r=NeilDeakin

Comment 8

[Oana Pop-Rus]

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

Comment 9

[Ryan VanderMeulen [:RyanVM]]

Is this something we should consider uplifting to ESR68?

Comment 10

[Anca Soncutean, Desktop QA]

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.

Comment 11

[Brian Grinstead [:bgrins]]

(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

[Ryan VanderMeulen [:RyanVM]]

OK, calling ESR68 wontfix in that case. The TB folks can still uplift to their branch if they so desire.