r224179 introduced a performance regression, originally reported at https://bugs.webkit.org/show_bug.cgi?id=168219#c55. This code in WebPage::editorState: postLayoutData.canCut = editor.canCut(); postLayoutData.canCopy = editor.canCopy(); postLayoutData.canPaste = editor.canPaste(); postLayoutData.canUndo = editor.canUndo(); postLayoutData.canRedo = editor.canRedo(); is part of a performance-critical path. (The editor state is computed and sent to the UI process during the layer flush.) But Editor::canUndo and Editor::canRedo are both implemented with sync IPC calls to WebPageProxy in the UI process. WebPageProxy passes them along to PageClientImpl to compute the availability of the commands. As Simon noted in bug #168219, that's all pointless because this code only exists for the purpose of getting editing command availability to the UI process. In the case of undo and redo, it's not needed at all. I did not realize that when writing the code. So canUndo and canRedo should be removed from EditorState. I don't think any changes are needed to the GTK/WPE WebKitEditorState API. The API can be implemented using WebPageProxy::canUndoRedo instead of EditorState. I think that should be sufficient to avoid the perf regression.
Created attachment 327112 [details] Patch
This needs owner approval because I added two new methods to WebPageProxy, canUndo and canRedo. That seems better than making canUndoRedo public, since that interface is a bit messy and really intended for message receipt from the web process.
Comment on attachment 327112 [details] Patch Clearing flags on attachment: 327112 Committed r224945: <https://trac.webkit.org/changeset/224945>
All reviewed patches have been landed. Closing bug.