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: RESOLVED FIXED
[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)
: mozilla53
Assigned To: Neil Deakin
:
: Neil Deakin
Mentors:
: 98226 228749 423268 563861 623177 660407 743167 1340566 (view as bug list)
Depends on:
Blocks: 277402
  Show dependency treegraph
 
Reported: 2000-06-06 13:56 PDT by Blake Ross
Modified: 2017-02-17 10:41 PST (History)
30 users (show)
roc: blocking1.9.1-
roc: wanted1.9.1-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
fixed


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]
no flags Details | Diff | Splinter 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
Scroll scrollframes when dragging over the edge of them (5.40 KB, patch)
2016-11-18 08:34 PST, Neil Deakin
no flags Details | Diff | Splinter Review
Scroll scrollframes when dragging over the edge of them (5.38 KB, patch)
2016-12-07 13:00 PST, Neil Deakin
bugs: review-
Details | Diff | Splinter Review
Scroll scrollframes when dragging over the edge of them, v2 (6.40 KB, patch)
2016-12-19 11:21 PST, Neil Deakin
bugs: review+
Details | Diff | Splinter Review

Description User image 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 User image 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 User image 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 User image 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 User image Blake Ross 2000-11-24 20:11:07 PST
pink, ideas for doing this?
Comment 5 User image 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 User image 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 User image 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 User image Asa Dotzler [:asa] 2004-07-28 16:11:43 PDT
->selection
Comment 9 User image Asa Dotzler [:asa] 2004-07-28 16:12:32 PDT
*** Bug 98226 has been marked as a duplicate of this bug. ***
Comment 10 User image Asa Dotzler [:asa] 2004-07-28 16:12:55 PDT
*** Bug 228749 has been marked as a duplicate of this bug. ***
Comment 11 User image 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 User image Martijn Wargers [:mwargers] 2006-04-22 15:40:40 PDT
IE6 does this for any scrollable view.
Comment 13 User image 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 User image 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 User image Martijn Wargers [:mwargers] 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 User image 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 User image Martijn Wargers [:mwargers] 2008-03-06 14:59:00 PST
Hmm, strange, you're right, I could have sworn it worked for me.
Comment 18 User image Martijn Wargers [:mwargers] 2008-05-14 13:14:31 PDT
*** Bug 423268 has been marked as a duplicate of this bug. ***
Comment 19 User image Martijn Wargers [:mwargers] 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 User image Martijn Wargers [:mwargers] 2008-06-02 10:08:56 PDT
Comment on attachment 320976 [details] [diff] [review]
patch

I might as well let it review.
Comment 21 User image Robert O'Callahan (:roc) (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 User image 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 User image 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 User image 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 User image 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 User image 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 User image 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 User image 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 User image Alex Faaborg [:faaborg] (Firefox UX) 2009-06-22 23:01:26 PDT
(switching to whiteboard for polish-relative priorities)
Comment 30 User image gaoninza2 2009-07-25 04:29:02 PDT
REALLY NEEDING TO FIX THIS BUG
Comment 31 User image 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 User image 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 User image IU 2010-02-06 22:06:47 PST
Please, can we get this bug fixed.  It's a blooming pain. :-(
Comment 34 User image 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 User image 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 User image Tim (fmdeveloper) 2010-05-04 21:29:39 PDT
*** Bug 563861 has been marked as a duplicate of this bug. ***
Comment 37 User image 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 User image Mardeg 2011-06-19 03:33:46 PDT
*** Bug 660407 has been marked as a duplicate of this bug. ***
Comment 39 User image Masayuki Nakano [:masayuki] 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 User image Masayuki Nakano [:masayuki] 2011-08-04 16:51:00 PDT
*** Bug 623177 has been marked as a duplicate of this bug. ***
Comment 41 User image 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 User image Mardeg 2012-04-05 23:56:51 PDT
*** Bug 743167 has been marked as a duplicate of this bug. ***
Comment 43 User image 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 User image 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.
Comment 45 User image guerin45 2016-10-10 02:06:49 PDT
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 User image Neil Deakin 2016-11-18 08:34:21 PST
Created attachment 8812223 [details] [diff] [review]
Scroll scrollframes when dragging over the edge of them

This patch handles any scrollable area.
Comment 47 User image Neil Deakin 2016-12-07 13:00:45 PST
Created attachment 8817228 [details] [diff] [review]
Scroll scrollframes when dragging over the edge of them
Comment 48 User image Mats Palmgren (:mats) 2016-12-07 13:27:24 PST
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 User image Neil Deakin 2016-12-07 13:36:09 PST
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 User image Mats Palmgren (:mats) 2016-12-07 13:57:30 PST
Comment on attachment 8817228 [details] [diff] [review]
Scroll scrollframes when dragging over the edge of them

OK, good.
Comment 51 User image Masayuki Nakano [:masayuki] 2016-12-07 23:32:45 PST
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 User image Olli Pettay [:smaug] 2016-12-08 00:31:27 PST
Comment on attachment 8817228 [details] [diff] [review]
Scroll scrollframes when dragging over the edge of them

># HG changeset patch
># User Neil Deakin <neil@mozilla.com>
># 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 User image Neil Deakin 2016-12-08 08:31:45 PST
(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 <neil@mozilla.com>
> ># 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 User image Olli Pettay [:smaug] 2016-12-10 18:13:20 PST
(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 User image Neil Deakin 2016-12-19 11:21:34 PST
Created attachment 8820002 [details] [diff] [review]
Scroll scrollframes when dragging over the edge of them, v2
Comment 56 User image Olli Pettay [:smaug] 2016-12-19 11:53:49 PST
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 User image Neil Deakin 2016-12-20 10:40:03 PST
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 User image Phil Ringnalda (:philor) 2016-12-20 20:18:22 PST
https://hg.mozilla.org/mozilla-central/rev/b352c7f6bc15
Comment 59 User image Neil Deakin 2017-02-17 10:41:04 PST
*** Bug 1340566 has been marked as a duplicate of this bug. ***

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