Dragging a scrollbar of a block anchor is not possible as expected, because link's drag-and-drop operation is started.
Categories
(Core :: XUL, defect, P5)
Tracking
()
Tracking | Status | |
---|---|---|
firefox97 | --- | verified |
People
(Reporter: big.sea.cow, Assigned: edgar)
References
()
Details
(Keywords: testcase, Whiteboard: [testday-20110902])
Attachments
(3 files, 1 obsolete file)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070115 Minefield/3.0a2pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070115 Minefield/3.0a2pre Dragging a scrollbar of a block anchor is not possible as expected in FireFox, because link's drag-and-drop operation is started. My test case works fine in IE6, IE7 or Opera 9. Reproducible: Always Steps to Reproduce: Drag a scrollbar of a block anchor (the "a" tag with "display: block","ovewflow: auto" and bigger content). Actual Results: The scrollbar of the block anchor can not be dragged as expected, because link's drag-and-drop operation is started. Expected Results: The scrollbar should be dragable. Link's drag-and-drop operation should be started only when anchor's content is dragged not scrollbars.
Comment 1•18 years ago
|
||
Comment 2•15 years ago
|
||
do you see this problem when using FF3? Or better yet, current beta of 3.1? http://www.mozilla.com/en-US/firefox/all-beta.html
Comment 3•15 years ago
|
||
@Reporter, we have not heard back from you in a while, so I am closing this bug as INCOMPLETE. You can reopen this bug if more information becomes available. Some helpful information you can provide us is found at http://quality.mozilla.org/bug-writing-guidelines. You should also use a recent version of Firefox, from http://www.getfirefox.com.
Reporter | ||
Comment 4•15 years ago
|
||
The bug can be easily reproduces on FF 3.0.9 running in safe mode.
Comment 5•15 years ago
|
||
seeing this in trunk, but not sure if this is desired or not.
This bug happens all the time with me, I'm developing some kinda combobox (same as select of html) and this bug is **** up the project. This bug happens ONLY on Firefox, my project is even working on IE6 ¬¬'.
Comment 7•14 years ago
|
||
I also have the same problem. Has someone found a workaround ?
Comment 8•14 years ago
|
||
Not a parser bug.
Comment 9•14 years ago
|
||
Would it make sense for scrollbar drags to preventDefault or something?
We already have in scrollbar.xml: <handler event="click" preventdefault="true" action="event.stopPropagation();"/> We need to add something similar for mousedown I guess
Comment 11•13 years ago
|
||
Amazing that this bug hasn't been fixed yet. I figured it's a good small bug for my first ever Mozilla bug fix so went and downloaded the mozilla-central and added this to scrollbar.xml and built it and it works. I have no idea what tests I need to do... It's a tiny change. Attaching the patch now.
Comment 12•13 years ago
|
||
I have no idea where to start with Mochitest. Robert O'Callahan, could you have a look please? Thanks
Updated•13 years ago
|
Comment 13•13 years ago
|
||
Neil should probably review the patch. And the patch has tabs. Please use spaces.
Comment 14•13 years ago
|
||
Damn. Didn't notice that. Can I edit it somehow? What should I do?
Comment 15•13 years ago
|
||
Upload a new patch without tabs.
Updated•13 years ago
|
Updated•13 years ago
|
Comment 16•13 years ago
|
||
Wrong Neil ;) But there needs to be a new patch without tabs, and tests are required too. Perhaps you could add something to existing scrollbar tests. I'll try to find a test to modify...
Comment 17•13 years ago
|
||
Updated•13 years ago
|
Comment 18•13 years ago
|
||
Comment on attachment 524231 [details] [diff] [review] Patch with spaces instead of tabs You could add a test to toolkit/content/tests/widgets/test_scrollbar.xul Add an <html:a> element, then synthesize a mouse down, a couple of mousemove events and a mouseup, (all using synthesizeMouse) then check the scroll position scrollTop.
Comment 20•13 years ago
|
||
Some open bugs about scrollbars not working properly because they are a part of a selection, but where the selection is not because of an <a>: bug 345312, bug 442378, bug 491079, bug 572504, bug 649684; Possibly also bug 464655.
Updated•13 years ago
|
Comment 21•9 years ago
|
||
This is still happening in Firefox 39!
Comment 22•8 years ago
|
||
Hamish, do you have plans to pick up your patch (and add tests)?
Updated•8 years ago
|
Comment 23•8 years ago
|
||
I had completely forgotten about this. This was my first and only patch for Mozilla. I'll have a look at what it would take for me to finish this off but I'll be familiarising my self with everything from scratch. Someone already familiar with the project could probably pick this up and get it done in minutes, so if someone wants to do that, please go ahead.
Comment 24•8 years ago
|
||
Thanks for the speedy reply -- I'd be happy to pick it up since it's currently breaking a BBC site. But I won't be able to get to it until the end of the week/early next week. If you haven't assigned it to yourself by then, I might grab it. :)
Comment 25•3 years ago
|
||
Bulk-downgrade of unassigned, untouched DOM/Storage bug's priority.
If you have reason to believe, this is wrong, please write a comment and ni :jstutte.
Updated•3 years ago
|
Comment 26•3 years ago
|
||
That should be interesting to have eyeballs from the UX team.
Maybe Dennis will look at it to see if it's simple or not to fix.
Comment 27•2 years ago
|
||
So, I don't know if this is not simple to fix, or if my understanding is just too limited to understand what's going on here.
The patch in this bug was adjusting XUL stuff, but this got removed a couple of years ago. These days, the elements you see in that XML are created programmatically, namely in nsScrollbarFrame::CreateAnonymousContent
. Unfortuantely, you can't just add a event.stopPropagation()
there.
There are some comments from :bgrins about these specific scrollbar handlers in bug 1431246 comment 4 and the comments after that. From my somewhat limited understanding, I share his understanding that nsXULElement::IsEventStoppedFromAnonymousScrollbar
should already make this drag-interaction impossible, although I don't understand the order of things when we scroll a block element as it's the case in this bug. Clearly I'm missing something here.
Unfortunately, I'm not deep enough into this code to be able to suggest a way forward here. If this is an interesting bug to someone, :smaug may be a good person to talk to. Or maybe Emilio?
Comment 28•2 years ago
|
||
https://searchfox.org/mozilla-central/rev/1e5b6b30d96e9bd7d63eb22bda6f43cf212b5819/dom/xul/nsXULElement.cpp#911 doesn't seem to handle mousedown, so that'd be the equivalent to the xul patch above I believe. About why having Dragstart there doesn't seem to be enough, we probably create Dragstart from the mousedown event or so, but it's just a guess and rr is not working for me atm, so would need to dig more.
Comment 29•2 years ago
|
||
eDragStart
is synthesized from eMouseMove
, not eMouseDown
.
https://searchfox.org/mozilla-central/rev/bc5e79f3ae0f42cb4a6ebd05fc32f48a3829059d/dom/events/EventStateManager.cpp#690,733-735,744-745,748
I guess that it captures mouse pointer for changing scroll position, then, it needs to make PresShell::IsMouseCapturePreventingDrag()
return true
.
Edgar may be familiar around here.
Assignee | ||
Comment 30•2 years ago
|
||
(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #29)
I guess that it captures mouse pointer for changing scroll position, then, it needs to make
PresShell::IsMouseCapturePreventingDrag()
returntrue
.
Yeah, we probably need to prevent drag while capturing mouse in https://searchfox.org/mozilla-central/rev/3d94f040d68627d07fb06be04a05cad33cda10d4/layout/xul/nsSliderFrame.cpp#1270-1271.
Assignee | ||
Comment 31•2 years ago
|
||
Assignee | ||
Comment 32•2 years ago
|
||
Updated•2 years ago
|
Updated•2 years ago
|
Assignee | ||
Comment 33•2 years ago
|
||
Comment 35•2 years ago
|
||
Pushed by echen@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/e7a9eb5be591 Prevent drag-and-drop operation while dragging a scrollbar; r=masayuki
Comment 36•2 years ago
|
||
bugherder |
Updated•2 years ago
|
Updated•2 years ago
|
Comment 38•2 years ago
|
||
Reproduced the issue with affected Firefox 95.0a1 (20211005215418) on Windows 10x64. Dragging scrollbar from the attached test case drags the frame as well. Also using Ctrl+A inside a PDF and then dragging the scroll bar blocks the scroll bar.
I can no longer reproduce the issue with Firefox 97.0b9 (20220127193706) on Windows 10x64, macOS 10.15 and Ubuntu 20.04. Dragging the scroll bar inside the attached test case and inside a PDF after using CTRL+A works as expected.
Updated•2 years ago
|
Description
•