RIM Bug:245678 Steps: 1) Launch browser and navigate to a site 2) Tap on the URL bar so that the text is highlighted. 3) Press and hold the URL bar. 4) Tap on the webcontent to dismiss selection and CCM Actual: 3) The VKB is dismissed and the CCM is displayed on the side. 4) You would see the VKB flicker in and out. Expected: 3) The VKB is dismissed and the CCM is displayed on the side. 4) The text selection on the URL bar is dismissed and the CCM disappears.
Created attachment 177225 [details] patch >It looks safe but that assumes the change event will re trigger, if not we risk having a stale selection >overlay if the layout change modifies it. There is a function "void FrameView::performPostLayoutTasks()" which will call FrameSelection::updateAppearance() on every time the FrameView layout is finished. So I think the selection changing will be notified at last. If we don't ensure it, another solution is to check and layoutIfNeeded at the beginning of "SelectionHandler::selectionPositionChanged()".
Comment on attachment 177225 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=177225&action=review LGTM, but please fix the ChangeLog before landing. > Source/WebKit/blackberry/ChangeLog:6 > + Reviewed by NOBODY (OOPS!). What PR and internal reviewer? > Source/WebKit/blackberry/ChangeLog:9 > + At the same time, the thread 5 is executing compositeLayers and it will dispatch thread 5 is a bit imprecise...
Created attachment 177637 [details] patch Fix change log.
Created attachment 177645 [details] patch Fix change log.
Comment on attachment 177645 [details] patch commit.
Comment on attachment 177645 [details] patch Clearing flags on attachment: 177645 Committed r136633: <http://trac.webkit.org/changeset/136633>
Landed in r136633, closing.