Title: [137977] trunk/Source/WebKit/blackberry
- Revision
- 137977
- Author
- [email protected]
- Date
- 2012-12-17 20:19:25 -0800 (Mon, 17 Dec 2012)
Log Message
[BlackBerry] Prevent selection handles from being rendered after selection was canceled
https://bugs.webkit.org/show_bug.cgi?id=105203
Patch by Yongxin Dai <[email protected]> on 2012-12-17
Reviewed by Rob Buis.
PR255438
Here is the explanation why handles occur without selection overlay.
1. Still touch at current selection (Selection A) initiated by touch-hold
2. Selection expanding (Selection B) is ongoing
3. Finger moves. In UI thread:
1) SelectionHander::cancelSelection() gets called.
a. Selection A is canceled immediately (clear selecting state and hide handles)
b. Post a request to webkit thread to cancel Selection A.
4. In webkit thread:
1) Selection B becomes active selection
a. Show selection overlay for Selection B
b. Dispatch Selection B to UI thread to show handles
2) Handle the request of canceling Selection A. The selection A was gone. Instead the active Selection B is canceled.
The visual change is Selection overlay for Selection B becomes invisible..
5. In UI thread:
Selection B is rendered. The start handle and the end handle occur without selection overlay.
The fix is to notify client with a empty selection whenever the selection is canceled in webkit thread.
Reviewed Internally by Mike Fenton.
* WebKitSupport/SelectionHandler.cpp:
(BlackBerry::WebKit::SelectionHandler::cancelSelection):
Modified Paths
Diff
Modified: trunk/Source/WebKit/blackberry/ChangeLog (137976 => 137977)
--- trunk/Source/WebKit/blackberry/ChangeLog 2012-12-18 03:51:07 UTC (rev 137976)
+++ trunk/Source/WebKit/blackberry/ChangeLog 2012-12-18 04:19:25 UTC (rev 137977)
@@ -1,3 +1,35 @@
+2012-12-17 Yongxin Dai <[email protected]>
+
+ [BlackBerry] Prevent selection handles from being rendered after selection was canceled
+ https://bugs.webkit.org/show_bug.cgi?id=105203
+
+ Reviewed by Rob Buis.
+
+ PR255438
+
+ Here is the explanation why handles occur without selection overlay.
+ 1. Still touch at current selection (Selection A) initiated by touch-hold
+ 2. Selection expanding (Selection B) is ongoing
+ 3. Finger moves. In UI thread:
+ 1) SelectionHander::cancelSelection() gets called.
+ a. Selection A is canceled immediately (clear selecting state and hide handles)
+ b. Post a request to webkit thread to cancel Selection A.
+ 4. In webkit thread:
+ 1) Selection B becomes active selection
+ a. Show selection overlay for Selection B
+ b. Dispatch Selection B to UI thread to show handles
+ 2) Handle the request of canceling Selection A. The selection A was gone. Instead the active Selection B is canceled.
+ The visual change is Selection overlay for Selection B becomes invisible..
+ 5. In UI thread:
+ Selection B is rendered. The start handle and the end handle occur without selection overlay.
+
+ The fix is to notify client with a empty selection whenever the selection is canceled in webkit thread.
+
+ Reviewed Internally by Mike Fenton.
+
+ * WebKitSupport/SelectionHandler.cpp:
+ (BlackBerry::WebKit::SelectionHandler::cancelSelection):
+
2012-12-17 Yong Li <[email protected]>
[BlackBerry] Null pointer access in compositorDrawsRootLayer
Modified: trunk/Source/WebKit/blackberry/WebKitSupport/SelectionHandler.cpp (137976 => 137977)
--- trunk/Source/WebKit/blackberry/WebKitSupport/SelectionHandler.cpp 2012-12-18 03:51:07 UTC (rev 137976)
+++ trunk/Source/WebKit/blackberry/WebKitSupport/SelectionHandler.cpp 2012-12-18 04:19:25 UTC (rev 137977)
@@ -85,6 +85,10 @@
if (m_webPage->m_selectionOverlay)
m_webPage->m_selectionOverlay->hide();
+ // Notify client with empty selection to ensure the handles are removed if
+ // rendering happened prior to processing on webkit thread
+ m_webPage->m_client->notifySelectionDetailsChanged(WebCore::IntRect(DOMSupport::InvalidPoint, WebCore::IntSize()),
+ WebCore::IntRect(DOMSupport::InvalidPoint, WebCore::IntSize()), IntRectRegion());
SelectionLog(Platform::LogLevelInfo, "SelectionHandler::cancelSelection");
_______________________________________________
webkit-changes mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-changes
