Figure out what we need to do when Web Audio is playing and a navigation occurs

RESOLVED DUPLICATE of bug 815492

Status

()

Core
Web Audio
RESOLVED DUPLICATE of bug 815492
5 years ago
5 years ago

People

(Reporter: Ehsan, Unassigned)

Tracking

Trunk
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
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.
(Reporter)

Comment 3

5 years ago
(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?
(Reporter)

Comment 5

5 years ago
(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.
Flags: needinfo?(roc)
Yes. You should be able to pause/resume the MSG destination node in the same way.
Flags: needinfo?(roc)
(Reporter)

Comment 8

5 years ago
It's not every day that one gets to dupe a bug against one of their own!
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 815492
(Reporter)

Comment 9

5 years ago
Mass moving Web Audio bugs to the Web Audio component.  Filter on duckityduck.
Component: Video/Audio → Web Audio
You need to log in before you can comment on or make changes to this bug.