Bug 8137 - REGRESSION: scrolling on Google maps continues after the mouse is released outside the window
Summary: REGRESSION: scrolling on Google maps continues after the mouse is released ou...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 420+
Hardware: Mac OS X 10.4
: P1 Normal
Assignee: Geoffrey Garen
URL: http://maps.google.com
Keywords: GoogleBug, HasReduction, InRadar, Regression
Depends on:
Blocks:
 
Reported: 2006-04-02 07:23 PDT by Alexey Proskuryakov
Modified: 2006-12-19 12:44 PST (History)
7 users (show)

See Also:


Attachments
reduction (1.02 KB, text/html)
2006-12-18 15:03 PST, Geoffrey Garen
no flags Details
reduction (979 bytes, text/html)
2006-12-18 15:56 PST, Geoffrey Garen
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexey Proskuryakov 2006-04-02 07:23:20 PDT
The same problem as in bug 5923, but apparently with a different cause (as the layout test still passes).

Steps to reproduce:
1. Go to http://maps.google.com
2. Click the mouse anywhere on the map, drag until the mouse pointer goes
outside the Safari window
3. Release the mouse button
4. Move the mouse pointer back into the window

Results: the map scrolls, although the mouse button is not down
Expected results (as in Safari 2.0.3): it shouldn't
Comment 1 mitz 2006-04-02 10:48:31 PDT
This time around the problem seems to be that the final mouseup event is not delivered, because of the mouseDown check in RenderLayer::shouldApplyImplicitCapture(), which was introduced in r13601.
Comment 2 Darin Adler 2006-04-02 16:50:07 PDT
Maciej, your change log for r13601 says nothing about what you were trying to accomplish with that check-in, so I am not comfortable making a change. But it does seem clear that a mouse up event wants to participate in the capture even though the mouse is no longer down at the time it's generated.
Comment 3 Darin Adler 2006-04-02 16:50:44 PDT
We'll need a test case, so attaching the NeedsReduction keyword.
Comment 4 Alice Liu 2006-05-16 09:51:23 PDT
<rdar://problem/4549745>
Comment 5 Joost de Valk (AlthA) 2006-07-12 10:20:36 PDT
Adding GoogleBug keyword in one big change.
Comment 6 Alexey Proskuryakov 2006-12-02 12:20:24 PST
(In reply to comment #1)
> This time around the problem seems to be that the final mouseup event is not
> delivered, because of the mouseDown check in
> RenderLayer::shouldApplyImplicitCapture(), which was introduced in r13601.

This method no longer exists due to refactoring, but the problem remains. I couldn't quickly find where this logic was moved.
Comment 7 mitz 2006-12-02 14:34:28 PST
(In reply to comment #6)
> (In reply to comment #1)
> This method no longer exists due to refactoring, but the problem remains. I
> couldn't quickly find where this logic was moved.
> 

Now in RenderLayer::hitTestLayer(), the request.active condition:

    // We didn't hit any layer.  However if the mouse is down, we must always at least be inside
    // the render view.
    if (request.active && renderer()->isRenderView()) {
        renderer()->setInnerNode(result);
        return this;
    }

Comment 8 Geoffrey Garen 2006-12-18 09:39:10 PST
I'm working on this.
Comment 9 Geoffrey Garen 2006-12-18 15:03:47 PST
Created attachment 11906 [details]
reduction
Comment 10 Geoffrey Garen 2006-12-18 15:56:25 PST
Created attachment 11910 [details]
reduction

New reduction. Mitz pointed out that the old reduction tested for behavior that, though different in shipping Safari, was incorrect.
Comment 11 Geoffrey Garen 2006-12-19 00:19:10 PST
Committed revision 18304.
Comment 12 mitz 2006-12-19 12:44:27 PST
(In reply to comment #11)
> Committed revision 18304.
> 

The patch caused bug 11880.