Last Comment Bug 41708 - Should be able to scroll in the viewport while dragging
: Should be able to scroll in the viewport while dragging
Status: NEW
[polish-hard] [polish-interactive][po...
: polish
Product: Core
Classification: Components
Component: Drag and Drop (show other bugs)
: Trunk
: All All
: P3 normal with 23 votes (vote)
: ---
Assigned To: Masayuki Nakano [:masayuki] (Mozilla Japan)
:
Mentors:
: 98226 228749 423268 563861 623177 660407 743167 (view as bug list)
Depends on:
Blocks: 277402
  Show dependency treegraph
 
Reported: 2000-06-06 13:56 PDT by Blake Ross
Modified: 2015-03-17 13:28 PDT (History)
27 users (show)
roc: blocking1.9.1-
roc: wanted1.9.1-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Workaround extension (2.27 KB, application/x-xpinstall)
2006-02-01 19:30 PST, nrlz
no flags Details
patch (2.89 KB, patch)
2008-05-14 13:25 PDT, Martijn Wargers [:mwargers] (not working for Mozilla)
no flags Details | Diff | Review
Workaround extension (updated for Firefox 3.0 to 3.7+ compatibility) (2.71 KB, application/x-xpinstall)
2010-02-07 14:06 PST, IU
no flags Details
Workaround extension (updated for Firefox 3.0 to 3.7+ compatibility) (2.63 KB, application/x-xpinstall)
2010-02-07 18:03 PST, IU
no flags Details

Description Blake Ross 2000-06-06 13:56:41 PDT
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) 2000-06-07 10:11:22 PDT
afaik, D&D issues should go to xp toolkit... (lemme know otherwise!)
Comment 2 John Morrison 2000-06-07 12:43:17 PDT
... as you can with IE on windows; IE5.5 on mac does not scroll when dragging a 
link. 
Comment 3 Peter Trudelle 2000-06-07 16:40:47 PDT
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 2000-11-24 20:11:07 PST
pink, ideas for doing this?
Comment 5 Matthew Paul Thomas 2000-11-24 21:35:20 PST
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) 2000-11-27 13:58:10 PST
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 Paul Thomas 2000-12-02 07:27:18 PST
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] 2004-07-28 16:11:43 PDT
->selection
Comment 9 Asa Dotzler [:asa] 2004-07-28 16:12:32 PDT
*** Bug 98226 has been marked as a duplicate of this bug. ***
Comment 10 Asa Dotzler [:asa] 2004-07-28 16:12:55 PDT
*** Bug 228749 has been marked as a duplicate of this bug. ***
Comment 11 nrlz 2006-02-01 19:30:10 PST
Created attachment 210437 [details]
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 [:mwargers] (not working for Mozilla) 2006-04-22 15:40:40 PDT
IE6 does this for any scrollable view.
Comment 13 RenegadeX 2007-10-15 23:01:38 PDT
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 2008-03-05 13:39:36 PST
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 [:mwargers] (not working for Mozilla) 2008-03-05 15:40:51 PST
(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 2008-03-06 14:44:17 PST
(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 [:mwargers] (not working for Mozilla) 2008-03-06 14:59:00 PST
Hmm, strange, you're right, I could have sworn it worked for me.
Comment 18 Martijn Wargers [:mwargers] (not working for Mozilla) 2008-05-14 13:14:31 PDT
*** Bug 423268 has been marked as a duplicate of this bug. ***
Comment 19 Martijn Wargers [:mwargers] (not working for Mozilla) 2008-05-14 13:25:29 PDT
Created attachment 320976 [details] [diff] [review]
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 [:mwargers] (not working for Mozilla) 2008-06-02 10:08:56 PDT
Comment on attachment 320976 [details] [diff] [review]
patch

I might as well let it review.
Comment 21 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2008-07-21 04:39:02 PDT
+  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 2008-07-22 13:27:45 PDT
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) 2008-08-24 14:56:21 PDT
Selection doesn't seem to be the right component here. What is a better one?
Comment 24 RenegadeX 2008-11-29 20:34:42 PST
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) 2008-12-03 23:11:58 PST
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 2008-12-20 02:12:37 PST
(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) 2008-12-31 16:59:17 PST
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) 2009-06-22 22:29:04 PDT
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) 2009-06-22 23:01:26 PDT
(switching to whiteboard for polish-relative priorities)
Comment 30 gaoninza2 2009-07-25 04:29:02 PDT
REALLY NEEDING TO FIX THIS BUG
Comment 31 Steve England [:stevee] 2009-07-25 04:32:20 PDT
gaoninza2 don't mess with the flags and don't post useless comments that add nothing to fixing the bug. thanks.
Comment 32 mjarecki 2009-08-04 17:59:30 PDT
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 2010-02-06 22:06:47 PST
Please, can we get this bug fixed.  It's a blooming pain. :-(
Comment 34 IU 2010-02-07 14:06:55 PST
Created attachment 425721 [details]
 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 2010-02-07 18:03:35 PST
Created attachment 425734 [details]
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 36 Tim (fmdeveloper) 2010-05-04 21:29:39 PDT
*** Bug 563861 has been marked as a duplicate of this bug. ***
Comment 37 RenegadeX 2011-03-11 01:31:18 PST
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 38 Mardeg 2011-06-19 03:33:46 PDT
*** Bug 660407 has been marked as a duplicate of this bug. ***
Comment 39 Masayuki Nakano [:masayuki] (Mozilla Japan) 2011-07-28 00:58:20 PDT
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 40 Masayuki Nakano [:masayuki] (Mozilla Japan) 2011-08-04 16:51:00 PDT
*** Bug 623177 has been marked as a duplicate of this bug. ***
Comment 41 Giorgio 2011-11-10 04:56:48 PST
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 42 Mardeg 2012-04-05 23:56:51 PDT
*** Bug 743167 has been marked as a duplicate of this bug. ***
Comment 43 Nicolas Barbulesco 2012-09-07 07:38:56 PDT
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 2015-03-17 13:28:50 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.