REGRESSION (r243926): [iOS] Release assertion when computing editor state during an overflow scroll triggered by layout

[Wenson Hsieh]

<rdar://problem/49908848>

[Wenson Hsieh]

Created attachment 367635 [details]
Fixes the bug

[Simon Fraser (smfr)]

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?

[Wenson Hsieh]

(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.

[WebKit Commit Bot]

Comment on attachment 367635 [details]
Fixes the bug

Clearing flags on attachment: 367635

Committed r244388: <https://trac.webkit.org/changeset/244388>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.