Bug 5853 – REGRESSION (10.4.2): Editable webviews auto-scroll more easily than they used to during drag over content

• Status: NEW
• Component: WebKit Misc.

[John Sullivan]

This bug is also in Radar as <rdar://4267144>. I eliminated some of the back-and-forth from the 
following text when copying it into Bugzilla.

Safari 2.0.2 (416.8) - content scrolls during Finder drag to Trash

I maintain my Safari window at about 85% of full-screen size.  When dragging a file icon to the Trash, 
my drag vector inevitably crosses over the lower right corner of the webview, and now it immediately 
scrolls its contents down, seeming to track the drag/drop to a particular location in the content.  Why 
does a webview need to accept a drop in a non-form area, other than to open that URL in the frame?  It 
should not scroll the content when dragging.  Previous versions did not suffer from this problem.  It is 
very annoying.  When I have a Google search list of documents open in the content area, I download 
and view the files and systematically drag them from Desktop to Trash, but I lose my position in the 
search when the content is scrolled!!!  Very bad behavior.  Please fix it!  Thanks.

<GMT22-Sep-2005 21:17:12GMT> John Sullivan:
I don't know why this would have changed for Tiger, but I can imagine it did by accident.

This is not a Safari issue specifically, but a general WebKit issue. We should investigate why we 
autoscroll in WebViews (probably in WebHTMLView specifically) since it doesn't seem to be appropriate 
behavior for most dragged contents. Putting this in Leopard since it appears to be a regression. If it 
turns out not to be a regression then the priority is much lower.

I guess I'll hang onto this one myself, at least for now.

<GMT28-Sep-2005 22:33:02GMT> John Sullivan:
I've compared 10.4 8A426 with 10.4.3 8F32, and I do see a difference, though it's not exactly what this 
bug states. Safari pages auto-scroll during drag over content in 10.4 also (and, I believe, all earlier 
versions). However, the distance threshhold seems to have changed. In 10.4, it seems to start auto-
scrolling only when the cursor is within (about?) 8 pixels of the window edge. In 10.4.3 8F32, it seems 
to start auto-scrolling only when the cursor is within (about?) 24 pixels of the window edge. This larger 
distance makes it more likely that a file drag that just happens to cross the bottom of a Safari window 
will pause long enough in the hot area to initiate an auto-scroll.

I don't yet know when this behavior change occurred, just that it was sometime after 10.4 8A426. I also 
don't yet know what caused the behavior change. I'm investigating that now.

<GMT28-Sep-2005 23:17:03GMT> John Sullivan:
There are two separable issues here:

(1) Probably, Safari pages should not auto-scroll during drag over content at all. Before Tiger, they did 
not. Tiger introduced this behavior to fix 3689734, but that bug was specifically about dragging over 
an editable WebView. I don't think we intentionally changed this to change the behavior of dragging 
over a non-editable WebView.

(2) As I said above, the "hot area" that triggers autoscroll has increased sometime between 10.4 and 
10.4.3 8F32. We are inheriting the implementation of -_shouldAutoscrollForDraggingInfo: from 
NSClipView. This implementation is based on the value of verticalLineScroll of the superview (the 
NSScrollView).

I was suspicious that the fix for 4077106 changed the value of verticalLineScroll for the NSScrollViews 
in WebViews. This fix went into SUTiCambridge (10.4.2). But I can't find any evidence that the change to 
fix that bug actually affected this value; that does not seem to be the case.

The remaining possibilities are:
2A) the value for -[NSScrollView verticalLineScroll] has changed between 10.4 and 10.4.3 8F32
2B) the implementation of -[NSClipView _shouldAutoscrollForDraggingInfo:] has changed between 10.4. 
and 10.4.3 8F32
2C) some change in WebKit or Safari increased the value of verticalLineScroll

I don't think (2C) is the case, but I might be missing something.


<GMT28-Sep-2005 23:45:56GMT> John Sullivan:
I found the problem. It was in fact that fix for 4077106 that I was suspicious of. I didn't find it before 
because I was looking for "verticalLineScroll" but the relevant line is this one from -[WebFrameView 
initWithFrame:]:

    [scrollView setLineScroll:40.0];

We might want to fix this for a future Tiger update (probably by turning off autoscrolling entirely when 
dragging over a non-editable WebView; maybe we also want to reduce the autoscrolling  hit area 
distance for editable WebViews?). But since it's a relatively minor issue and it's not a regression in 
Denver and Denver is desperately trying to wrap up, this isn't worth trying to address for Denver.

[Joost de Valk (AlthA)]

Adding Regression keyword.

[Joost de Valk (AlthA)]

Upping to P1 because this is a regression.

[John Sullivan]

There were two issues here:
(1) dragging over a non-editable webview (such as a typical Safari page) should not have auto-scrolled at all; the fact that it did was an uninentional side effect of making auto-scroll work for editable webviews a la Blot.
(2) the speed & hot area of the auto-scroll changed between 10.4.1 and 10.4.2.

Issue (1) has now been addressed in WebKit via the radar bug. We can leave this bug open to represent issue #2 only, which was caused by the setLineScroll:40 change mentioned above.

I'm not sure this is really causing trouble for anyone, so I'm demoting this to p2 even though it is a change in behavior. Fixing it would require separating the sensitivity of mouse wheel scrolling from the sensitivity of auto-scrolling somehow.