804111 - Should page re-request permissions for getUserMedia when coming out of bfcache?

Status: NEW

(Core :: WebRTC: Audio/Video, enhancement, P4)

Description

[John Drinkwater (:beta)]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/19.0 Firefox/19.0
Build ID: 20121019030551

Steps to reproduce:

Visited https://blog.mozilla.org/dolske/2012/10/21/image-enhancement-gum/
Accepted share camera, played about, viewed the canvas image (navigated to data: url), then returned with Back button.
Camera was open (webcam light still on), but no image shown.



Expected results:

When returning, the camera should work correctly.

Possibly related ‐ not much afterwards I triggered a crash https://crash-stats.mozilla.com/report/index/bp-a7541adc-5040-4399-951b-ad16c2121022

Comment 1

[Ioana (away)]

John, can you reproduce this issue in safe mode or with a clean profile?
http://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles
http://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode

Comment 2

[John Drinkwater (:beta)]

Yup.

Navigate to the URL, click ‘try it out in your browser here’, accept the camera request, press backwards, press forwards and you’re at the state I described.

Canvas has a static image of the last frame before you closed the window, webcam light is now off.

Comment 3

[John Drinkwater (:beta)]

(In reply to John Drinkwater (:beta) from comment #2)
> Yup.

Thats with safe-mode with a clean profile running 19.0a1 (2012-10-30)

Comment 4

[Chris Pearce [:cpearce (Not reading bugmail)]]

Jesup, looks like your team's area?

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

Yes.  This may well have changed as significant code and API detail changes have happened here in the last two weeks.  But this is definitely in our area.  Can we re-confirm with a build from this week?

Comment 6

[Jason Smith [:jsmith]]

Confirmed on 10/31 build. 

STR:

1. Go to https://blog.mozilla.org/dolske/2012/10/21/image-enhancement-gum/
2. Select "Try it out in your browser here"
3. Allow camera access and wait until your cam video stream starts
4. Select Back
5. Select Forward

Expected:

I would expect a re-prompt to occur asking for camera again. No camera frame should be seen.

Actual:

No camera prompt. The last camera frame is still seen.

Comment 7

[Jason Smith [:jsmith]]

cc Justin Dolske since the bug is driving from his demo

Comment 8

[Randell Jesup [:jesup] (needinfo me)]

Without looking into the internals, my assumption is that a page should be blocked from entering the bfcache if there's an active getUserMedia stream (and if this is hard to track, if getUserMedia has ever been called).  And I assume we're not doing this currently.

Comment 9

[Randell Jesup [:jesup] (needinfo me)]

Here's the comment from the DataChannel DOM review:
https://bugzilla.mozilla.org/show_bug.cgi?id=733002#c39
---------------------------------------------------

> >+  // Do we need to observe for window destroyed or frozen?  (same bug)
> Well, what should happen when the window/document goes to bfcache?
> And what should happen when the page goes out from bfcache?
> I think it might be ok to disable bfcache if we have webrtc active.
> Add something to nsDocument::CanSavePresentation

A very good point; PeerConnections should die on navigation (and that will ripple down to the DataChannels attached to it).  Perhaps they should add themselves as unload or beforeunload listeners to the document, which will let them kill themselves as well as block CanSavePresentation. Per Olli, it would need to a system event handler, so it can't be blocked (e.g. AddSystemEventListener())

(This patch is being reviewed in a slight vacuum, since PeerConnection isn't ready - I plan to lash it into the DOM in a temporary place until PeerConnection lands).  If we ever decide to use DataChannels without PeerConnection (which I doubt due to all the NAT traversal and negotiation issues), we'd need to deal with this directly.

Comment 10

[Randell Jesup [:jesup] (needinfo me)]

Note: that talks of PeerConnections, but here we don't have the same sort of object to hang the state off of; we'll need to hang it somewhere lower; OR hang it off of LocalMediaStream (which may make the most sense, as that's directly tied to getUserMedia-provided streams, and if the streams are dead the observers/etc will die with them and no longer block bfcache)

Comment 11

[Randell Jesup [:jesup] (needinfo me)]

Nothing fatal here; we need to think about what the right behavior is (perhaps my suggestions in comment 10) and how we could reasonably implement it.  Hitting reload will restart the page.  Not blocking to preffing on, however.

Comment 12

[Randell Jesup [:jesup] (needinfo me)]

Reinvestigate - I thought we landed bfcache blocking.  We do invalidate the getUserMedia instance on navigation.

Though the page should handle navigation back by re-connecting getUserMedia...

Comment 13

[Randell Jesup [:jesup] (needinfo me)]

This is working as intended for some time now. 

The open question here is how (and whether) to cause the page to re-request getUserMedia if it's restored from the bfcache/etc.

This would require a third state for MediaStreams: dormant.  Also there would be a UI impact, as this would merely re-activate a dormant stream, with no changes in options selected allowed.  Chrome avoids this by simply having Allow and Deny - they may also be forcing reload; I haven't experimented so see what they're doing.

There might also be standards-committee involvement here, though bfcache behavior generally is up to the UA

Comment 14

[Bulk Bug Changes for mreavy's org]

Mass change P3->P4 to align with new Mozilla triage process.