Bug 141049 – Call WebPage::didChangeSelection() asynchronously

• Status: RESOLVED
• Resolution: INVALID
• Component: Forms

[Chris Dumez]

Call WebPage::didChangeSelection() asynchronously to avoid sending a lot of IPC within a single event loop iteration and retrieving the editorState() each time (which is expensive).

[Chris Dumez]

Created attachment 245648 [details]
WIP patch

[Build Bot]

Comment on attachment 245648 [details]
WIP patch

Attachment 245648 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.appspot.com/results/5022045893033984

New failing tests:
platform/mac/editing/input/selection-change-closes-typing.html
platform/mac/editing/input/selection-change-closes-typing-2.html
editing/secure-input/removed-password-input.html
editing/secure-input/reset-state-on-navigation.html
editing/secure-input/password-input-focusing.html
editing/secure-input/password-input-changed-type.html

[Build Bot]

Created attachment 245660 [details]
Archive of layout-test-results from ews106 for mac-mavericks-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews106  Port: mac-mavericks-wk2  Platform: Mac OS X 10.9.5

[Alexey Proskuryakov]

A change like thug would be very hard to make. Probably impossible on Mavericks with its synchronous NSTextInputClient. 

We have very little test coverage for interactive text input.

[Chris Dumez]

(In reply to comment #4)
> A change like thug would be very hard to make. Probably impossible on
> Mavericks with its synchronous NSTextInputClient. 
> 
> We have very little test coverage for interactive text input.

Agreed. This was just a test to get results from EWS. I will indeed have to go in another direction.