Summary: | REGRESSION (r88580): Cursor fails to change to pointer on embedded Google maps popups | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Rick Baumhauer <rick.baumhauer> | ||||||||||||||
Component: | Layout and Rendering | Assignee: | Simon Fraser (smfr) <simon.fraser> | ||||||||||||||
Status: | RESOLVED FIXED | ||||||||||||||||
Severity: | Normal | CC: | ap, dglazkov, enne, joel, mitz, simon.fraser, webkit-bug-importer, webkit.review.bot | ||||||||||||||
Priority: | P1 | Keywords: | InRadar, Regression | ||||||||||||||
Version: | 528+ (Nightly build) | ||||||||||||||||
Hardware: | Mac | ||||||||||||||||
OS: | OS X 10.6 | ||||||||||||||||
Attachments: |
|
Description
Rick Baumhauer
2011-06-16 07:26:49 PDT
Bisection says it's <http://trac.webkit.org/changeset/88580>. That's odd; that shouldn't affect any hit testing issues, and therefore any cursor issues. Maybe the description of the bug is confusing? Rick: please provide a full url of a page that shows this, and, if possible, a screenshot showing the issues. Created attachment 97462 [details]
Webkit Batchgeo.com mouse pointer issue.
Had to fake this, as normal screen grabs won't grab the mouse pointer, but this is what I'm seeing in Webkit.
Created attachment 97464 [details]
Correct Batchgeo.com mouse pointer in Safari 5.0.5
Again, faked the mouse pointer, but this is how it should behave, and is behaving in Safari 5.0.5.
Complete URL is http://batchgeo.com/map/44134cd4f0d9ac22be70b25de1473c68 Simon, I can show you how to reproduce this. If you disable accelerated compositing, the bug goes away. Odd. *** Bug 66174 has been marked as a duplicate of this bug. *** May be the same as bug 65398. Created attachment 106164 [details]
Reduction
The problem is this code in RenderLayer::hitTestLayer: #if USE(ACCELERATED_COMPOSITING) if (isComposited()) { // It doesn't make sense to project hitTestRect into the plane of this layer, so use the same bounds we use for painting. localHitTestRect = backing()->compositedBounds(); } else #endif In the test case, the 'container' layer has zero size. Created attachment 106170 [details]
Clearer reduction
That code was added for http://trac.webkit.org/changeset/41952 The underlying issue is that TransformationMatrix::projectQuad() returns garbage if, inside projectPoint, w is negative. That means that the quad projects behind the w=0 plane. So if w is negative we need to return "large" values for x and y from projectPoint(), while ensuring that the IntRect we finally construct from those values is not degenerate. Something like: diff --git a/Source/WebCore/platform/graphics/transforms/TransformationMatrix.cpp b/Source/WebCore/platform/graphics/transforms/TransformationMatrix.cpp index 6366342..51174cd 100644 --- a/Source/WebCore/platform/graphics/transforms/TransformationMatrix.cpp +++ b/Source/WebCore/platform/graphics/transforms/TransformationMatrix.cpp @@ -551,11 +551,15 @@ FloatPoint TransformationMatrix::projectPoint(const FloatPoint& p) const double y = p.y(); double z = -(m13() * x + m23() * y + m43()) / m33(); + // FIXME: use multVecMatrix() double outX = x * m11() + y * m21() + z * m31() + m41(); double outY = x * m12() + y * m22() + z * m32() + m42(); double w = x * m14() + y * m24() + z * m34() + m44(); - if (w != 1 && w != 0) { + if (w < 0) { + outX = copysign(INT_MAX / 2, outX); + outY = copysign(INT_MAX / 2, outY); + } else if (w != 1 && w != 0) { outX /= w; outY /= w; } We could return inf but we'd have to futz with enclosingIntRect() later to turn a rect with inf position or dimensions into a non-empty rect. Created attachment 112262 [details]
Patch
Attachment 112262 [details] did not pass style-queue:
Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'LayoutTests/ChangeLog', u'LayoutTests/plat..." exit_code: 1
Source/WebCore/platform/graphics/transforms/TransformationMatrix.cpp:564: Tests for true/false, null/non-null, and zero/non-zero should all be done without equality comparisons. [readability/comparison_to_zero] [5]
Total errors found: 1 in 16 files
If any of these errors are false positives, please file a bug against check-webkit-style.
Comment on attachment 112262 [details] Patch Attachment 112262 [details] did not pass efl-ews (efl): Output: http://queues.webkit.org/results/10209014 Comment on attachment 112262 [details] Patch Attachment 112262 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/10203919 Comment on attachment 112262 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=112262&action=review As discussed, because of the clamping behavior of projectPoint and boundsOfProjectedQuad, they should be renamed to something like projectAndClampPoint and clampedBoundsOfProjectedQuad. >> Source/WebCore/platform/graphics/transforms/TransformationMatrix.cpp:564 >> + } else if (w != 1 && w != 0) { > > Tests for true/false, null/non-null, and zero/non-zero should all be done without equality comparisons. [readability/comparison_to_zero] [5] Maybe the right thing to do when w == 0 is the same as w < 0? So if (w <= 0) would be better. > Source/WebCore/platform/graphics/transforms/TransformationMatrix.cpp:579 > + Is this newline needed? Created attachment 112275 [details]
Patch
*** Bug 65398 has been marked as a duplicate of this bug. *** |