Open Bug 1352332 Opened 7 years ago Updated 2 years ago

mousedown/mouseup events bubble when clicking on the scrollbar on Linux

Categories

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

55 Branch
Unspecified
Linux
defect

Tracking

()

Tracking Status
firefox55 --- affected

People

(Reporter: julienw, Unassigned)

References

Details

Attachments

(1 file)

Attached file testcase
STR:
1. Load the testcase.
2. click the scrollbar with the mouse.

=> See "mousedown" and "mouseup" are displayed in the log window (but not "click").

One issue with this is that some libraries use mousedown and mouseup to trigger a context menu, see for example [1]. As a result scrolling slowly the scrollbar will trigger the context menu.

I'm filing this bug because the behavior seems unconsistent accross platforms. For example it seems to work like described here on Linux, but on MacOS we don't seem to propagate the events.

[1] https://github.com/vkbansal/react-contextmenu/blob/dc3b676d7d63fc69f8ba756a5a0ff06d449df20d/src/ContextMenuTrigger.js#L31
Also shows "mousedown" and "mouseup" on Windows 8.1.
FWIW this currently manifests in the perf-html tool, for the tree's scrollbar. For example try to slowly scroll the tree using the scrollbar in the following URL: https://perf-html.io/public/f1c034199abaa5756b405cd3fbcc9d65c3f34c28/calltree/?invertCallstack&search=js%3A%3AAtomize%28&thread=0
I think Olli will have relevant thoughts here.
Flags: needinfo?(bugs)
Priority: -- → P2
FWIW if I click around (or click and drag) on the scrollbar, I don't get click events at all in either Nightly or Chrome on Windows 10. I *do* get click events in both if I click in the text area itself.
@Andrew: yep, that's what I explain in comment 0 :)
But we get mousedown/mouseup events, and I think we shouldn't.
Karl's lightning talk pointed to bug 1365761, this sounds related. Too bad :botond hadn't fixed both bugs in one patch ;)
See Also: → 1365761
And I think we should get mousedown/up :)

Why we shouldn't get mousedown/up?
Flags: needinfo?(bugs)
Flags: needinfo?(felash)
My main issue is that when the user interacts with the scrollbar he doesn't interact with the page and this yields unexpected results like bringing in the context menu in my case.

It's also inconsistent because we get "mousedown/up" but not "click".
It's also inconsistent because the behavior is different on Mac (this should be retested though, I tested several months ago).

Now I see Chrome has the same behavior as we have (on Linux at least).
Flags: needinfo?(felash)
FWIW, we could add some more events too https://searchfox.org/mozilla-central/rev/062e1cf551f5bf3f0af33671b818f75a55ac497b/dom/xul/nsXULElement.cpp#1290, but I'm not convinced it is the right thing to do.
Component: Event Handling → User events and focus handling

I see a wacky thing on Google Sheets on nightly linux on Xorg (not Wayland) on Ubuntu 22.04 where if I press and hold down on the scrollbar and then move my mouse to the right of the window so it's outside the window, I scroll a bit, then release the mouse, some scrolling state machine gets in a bad way presumably because it didn't see the mouse up but did see the mouse down.

Until I make a point of going into the scroll region again and giving it a mouse-up event, any time my mouse moves through the scrollbar region, the sheet scrolls although the scroll thumb does not update. Since I have 2 monitors and the sheets window is on the right side of the left monitor, this results in a lot of wacky scrolling.

I presume this is a result of this bug where Google Sheets is trying to implement scrolling logic itself and it's activating because our scrollbar is letting it see the mouse down? And then it goes crazy because it can't possibly see a mouse up outside of the window, but our scrollbar handling logic can because we're using a platform widget that performs an input capture?

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: