Re: FW: [w3c/media-source] Restore auto-revoking behavior of createObjectURL(MediaSource) to revert breaking change introducing memory leaks (#156)

I've replied on the issue
<https://github.com/w3c/media-source/issues/156#issuecomment-244512364>,
and encourage my co-editors to assist in triage.

Thanks,
Matt

On Thu, Sep 1, 2016 at 6:06 PM, Paul Cotton <Paul.Cotton@microsoft.com>
wrote:

> How are the Editors planning to handle this request?
>
>
>
> *From:* Karl Tomlinson [mailto:notifications@github.com]
> *Sent:* Wednesday, August 31, 2016 7:42 PM
> *To:* w3c/media-source <media-source@noreply.github.com>
> *Subject:* [w3c/media-source] Restore auto-revoking behavior of
> createObjectURL(MediaSource) to revert breaking change introducing memory
> leaks (#156)
>
>
>
> #10 (comment)
> <https://github.com/w3c/media-source/issues/10#issuecomment-151735372>
> pointed out that removing the auto-revoking behavior would be a breaking
> change.
>
> #10 (comment)
> <https://github.com/w3c/media-source/issues/10#issuecomment-189219426>
> used two arguments to say this would not be a breaking change:
>
> 1.     That clients already needed to revoke explicitly anyway, due to a
> bug in
> the File API spec.
>
> 2.     That three existing UAs did not implement the auto-revoking
> behavior.
>
> Firefox does auto-revoke, and so 2 was incorrect. This is tested in
> w3c/web-platform-tests@7ca2c25
> <https://github.com/w3c/web-platform-tests/commit/7ca2c25204985477514ddb4e9171e7544d98a8e5>
>
> I am also not convinced by 1. Whether the precise time of revocation was
> clear or not, it was clear that the intention was that the client need not
> revoke.
>
> MSE does not need object URLs of infinite lifetime because these merely
> provide a mechanism of associating the MediaSource with a media element.
>
> As referenced in
> #10 (comment)
> <https://github.com/w3c/media-source/issues/10#issuecomment-201024017>
> removing the auto revocation leads to memory leaks.
> These leaks extend to objects affecting and affected by the MediaSource
> object.
>
> The second sentence of
> #10 (comment)
> <https://github.com/w3c/media-source/issues/10#issuecomment-208923486>
> is also incorrect because Firefox, at least, revokes the object URL on the
> next stable state, and so there is nothing to keep the objects alive.
>
> I don't know the reasons for requiring explicit revocation of File URLs,
> but I
> doubt they apply to MSE.
>
> Keeping track of strings for object URLs created, or immediately explicitly
> revoking, is an unnecessary burden for clients, one that is unexpected in a
> garbage collected world. This outweighs benefits of a breaking change to
> be consistent with the File API.
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/w3c/media-source/issues/156>, or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AH6r-EM9a19OS2c2dHbouApAOCNLVYTkks5qlhEygaJpZM4JyLPS>
> .
>