722981 - nsMediaCacheFlusher uses the global Private Browsing status to decide when to flush the media cache

Status: RESOLVED FIXED

(Core :: Audio/Video, defect)

Description

[Josh Matthews [:jdm]]

The global PB service is going away. We'll probably need to have two separate media caches, since there could be a PB window watching a video and a regular window watching another concurrently.

Comment 1

[Josh Matthews [:jdm]]

We can at least clear out the private media cache based on the last-pb-context-destroyed notification in bug 725210.

Comment 2

[Josh Matthews [:jdm]]

Robert, what work will be required to allow multiple media caches? I scanned through nsMediaCache for places that use gMediaCache, and it didn't look like a completely straightforward process for someone brand new to the media code.

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

It's not trivial, but I think it's not hard.

-- Give each nsMediaCacheStream a reference to its nsMediaCache. Make nsMediaCacheStream::Init indicate which cache to use (could just be an enum). Then InitMediaCache would take that enum as a parameter and index into a global array. Or some value of the enum could create a new unique nsMediaCache and add it to the array.
-- Make MaybeShutdown nonstatic.
-- Make nsMediaCacheFlusher iterate through the global array. (Would it still be needed though?)
-- Give each ResourceStreamIterator a reference to its nsMediaCache.
-- Give each UpdateEvent a reference to its nsMediaCache.

Comment 4

[(no longer active)]

OK, so we had talked about this over in bug 572243.  To summarize, the media cache does not include the URL to the media resource.  The data itself might potentially be used to trace the media item back to its source, but the current approach of clearing the cache when the PB mode is over seems to be sufficient in order to defend against that.

The advantage of separating the media cache into two caches is that when leaving the PB mode, the media cache for non-PB media will not get evicted.  I think that's definitely something to strive to do, but it's out of scope for this bug.  As far as this bug is concerned, we should just preserve the existing functionality.

Comment 5

[(no longer active)]

Attachment: Patch (v1)

Comment 6

[(no longer active)]

https://hg.mozilla.org/projects/birch/rev/0e1a36682e9e

Comment 7

[(no longer active)]

https://hg.mozilla.org/mozilla-central/rev/0e1a36682e9e