<rdar://problem/49908848>
Created attachment 367635 [details] Fixes the bug
Comment on attachment 367635 [details] Fixes the bug View in context: https://bugs.webkit.org/attachment.cgi?id=367635&action=review > Source/WebKit/WebProcess/WebPage/WebPage.cpp:5295 > void WebPage::didChangeSelection() > +{ > + didChangeSelectionOrOverflowScrollPosition(EditorStateUpdateScheduling::Immediate); > +} Don't we run the risk that callers of this will trigger the same release assert?
(In reply to Simon Fraser (smfr) from comment #2) > Comment on attachment 367635 [details] > Fixes the bug > > View in context: > https://bugs.webkit.org/attachment.cgi?id=367635&action=review > > > Source/WebKit/WebProcess/WebPage/WebPage.cpp:5295 > > void WebPage::didChangeSelection() > > +{ > > + didChangeSelectionOrOverflowScrollPosition(EditorStateUpdateScheduling::Immediate); > > +} > > Don't we run the risk that callers of this will trigger the same release > assert? Yes, we do; I'm hoping to remove EditorStateUpdateScheduling::Immediate altogether and always only schedule editor state updates in the (very near) future. This would also schedule rendering updates instead of scheduling compositing flushes, as it does now.
Comment on attachment 367635 [details] Fixes the bug Clearing flags on attachment: 367635 Committed r244388: <https://trac.webkit.org/changeset/244388>
All reviewed patches have been landed. Closing bug.