The restoreIndex was an opportunity of optimization. If all no drawing between the Save and Restore happens, this means these items are all void and can be deleted from the DisplayList. With the canvas drawing and with batching the DisplayList flushing, this causes a serious problem when we try to remove the items at and after currentState().saveItemIndex.
Created attachment 392607 [details]
Comment on attachment 392607 [details]
View in context: https://bugs.webkit.org/attachment.cgi?id=392607&action=review
Please file a bug to track adding this optimization back.
> + DisplayList::Save item should not track the index of the corresponding Restore item
This title should be "remove the optimization for..."
Created attachment 392614 [details]
The commit-queue encountered the following flaky tests while processing attachment 392614 [details]:
editing/spelling/spellcheck-paste-continuous-disabled.html bug 208016 (authors: email@example.com and firstname.lastname@example.org)
The commit-queue is continuing to process your patch.
Comment on attachment 392614 [details]
Clearing flags on attachment: 392614
Committed r257945: <https://trac.webkit.org/changeset/257945>
All reviewed patches have been landed. Closing bug.
Reverted r257945 for reason:
This causes tests to fail
Committed r257947: <https://trac.webkit.org/changeset/257947>
(In reply to Simon Fraser (smfr) from comment #9)
Yes because DisplayList::Restore has no parameters now and operator<<(TextStream& ts, const Item&) should not call operator<<(TextStream& ts, const Save&) because this is going to call itself and we end up in infinite recursion.
Created attachment 392635 [details]
Comment on attachment 392635 [details]
Clearing flags on attachment: 392635
Committed r257958: <https://trac.webkit.org/changeset/257958>