WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
8137
REGRESSION: scrolling on Google maps continues after the mouse is released outside the window
https://bugs.webkit.org/show_bug.cgi?id=8137
Summary
REGRESSION: scrolling on Google maps continues after the mouse is released ou...
Alexey Proskuryakov
Reported
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
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
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
mitz
Comment 1
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
.
Darin Adler
Comment 2
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.
Darin Adler
Comment 3
2006-04-02 16:50:44 PDT
We'll need a test case, so attaching the NeedsReduction keyword.
Alice Liu
Comment 4
2006-05-16 09:51:23 PDT
<
rdar://problem/4549745
>
Joost de Valk (AlthA)
Comment 5
2006-07-12 10:20:36 PDT
Adding GoogleBug keyword in one big change.
Alexey Proskuryakov
Comment 6
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.
mitz
Comment 7
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; }
Geoffrey Garen
Comment 8
2006-12-18 09:39:10 PST
I'm working on this.
Geoffrey Garen
Comment 9
2006-12-18 15:03:47 PST
Created
attachment 11906
[details]
reduction
Geoffrey Garen
Comment 10
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.
Geoffrey Garen
Comment 11
2006-12-19 00:19:10 PST
Committed revision 18304.
mitz
Comment 12
2006-12-19 12:44:27 PST
(In reply to
comment #11
)
> Committed revision 18304. >
The patch caused
bug 11880
.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug