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().
Created attachment 374002 [details]
Comment on attachment 374002 [details]
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]
Comment on attachment 374205 [details]
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]
Comment on attachment 374785 [details]
Clearing flags on attachment: 374785
Committed r247783: <https://trac.webkit.org/changeset/247783>
All reviewed patches have been landed. Closing bug.