Right now, Frame::rectForSelection instantiates a FrameSelection in order to compute the absolute caret bounds of start and end points. We're trying to contain the side-effects of FrameSelection::setSelection with suppressSelectionNotifications and restoreSelectionNotifications on WebEditorClient, as well as suppressCloseTyping and restoreCloseTyping on FrameSelection but selectionchange event still fires and it could change the focus, Because it uses FrameSelection::setSelection on both start and end points, it erroneously fires selectionchange events and closes the open typing command.
Created attachment 223827 [details] Cleanup
Comment on attachment 223827 [details] Cleanup Attachment 223827 [details] did not pass mac-ews (mac): Output: http://webkit-queues.appspot.com/results/5678939372519424 New failing tests: animations/stop-animation-on-suspend.html
Created attachment 223841 [details] Archive of layout-test-results from webkit-ews-07 for mac-mountainlion The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: webkit-ews-07 Port: mac-mountainlion Platform: Mac OS X 10.8.5
> animations/stop-animation-on-suspend.html Now, that's a lie.
Comment on attachment 223827 [details] Cleanup View in context: https://bugs.webkit.org/attachment.cgi?id=223827&action=review > Source/WebCore/editing/htmlediting.cpp:1278 > + // if caretNode is a block and caret is inside it then caret should be painted by that block Comment style.
Comment on attachment 223827 [details] Cleanup (In reply to comment #5) > (From update of attachment 223827 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=223827&action=review > > > Source/WebCore/editing/htmlediting.cpp:1278 > > + // if caretNode is a block and caret is inside it then caret should be painted by that block > > Comment style. WIll fix.
Committed r163920: <http://trac.webkit.org/changeset/163920>