Closed Bug 1575485 Opened 5 years ago Closed 5 years ago

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

Categories

(Toolkit :: UI Widgets, defect, P2)

67 Branch
Desktop
Unspecified
defect

Tracking

()

VERIFIED FIXED
mozilla71
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:

  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?

Flags: needinfo?(vporof)
Blocks: war-on-xbl
Attached image Screenshot
Has Regression Range: --- → yes
Has STR: --- → yes
Summary: Unable scroll Sidebar/Library window with turning the mouse wheel when the mouse pointer is over scrollbar → Unable scroll Sidebar/Library window with turning the mouse wheel on scrollbar

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

Flags: needinfo?(bgrinstead)
Flags: needinfo?(vporof)
No longer blocks: war-on-xbl

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.

Priority: -- → P2

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

I think I have a fix for this

Assignee: nobody → bgrinstead
Status: NEW → ASSIGNED
Flags: needinfo?(bgrinstead)
Attachment #9099985 - Attachment description: Bug 1575485 - WIP - Listen to tree events on the shadowRoot instead of the host element → Bug 1575485 - Listen to tree events on the shadowRoot instead of the host element
Attachment #9099985 - Attachment description: Bug 1575485 - Listen to tree events on the shadowRoot instead of the host element → Bug 1575485 - Listen to legacy mouse scroll events on <tree> shadowRoot instead of the host element
Pushed by bgrinstead@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/e6ddee7b827e Listen to legacy mouse scroll events on <tree> shadowRoot instead of the host element r=NeilDeakin
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla71

Is this something we should consider uplifting to ESR68?

Flags: needinfo?(bgrinstead)

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.

Status: RESOLVED → VERIFIED
Flags: qe-verify+

(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.

Flags: needinfo?(bgrinstead)

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

See Also: → 1601184
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: