41708 - Should be able to scroll in the viewport while dragging

Status: RESOLVED FIXED

(Core :: DOM: Copy & Paste and Drag & Drop, defect, P3)

Description

[Blake Ross]

When dragging links on a page, you should be able to scroll the page up by 
dragging up and scroll it down by dragging down (upward drag should start right 
at the edge where the personal toolbar meets the viewport, and downward drag 
should start right at the edge where the statusbar meets the viewport) as you 
can in IE.  While this isn't _overly_ useful, it's odd if we don't support 
this, since we already support dropping links (url's) into textboxes with 
focus.  Without being able to scroll the viewport, however, there's no way to 
drop links into textboxes not visible in the current view.

Comment 1

[sairuh (rarely reading bugmail)]

afaik, D&D issues should go to xp toolkit... (lemme know otherwise!)

Comment 2

[John Morrison]

... as you can with IE on windows; IE5.5 on mac does not scroll when dragging a 
link. 

Comment 3

[Peter Trudelle]

We weren't able to to that in any other versions of the product either, and
AFAIK there is no requirement for it in this version either. assigning to
pinkerton for a future release.

Comment 4

[Blake Ross]

pink, ideas for doing this?

Comment 5

[Matthew T (active 1999-2002)]

Hummm. Most applications which do this have a buffer zone (rulers, scrollbars, 
toolbars, and associated paraphernalia) between each edge of the viewport and the 
edge of the window, in which they know that holding a dragged object means the 
user wants to scroll (rather than wanting to drag outside the window). In 
Navigator we don't have this luxury: there is practically nothing between the 
left side of the viewport and the left side of the window, and immediately above 
the viewport is the Personal Toolbar which is a drop target. You don't want the 
page to be constantly scrolling while you're dragging a link to the Personal 
Toolbar.

So perhaps we want the D&D auto-scrolling region to be *inside* the viewport 
here, rather than outside? Or would that be too weird?

Comment 6

[Mike Pinkerton (not reading bugmail)]

for tree scrolling (a la bookmarks) the region is w/in the bounds of the tree
(for various implementation reasons). we should try to be consistent, no?

Comment 7

[Matthew T (active 1999-2002)]

Yup -- right down to sharing the same constant for however thick the scrolling 
region is inside the viewport, too. (1 em of the CSS2 large UI font, perhaps.)

This would probably also fix bug 55924.

Comment 8

[Asa Dotzler [:asa]]

->selection

Comment 9

[Asa Dotzler [:asa]]

*** Bug 98226 has been marked as a duplicate of this bug. ***

Comment 10

[Asa Dotzler [:asa]]

*** Bug 228749 has been marked as a duplicate of this bug. ***

Comment 11

[nrlz]

Attachment: Workaround extension

I was bit by this bug while using a web form on a small screen, so I decided to write a workaround for this. It basically registers an ondragover listener and starts scrolling the window if the mouse is within 20 pixels from any edge.

Comment 12

[Martijn Wargers (dead)]

IE6 does this for any scrollable view.

Comment 13

[RenegadeX]

I'm disappointed to see this Bug appears to have been forgotten about.
nrlz's DragToScroll extension solves the problem beautifully, but really we shouldn't need to resort to an extension to do something that should be standard/taken for granted.

Is it too late to get this included in Firefox 3?

Comment 14

[Szabolcs Horvát]

In addition to scrolling the view when the mouse approaches an edge (like IE), it would be nice if the mouse wheel worked while dragging.

Fixing this would be an even greater advantage now, with Firefox 3's other drag and drop improvements (like switching tabs on drag and hover).

Comment 15

[Martijn Wargers (dead)]

(In reply to comment #14)
> In addition to scrolling the view when the mouse approaches an edge (like IE),
> it would be nice if the mouse wheel worked while dragging.

Well, it's your lucky day then, because that is already fixed now that bug 389931 was fixed.

Comment 16

[Szabolcs Horvát]

(In reply to comment #15)
> (In reply to comment #14)
> > In addition to scrolling the view when the mouse approaches an edge (like IE),
> > it would be nice if the mouse wheel worked while dragging.
> 
> Well, it's your lucky day then, because that is already fixed now that bug
> 389931 was fixed.

Hmm ... I still can't seem to scroll the page with the moue wheel while dragging a link or a piece of text.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008030607 Minefield/3.0b5pre ID:2008030607

Comment 17

[Martijn Wargers (dead)]

Hmm, strange, you're right, I could have sworn it worked for me.

Comment 19

[Martijn Wargers (dead)]

Attachment: patch

Ok, well, this doesn't fix what this bug is about, because I don't know how to do that. But this makes it so, that when you're dragging over a scrollbarbutton, scrolling occurs. It works really well. The only thing is that the scrollbar doesn't get a pressed look when dragging over it, which I think should be happening.

Comment 20

[Martijn Wargers (dead)]

Comment on attachment 320976 [details] [diff] [review]
patch

I might as well let it review.

Comment 21

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

+  if ((aEvent->eventStructType == NS_MOUSE_EVENT &&
+       aEvent->message == NS_MOUSE_BUTTON_DOWN) ||
+      aEvent->message == NS_DRAGDROP_ENTER) {

The eventStructType check should be tested for dragdrop events too.

Comment 22

[RenegadeX]

Um, I don't want to sound ungrateful or anything but Martin's solution in Comment 19 is in my opinion a lame workaround. It might actually work without any issues (I haven't tested it) but having to drag text to a scroll-button is inefficient (text is typically dragged so it can be dropped in a text-box which in all likelihood is in the centre(top or bottom) of the screen, not at the right-edge where the scrollbar is), and if this Bug was resolved properly, dragging to scroll-buttons would be unnecessary.

nrlz's DragToScroll extension addresses the issue and solution perfectly - the only problem is it is an extension and not a patch.

Was there actually a good reason why the code from the extension can't be 'ported' into a patch? Or was it just because nobody ever actually got around to turning it into a patch, and submitting it here for review?

--
Aside:
I've been using the DragToScroll extension for nearly 2 1/2yrs (on WinXP), and haven't ever experienced any problems with it. It works in Firefox 3 (just have to override/manually bump the maxversion), though there is a message in the Error Console that warns: "Use of getBoxObjectFor() is deprecated. Try to use element.getBoundingClientRect() if possible".

Looking at the ext's sourcecode, the line which refers to 'getBoxObjectFor' is commented with a note referencing Bug 330818, which has long since been resolved. I tried doing a simple substitution of the terms, but that seemed to break the extension. Maybe I did it wrong?

Regardless, I am embarrassed as a Firefox user that this Bug has been open FOR EIGHT(8) YEARS, and that somehow the Firefox development team released Firefox 3 without getting this very useful feature fixed(added). I'm putting a '?' on the 'wanted for 1.9.1' as this Bug has been overlooked for far too long.

Comment 23

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Selection doesn't seem to be the right component here. What is a better one?

Comment 24

[RenegadeX]

As per Faaborg via a recent Mozillazine thread asking for Firefox 3.1 'polish'
suggestions (http://forums.mozillazine.org/viewtopic.php?f=23&t=938165) - I'm adding him to the CC list and requesting someone with Bug permissions to and the following Whiteboard terms to this bug (less single quotes on each):
'[polish-hard]', '[polish-interactive]' and '[polish-high-visibility]'

Comment 25

[Alex Faaborg [:faaborg] (Firefox UX)]

I'm actually thinking about getting rid of [polish-interactive], the problem is that the category can get broad enough that a sizable percentage of bugs in bugzilla would qualify, and then term then becomes less useful for targeting noticeable blemishes.

Either way, I don't think this qualifies for [polish-high-visibility] since the definition of that is meant to be something that users encounter multiple times throughout the day, and in the initial description of this bug the reporter notes "While this isn't _overly_ useful"

Anyway, my point isn't that this isn't a very valid bug, I really hope this gets fixed.  I just kind of think it feels more like a missing feature than polish problem.

Comment 26

[RenegadeX]

(In reply to comment #25)
> Either way, I don't think this qualifies for [polish-high-visibility] since
> the definition of that is meant to be something that users encounter
> multiple times throughout the day, and in the initial description of this
> bug the reporter notes "While this isn't _overly_ useful".

Um, that his opinion, and that's apparently your opinion. I for one, on the other hand, find it extremely USEFUL and EFFICIENT, and make use of the DragToScroll extension's added functionality multiple times a day, every day, be it a message board, a news site, my local library's site, Wikipedia, Google, AMO, whatever. 

ex: look up now, there's a search box at the top of this Bugzilla page. Seeing the word 'polish-interactive' piqued my curiosity -- what other Bugs have contain this term? Most Firefox users would either:
-A) scroll up the page, 2) left-click in Search textbox, 3) type "polish-interactive" ---> a total of 18 keypresses!!!, --> 22) click 'Find' to submit the search.
-B) highlight the term on the page "polish-interactive", 2) right-click to bring up the context menu, 3) left-click to choose 'Copy' from the context menu, 4) scroll to the top of the page, 5) right-click in the Search text box, 6) left-click to Paste the text, 7) click 'Find' to submit the search.

I, on the other hand like to use my browser efficiently. So I:
- 1) highlight the term on the page "polish-interactive", 2) click-and-hold on it, 3) continuing to hold while moving the mouse to the top of the viewport, to the Search textbox, 4) release the mouse button to drop it in the Search textbox, 5) click Find.

But I can only do this in Firefox because I have an extension installed.

> I just kind of think it feels more like a missing feature than polish problem.

I disagree - dragging while scrolling is more than a 'feature'.. it's an EXPECTATION. Long before Firefox 1.0, IE users (who were the majority) were happily dragging and scrolling, and in fact for all MS Windows users it was a completely natural action given that the behaviour is identical to that in the operating system's File Manager (file 'Explorer') - I haven't checked to confirm but I believe going back as far as 1990's Windows 3.0.

So, transitioning to Firefox, it was a *shock* to suddenly find that an action one had taken for granted for all those years was now not possible. Thus, it's Bugs like this that have always left Firefox seeming 'unpolished'. And if the desire is for Firefox 3.1 to be a 'polished', complete, details-taken-care-of product, then that goal won't be met as long as this Bug remains open.

Frankly, I fear that even if this Bug is finally resolved, not many people will notice or care - as after all this time doing things the slow inefficient way, most Firefox users will continue to be stuck in their habits and do as they have always done as long as they've been using the browser.

Comment 27

[Alex Faaborg [:faaborg] (Firefox UX)]

Fair enough, adding the polish terms back.  Since I think we both agree that this doesn't effect the majority of users on a daily basis it can't qualify as high visibility.

Comment 28

[Alex Faaborg [:faaborg] (Firefox UX)]

P4 - Polish issue that is rarely encountered, and is easily identifiable.

Users who expect this behavior will be annoyed that it doesn't work, however link dragging inside of a page isn't an incredibly common behavior.

Comment 29

[Alex Faaborg [:faaborg] (Firefox UX)]

(switching to whiteboard for polish-relative priorities)

Comment 30

[gaoninza2]

REALLY NEEDING TO FIX THIS BUG

Comment 31

[Steve England [:stevee]]

gaoninza2 don't mess with the flags and don't post useless comments that add nothing to fixing the bug. thanks.

Comment 32

[mjarecki]

What needs to be done to get this bug's priority heightened? It has been open for 9 YEARS! 

Most discussion seems to revolve about the usage pattern for the "majority of users". This consideration seems fine when talking about existing web apps, in which drag/drop is successfully implemented using various JS libraries. 

However with the emergence of newer AJAX/HTML 5 apps utilising the native HTML 5 drag/drop features in 3.5 - of which this outliner demo might be considered an example: http://decafbad.com/2009/07/drag-and-drop/outline.html - the continued existence of this bug hampers the utility of a native drag/drop feature.

"Link dragging" is not the only use case app that is hampered by this bug - future, highly interactive drag/drop apps such as outliners, calendars, galleries, file managers are other examples.

It also puts Firefox behind Webkit in terms of development. For example, the previously mentioned outliner demo scrolls successfully using recent Webkit nightlies.

The existence of plug-ins that largely overcome this bug surely suggest the design pattern for the code exists, and should not be too difficult to implement.

Comment 33

[IU]

Please, can we get this bug fixed.  It's a blooming pain. :-(

Comment 34

[IU]

Attachment: Workaround extension (updated for Firefox 3.0 to 3.7+ compatibility)

Works, but don't bother me for updates 'cause I don't know JavaScript.  Took me forever to get this working.

Comment 35

[IU]

Attachment: Workaround extension (updated for Firefox 3.0 to 3.7+ compatibility)

Minor code clean-up and faster scrolling.

Last bug spam (for a while).  Sorry guys.

@nrlz:  Please take a look and update your mozdev and addons.mo pages with this update, if you're satisfied with the changes.

Thanks

Comment 37

[RenegadeX]

It's now ELEVEN years after this bug was reported; Firefox 4 is just about to be released any day/week now... and has it got Drag & Scroll? Answer: No. Echoing what mjarecki said in Comment 32 in August 2009, WHAT DO WE HAVE TO DO in order to get this bug noticed and finally given the attention and resolution it deserves?

Back in July 2008, I flagged this Bug as "wanted1.9.1?". Not long after, it was changed back to '-'. Blocking1.9.2? ... nope, not any more. Where are we at now? I don't even see a way to flag it for 2.0b13pre or whatever comes next. No wonder this Bug is frozen in time..

Its like some kind of sick joke. If it wasn't for the workaround-extension being available, I would have dumped Firefox. And yes, I use highlighted-text dragging pretty much every day (no exaggeration). Why? Because I can, and it's efficient.

FYI: Google Chrome has drag'n'drop scrolling built in. Which suggests the feature was considered by them useful enough to bother coding. Or, maybe they just wanted to 1-up Firefox?

Thank you 'UI' for the updated workaround-extension posted as Attachment 425734 [details] a full year ago. It still works in Firefox 4.0b13pre (when extension compatibility override is ON). Thank you also for posting the link on the AMO DragToScroll page so that others can install it.

Comment 39

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

I think that we can fix this bug easily after I fixed all regressions of new mouse drag handling for selection.

However, I worry about that this bug fix could cause some regressions on HTML5 D&D applications.

Comment 41

[Giorgio]

we all believe in you Masayuki!

by the way google chrome HASN'T (yet) drag'n'drop scrolling built in.

https://bugzilla.mozilla.org/attachment.cgi?id=501445 test here

works only in ie6+ with autoscroll near the frame border
and in opera using the mouse wheel during drag (only a partial solution)
in chrome and safari definitely not work, yet, like firefox

Comment 43

[Nicolas Barbulesco]

Hello,

I have a page in Firefox. Up in the page, I select some text. I start dragging my selected text downwards. I want to drop my selected text into a text area which is in a form down in the page.

Actual behaviour :

No scrolling happens. So I cannot drop my selected text where I want.

Expected behaviour :

The page scrolls downwards, and I drop my selected text where I want.

Please improve that.

Thank you.

Nicolas

Comment 44

[RenegadeX]

2 things:
1) FYI: a recent change in Firefox seems to have broken the "DragToScroll" extension by nlrz, which has worked for years provided extension version compatibility checking is overridden/set to false.

However, "Drag to Scroll (reloaded)" which was uploaded to AMO by Moonchild in 2013 works.
Get it here: https://addons.mozilla.org/en-us/firefox/addon/drag-to-scroll-reloaded/

2) In Comment#41 made by Giorgio in Nov 2011, he provided a test-case for drag-scrolling text within a frame, and noted that although it worked in IE6+, it didn't yet work in Google Chrome (or Safari). I have just confirmed that the testcase: a) does not work in Firefox, even with the Drag To Scroll workaround extension installed, b) still works in IE(11) provided that dragging pointer is held near the frame scrollbar, and c) that Google Chrome now *DOES* have native drag-to-scroll implemented - and not only does it works on all pages but in the aforementioned test-case it does not require the user to move the pointer near the scrollbar - dragging near the top or bottom of the frame is sufficient. And that's how it should be.

I have not tested Safari, but if IE can do it and Chrome can do it and Firefox can't then really, shouldn't Firefox do it? For the record, this bug is almost 13 years old, and the behaviour has been native to Windows for even longer.

Comment 45

[guerin45]

Microsoft Edge has drag'n'drop scrolling built in like Google Chrome.
Firefox is the last major browser to not have this feature yet...

Comment 46

[Neil Deakin]

Attachment: Scroll scrollframes when dragging over the edge of them

This patch handles any scrollable area.

Comment 47

[Neil Deakin]

Attachment: Scroll scrollframes when dragging over the edge of them

Comment 48

[Mats Palmgren (inactive)]

Comment on attachment 8817228 [details] [diff] [review]
Scroll scrollframes when dragging over the edge of them

The relevant CSS spec is much more stringent these days that
overflow:hidden MUST NOT be scrollable by the user:
https://drafts.csswg.org/css-overflow/#valdef-overflow-hidden
"
hidden
    [...] and that the UA must not provide any scrolling user interface to view the content outside the clipping region, nor allow scrolling by direct intervention of the user, such as dragging on a touch screen or using the scrolling wheel on a mouse. [...]
