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.
Adding Regression keyword.
Upping to P1 because this is a regression.
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.