Open Bug 804111 Opened 12 years ago Updated 2 years ago

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

Categories

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

19 Branch
enhancement

Tracking

()

People

(Reporter: beta, Unassigned)

References

()

Details

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
Flags: needinfo?(john)
Component: Untriaged → Video/Audio
Product: Firefox → Core
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.
Flags: needinfo?(john)
(In reply to John Drinkwater (:beta) from comment #2)
> Yup.

Thats with safe-mode with a clean profile running 19.0a1 (2012-10-30)
Jesup, looks like your team's area?
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?
Component: Video/Audio → WebRTC
Flags: needinfo?(john)
QA Contact: 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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(john)
cc Justin Dolske since the bug is driving from his demo
OS: Linux → All
Hardware: x86_64 → All
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.
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.
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)
Whiteboard: [getUserMedia][blocking-gum+]
Priority: -- → P1
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.
Assignee: nobody → rjesup
Priority: P1 → P2
Whiteboard: [getUserMedia][blocking-gum+] → [getUserMedia][blocking-gum-]
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...
Flags: needinfo?(rjesup)
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
Severity: normal → enhancement
Component: WebRTC → WebRTC: Audio/Video
Flags: needinfo?(rjesup)
Priority: P2 → P3
Whiteboard: [getUserMedia][blocking-gum-] → [getUserMedia]
backlog: --- → webRTC+
Rank: 36
QA Contact: jsmith
Whiteboard: [getUserMedia]
Mass change P3->P4 to align with new Mozilla triage process.
Priority: P3 → P4
Assignee: rjesup → nobody
Summary: getUserMedia is flaky with forward/back history behaviour → Should page re-request permissions for getUserMedia when coming out of bfcache?
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.