mousedown/mouseup events bubble when clicking on the scrollbar on Linux
Categories
(Core :: DOM: UI Events & Focus Handling, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox55 | --- | affected |
People
(Reporter: julienw, Unassigned)
References
Details
Attachments
(1 file)
1.76 KB,
text/html
|
Details |
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
Comment 1•7 years ago
|
||
Also shows "mousedown" and "mouseup" on Windows 8.1.
Reporter | ||
Comment 2•7 years ago
|
||
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
Comment 3•7 years ago
|
||
I think Olli will have relevant thoughts here.
Comment 4•7 years ago
|
||
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.
Reporter | ||
Comment 5•7 years ago
|
||
@Andrew: yep, that's what I explain in comment 0 :) But we get mousedown/mouseup events, and I think we shouldn't.
Reporter | ||
Comment 6•6 years ago
|
||
Karl's lightning talk pointed to bug 1365761, this sounds related. Too bad :botond hadn't fixed both bugs in one patch ;)
Comment 7•6 years ago
|
||
And I think we should get mousedown/up :) Why we shouldn't get mousedown/up?
Updated•6 years ago
|
Reporter | ||
Comment 8•6 years ago
|
||
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).
Comment 9•6 years ago
|
||
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.
Assignee | ||
Updated•5 years ago
|
Comment 11•2 years ago
|
||
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?
Updated•2 years ago
|
Description
•