Before this patch, SourceBuffer::removeCodedFrames() did not trigger an immediate reenqueue, but rather just set the `needsReenqueuing` flag, deferring it for the next append... but there may not be another append! In that case, the removed frames would still wrongly play. This is the case for instance in tests where a single long media append is done and then "cropped" with SourceBuffer.erase(). Test: media/media-source/media-source-erase-after-last-append.html
Created attachment 374002 [details] Patch
Comment on attachment 374002 [details] Patch I see it ok, so r+. Then we have Apple EWS going very red on this, so maybe you check why and wait for Jer and Eric so say something as well.
It's failing because it's missing the AtomicString -> AtomString rename, I'll re-upload with that fixed as soon as I clean up my git finishing changes in the WebKitMediaSrc patch.
Created attachment 374205 [details] Patch
Comment on attachment 374205 [details] Patch Rejecting attachment 374205 [details] from commit-queue. Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.webkit.org', '--bot-id=webkit-cq-03', 'validate-changelog', '--check-oops', '--non-interactive', 374205, '--port=mac']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit ChangeLog entry in LayoutTests/ChangeLog contains OOPS!. Full output: https://webkit-queues.webkit.org/results/12801817
Created attachment 374785 [details] Patch
Comment on attachment 374785 [details] Patch Clearing flags on attachment: 374785 Committed r247783: <https://trac.webkit.org/changeset/247783>
All reviewed patches have been landed. Closing bug.
<rdar://problem/53504713>