367028 - Dragging a scrollbar of a block anchor is not possible as expected, because link's drag-and-drop operation is started.

Status: VERIFIED FIXED

(Core :: XUL, defect, P5)

Description

[Michal Cizmazia]

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

[Steve England [:stevee]]

Attachment: testcase from reporter's URL

Comment 2

[Wayne Mery (:wsmwk)]

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

[Tyler Downer [He/Him]]

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

Comment 4

[Michal Cizmazia]

The bug can be easily reproduces on FF 3.0.9 running in safe mode.

Comment 5

[Tyler Downer [He/Him]]

seeing this in trunk, but not sure if this is desired or not.

Comment 6

[Alexander]

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

[Tojo Rakotoarison]

I also have the same problem. 
Has someone found a workaround ?

Comment 8

[Henri Sivonen (:hsivonen)]

Not a parser bug.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Would it make sense for scrollbar drags to preventDefault or something?

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

[Hamish Robertson]

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

[Hamish Robertson]

Attachment: Patch with no tests

I have no idea where to start with Mochitest. Robert O'Callahan, could you have a look please?

Thanks

Comment 13

[Olli Pettay [:smaug][[e-mail]]]

Neil should probably review the patch.

And the patch has tabs. Please use spaces.

Comment 14

[Hamish Robertson]

Damn. Didn't notice that.
Can I edit it somehow?

What should I do?

Comment 15

[Olli Pettay [:smaug][[e-mail]]]

Upload a new patch without tabs.

Comment 16

[Olli Pettay [:smaug][[e-mail]]]

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

[Hamish Robertson]

Attachment: Patch with spaces instead of tabs

Comment 18

[Neil Deakin]

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

[[:Aleksej]]

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.

Comment 21

[Luke]

This is still happening in Firefox 39!

Comment 22

[Mike Taylor [:miketaylr]]

Hamish, do you have plans to pick up your patch (and add tests)?

Comment 23

[Hamish Robertson]

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

[Mike Taylor [:miketaylr]]

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

[Jens Stutte [:jstutte]]

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.

Comment 26

[Karl Dubost💡 :karlcow]

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

[Dennis Schubert [:denschub]]

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

[Emilio Cobos Álvarez [:emilio]]

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

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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.

Comment 30

[Edgar Chen [:edgar]]

(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() return true.

Yeah, we probably need to prevent drag while capturing mouse in https://searchfox.org/mozilla-central/rev/3d94f040d68627d07fb06be04a05cad33cda10d4/layout/xul/nsSliderFrame.cpp#1270-1271.

Comment 31

[Edgar Chen [:edgar]]

Attachment: Bug 367028 - Prevent drag-and-drop operation while dragging a scrollbar;

Comment 32

[Edgar Chen [:edgar]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=f9ee5b5af23f61489b481229523f56a33eb31b94

Comment 33

[Edgar Chen [:edgar]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=4219d0093fcbbeeb5f3ea98f4df57d19efe1c709

Comment 35

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e7a9eb5be591
Prevent drag-and-drop operation while dragging a scrollbar; r=masayuki

Comment 36

[Sandor Molnar[:smolnar]]

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

Comment 38

[Alexandru Trif, Desktop Test Engineering [:atrif]]

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.