Currently when Web Audio is playing and you navigate away (by either going to a new URL or going back), the audio just keeps on playing, which is not great. I think at the very least we need to stop audio playback when you navigate away. Other than that, we need to figure out what we should do when you navigate back to a page which had Web Audio playback and is now in the bfcache. Should we prevent those pages from getting into the bfcache in the first place? It's not clear to me how we would "resume" the playback once the page comes out of the bfcache (or if we even should do that.) Thoughts/ideas welcome.

What do we do with HTML5 <audio>/<video> ? It'd be good if we could duplicate the behavior there. Or maybe we can't because of the nature of the content?

The media element registers itself as a freezable element: http://mxr.mozilla.org/mozilla-central/source/content/html/content/src/nsHTMLMediaElement.cpp#1767 ...and when the document is "frozen" (put into bfcache) we're notified: http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsDocument.cpp#3970 ... and nsHTMLMediaElement::NotifyOwnerDocumentActivityChanged() calls through to the MediaDecoder to tell it to suspend/resume playback. You could tie into the same mechanism somehow.

(In reply to comment #2) > The media element registers itself as a freezable element: > http://mxr.mozilla.org/mozilla-central/source/content/html/content/src/nsHTMLMediaElement.cpp#1767 > > ...and when the document is "frozen" (put into bfcache) we're notified: > http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsDocument.cpp#3970 > > ... and nsHTMLMediaElement::NotifyOwnerDocumentActivityChanged() calls through > to the MediaDecoder to tell it to suspend/resume playback. > > You could tie into the same mechanism somehow. So, when you come out of freeze mode, we can resume the playback exactly where we were frozen before, etc.? Does that mean that the media objects involved will stay alive somehwere? Or a new set of decoder etc. objects are created?

The decoders are kept alive while they're frozen. When a media element is "thawed", nsHTMLMediaElement::NotifyOwnerDocumentActivityChanged() is called again and NotifyOwnerDocumentActivityChanged() distinguishes between the freeze/thaw cases and resumes playback of its decoder. Thus the same decoder is thawed and playback resumes where it left off in a consistent state. Make sense?

(In reply to comment #4) > The decoders are kept alive while they're frozen. When a media element is > "thawed", nsHTMLMediaElement::NotifyOwnerDocumentActivityChanged() is called > again and NotifyOwnerDocumentActivityChanged() distinguishes between the > freeze/thaw cases and resumes playback of its decoder. Thus the same decoder is > thawed and playback resumes where it left off in a consistent state. > > Make sense? The decoder part, yes! What about the MSG part? Does the MSG know that a media element is being frozen/thawed? Does it do anything special to handle that?

Assuming MSG == MediaStreamGraph, then yes it looks like we set a blocker count in nsHTMLMediaElement::SuspendOrResumeElement() which I assume performs the suspend/resume semantics. Roc can confirm that.

Yes. You should be able to pause/resume the MSG destination node in the same way.

It's not every day that one gets to dupe a bug against one of their own!

Mass moving Web Audio bugs to the Web Audio component. Filter on duckityduck.