"

I haven't tested the patch but I'm guessing that just testing
for a non-null nsIScrollableFrame is insufficient since it
would be true also for overflow:hidden.

Comment 49

[Neil Deakin]

The patch only allows drag-scrolls when scrollbars are visible (when ScrollFrameHelper::mHasVerticalScrollbar is true), so this should already handle overflow:hidden no?

Comment 50

[Mats Palmgren (inactive)]

Comment on attachment 8817228 [details] [diff] [review]
Scroll scrollframes when dragging over the edge of them

OK, good.

Comment 51

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

I worked on similar to this bug at bug 552707. At that time, I met much a lot of regressions. The blocker bugs of it might help you.

Comment 52

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

Comment on attachment 8817228 [details] [diff] [review]
Scroll scrollframes when dragging over the edge of them

># HG changeset patch
># User Neil Deakin <[e-mail]>
># Parent  ad993783599ab2ede0cf931fdec02f4df40a7a6d
>
>diff --git a/dom/events/EventStateManager.cpp b/dom/events/EventStateManager.cpp
>--- a/dom/events/EventStateManager.cpp
>+++ b/dom/events/EventStateManager.cpp
>@@ -3322,16 +3322,31 @@ EventStateManager::PostHandleEvent(nsPre
>     }
>     break;
> 
>   case eDragEnter:
>   case eDragOver:
>     {
>       NS_ASSERTION(aEvent->mClass == eDragEventClass, "Expected a drag event");
> 
>+      // Check if the drag is occurring inside a scrollable area. If so, scroll
>+      // the area when the mouse is near the edges.
>+      if (mCurrentTarget && aEvent->mMessage == eDragOver) {
>+        nsIFrame* checkFrame = mCurrentTarget;
>+        while (checkFrame) {
>+          nsIScrollableFrame* scrollFrame = do_QueryFrame(checkFrame);
>+          if (scrollFrame) {
>+            scrollFrame->DragScroll(aEvent);
>+            // Break out so only the innermost scrollframe is scrolled.
>+            break;
>+          }
What happens in other browsers if a scrollable area has been scrolled to all the way up/down/left/right and some ancestor
area could be scrolled? Please test

>+ScrollFrameHelper::DragScroll(WidgetEvent* aEvent)
>+{
>+  // Dragging is allowed while within a 20 pixel border.
>+  nscoord margin = 20 * nsPresContext::AppUnitsPerCSSPixel();
Does this work well on highdpi and non-highdpi setups? Or when the page is zoomed in/out?

>+
>+  // Don't drag scroll for small scrollareas.
>+  if (mScrollPort.width < margin * 2 || mScrollPort.height < margin * 2) {
>+    return;
>+  }
How do other browsers deal with small scroll areas?

Comment 53

[Neil Deakin]

(In reply to Olli Pettay [:smaug] from comment #52)
> Comment on attachment 8817228 [details] [diff] [review]
> Scroll scrollframes when dragging over the edge of them
> 
> ># HG changeset patch
> ># User Neil Deakin <[e-mail]>
> ># Parent  ad993783599ab2ede0cf931fdec02f4df40a7a6d
> >
> >diff --git a/dom/events/EventStateManager.cpp b/dom/events/EventStateManager.cpp
> >--- a/dom/events/EventStateManager.cpp
> >+++ b/dom/events/EventStateManager.cpp
> >@@ -3322,16 +3322,31 @@ EventStateManager::PostHandleEvent(nsPre
> >     }
> >     break;
> > 
> >   case eDragEnter:
> >   case eDragOver:
> >     {
> >       NS_ASSERTION(aEvent->mClass == eDragEventClass, "Expected a drag event");
> > 
> >+      // Check if the drag is occurring inside a scrollable area. If so, scroll
> >+      // the area when the mouse is near the edges.
> >+      if (mCurrentTarget && aEvent->mMessage == eDragOver) {
> >+        nsIFrame* checkFrame = mCurrentTarget;
> >+        while (checkFrame) {
> >+          nsIScrollableFrame* scrollFrame = do_QueryFrame(checkFrame);
> >+          if (scrollFrame) {
> >+            scrollFrame->DragScroll(aEvent);
> >+            // Break out so only the innermost scrollframe is scrolled.
> >+            break;
> >+          }
> What happens in other browsers if a scrollable area has been scrolled to all
> the way up/down/left/right and some ancestor
> area could be scrolled? Please test

Chrome appears to scroll the inner element and then when reaching the scroll edge, the ancestor is scrolled. IE11 prefers to scroll the outermost scrollable element over the innermost always. Safari doesn't support drag scrolling.

> 
> >+ScrollFrameHelper::DragScroll(WidgetEvent* aEvent)
> >+{
> >+  // Dragging is allowed while within a 20 pixel border.
> >+  nscoord margin = 20 * nsPresContext::AppUnitsPerCSSPixel();
> Does this work well on highdpi and non-highdpi setups? Or when the page is
> zoomed in/out?

It uses 20 zoomed pixels. I can make it use 20 unzoomed pixels though.

> >+  // Don't drag scroll for small scrollareas.
> >+  if (mScrollPort.width < margin * 2 || mScrollPort.height < margin * 2) {
> >+    return;
> >+  }
> How do other browsers deal with small scroll areas?

Chrome scrolls anyway. IE9 does not.

One other issue, when the scrollarea area has a large border:

Chrome computes the margin from the outer border box edge (this seems wrong to me). IE uses the inner scroll area and you cannot scroll while in the border/scrollbar area. This patch uses the inner scroll area but allows scrolling while in the border/scrollbar area. I can change prevent this.

Comment 54

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

(In reply to Neil Deakin from comment #53)
> 
> Chrome appears to scroll the inner element and then when reaching the scroll
> edge, the ancestor is scrolled. 
I think I'd prefer that.


> > >+ScrollFrameHelper::DragScroll(WidgetEvent* aEvent)
> > >+{
> > >+  // Dragging is allowed while within a 20 pixel border.
> > >+  nscoord margin = 20 * nsPresContext::AppUnitsPerCSSPixel();
> > Does this work well on highdpi and non-highdpi setups? Or when the page is
> > zoomed in/out?
> 
> It uses 20 zoomed pixels. I can make it use 20 unzoomed pixels though.
I think unzoomed would make more sense (assuming I understand what you mean with those). Zoom level should affect to the ux here, I think

> Chrome computes the margin from the outer border box edge (this seems wrong
> to me). IE uses the inner scroll area and you cannot scroll while in the
> border/scrollbar area. This patch uses the inner scroll area but allows
> scrolling while in the border/scrollbar area. I can change prevent this.
IE behavior sounds a bit better here than what the patch gives.

Comment 55

[Neil Deakin]

Attachment: Scroll scrollframes when dragging over the edge of them, v2

Comment 56

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

Comment on attachment 8820002 [details] [diff] [review]
Scroll scrollframes when dragging over the edge of them, v2


>+  if (offset.x || offset.y) {
>+    ScrollTo(GetScrollPosition() + offset, nsIScrollableFrame::INSTANT);
Did you try non-instant scrolling here? Smooth or normal perhaps?

Comment 57

[Neil Deakin]

https://hg.mozilla.org/integration/mozilla-inbound/rev/b352c7f6bc15bcfe4e8f933045878aa5f1238c55
Bug 41708, support scrolling when hovering over the edge of a scrollframe while dragging, r=smaug

Comment 58

[Phil Ringnalda (:philor)]

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

Comment 60

[Stefan Wessman]

This change is really annoyning when dragging url to create a url-file. There must be a better way to implement this that doesn't interfere with this because right now it absolutely kill productivity for me and that make me furious!

I know you can drag to the side to avoid scrolling

Please make it possible to diable this new behaviour in the next bugfix release.

This is REALLY important, do not ignore !!

Comment 61

[Jerry]

(In reply to Stefan Wessman from comment #60)
> This change is really annoyning when dragging url to create a url-file.
> There must be a better way to implement this that doesn't interfere with
> this because right now it absolutely kill productivity for me and that make
> me furious!
> 
> I know you can drag to the side to avoid scrolling
> 
> Please make it possible to diable this new behaviour in the next bugfix
> release.
> 
> This is REALLY important, do not ignore !!

I second this, considering the fact that this was reported SEVENTEEN years ago it makes zero sense that people who have no need for this feature should suffer.

I only ask for the option to toggle this on or off in the next bugfix, that way everyone can have it both ways and be satisfied.

I apologize for this sounding like I'm whining but I was really taken aback by this.

Comment 62

[Neil Deakin]

Please file a new bug describing the issue you are having including more detailed steps to reproduce about what and how you are dragging.