Title: [126588] trunk/Source/WebKit/blackberry
- Revision
- 126588
- Author
- [email protected]
- Date
- 2012-08-24 08:30:39 -0700 (Fri, 24 Aug 2012)
Log Message
[BlackBerry] Touch cancel can cause huge and needless invalidations
https://bugs.webkit.org/show_bug.cgi?id=94938
PR #198051
Reviewed by George Staikos.
Patch by Antonio Gomes <[email protected]>
Internally reviewed by Gen Mak.
In order to remove the possible hover effect on touch_cancel, we always
invalidate the node under the fat finger, being the fat finger valid or not.
Point is: having a valid fat finger node does not mean the original touch
position was actually adjust for clicking or that the fat finger is actually
valid. We set the fat finger node to be the result of the point-based hit-test
regardless if it is a click target or not (in order to make our mouse-move
machinery to work).
We should can less aggressively invalidate the fat finger node, since it can
be rather an expensive call (longer than 1s in the worst scenario).
* WebKitSupport/TouchEventHandler.cpp:
(BlackBerry::WebKit::TouchEventHandler::touchEventCancel):
Modified Paths
Diff
Modified: trunk/Source/WebKit/blackberry/ChangeLog (126587 => 126588)
--- trunk/Source/WebKit/blackberry/ChangeLog 2012-08-24 15:12:53 UTC (rev 126587)
+++ trunk/Source/WebKit/blackberry/ChangeLog 2012-08-24 15:30:39 UTC (rev 126588)
@@ -1,3 +1,27 @@
+2012-08-24 Antonio Gomes <[email protected]>
+
+ [BlackBerry] Touch cancel can cause huge and needless invalidations
+ https://bugs.webkit.org/show_bug.cgi?id=94938
+ PR #198051
+
+ Reviewed by George Staikos.
+ Internally reviewed by Gen Mak.
+
+ In order to remove the possible hover effect on touch_cancel, we always
+ invalidate the node under the fat finger, being the fat finger valid or not.
+
+ Point is: having a valid fat finger node does not mean the original touch
+ position was actually adjust for clicking or that the fat finger is actually
+ valid. We set the fat finger node to be the result of the point-based hit-test
+ regardless if it is a click target or not (in order to make our mouse-move
+ machinery to work).
+
+ We should can less aggressively invalidate the fat finger node, since it can
+ be rather an expensive call (longer than 1s in the worst scenario).
+
+ * WebKitSupport/TouchEventHandler.cpp:
+ (BlackBerry::WebKit::TouchEventHandler::touchEventCancel):
+
2012-08-24 Arvid Nilsson <[email protected]>
[BlackBerry] Add WebPage API to reset block zoom
Modified: trunk/Source/WebKit/blackberry/WebKitSupport/TouchEventHandler.cpp (126587 => 126588)
--- trunk/Source/WebKit/blackberry/WebKitSupport/TouchEventHandler.cpp 2012-08-24 15:12:53 UTC (rev 126587)
+++ trunk/Source/WebKit/blackberry/WebKitSupport/TouchEventHandler.cpp 2012-08-24 15:30:39 UTC (rev 126588)
@@ -135,9 +135,14 @@
// If we cancel a single touch event, we need to also clean up any hover
// state we get into by synthetically moving the mouse to the m_fingerPoint.
- Element* elementUnderFatFinger = m_lastFatFingersResult.nodeAsElementIfApplicable();
- if (elementUnderFatFinger && elementUnderFatFinger->renderer()) {
+ Element* elementUnderFatFinger = m_lastFatFingersResult.positionWasAdjusted() ? m_lastFatFingersResult.nodeAsElementIfApplicable() : 0;
+ do {
+ if (!elementUnderFatFinger || !elementUnderFatFinger->renderer())
+ break;
+ if (!elementUnderFatFinger->renderer()->style()->affectedByHoverRules())
+ break;
+
HitTestRequest request(HitTestRequest::FingerUp);
// The HitTestResult point is not actually needed.
HitTestResult result(IntPoint::zero());
@@ -147,11 +152,14 @@
ASSERT(document);
document->renderView()->layer()->updateHoverActiveState(request, result);
document->updateStyleIfNeeded();
+
// Updating the document style may destroy the renderer.
- if (elementUnderFatFinger->renderer())
- elementUnderFatFinger->renderer()->repaint();
+ if (!elementUnderFatFinger->renderer())
+ break;
+
+ elementUnderFatFinger->renderer()->repaint();
ASSERT(!elementUnderFatFinger->hovered());
- }
+ } while (0);
m_lastFatFingersResult.reset();
}
_______________________________________________
webkit-changes mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-changes
