getUserMedia is flaky with forward/back history behaviour

NEW
Assigned to

Status

()

P4
enhancement
Rank:
36
6 years ago
a year ago

People

(Reporter: beta, Assigned: jesup)

Tracking

19 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

6 years ago
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

Updated

6 years ago

Updated

6 years ago
Flags: needinfo?(john)

Updated

6 years ago
Component: Untriaged → Video/Audio
Product: Firefox → Core
(Reporter)

Comment 2

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

Comment 3

6 years ago
(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?
(Assignee)

Comment 5

6 years ago
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
(Assignee)

Comment 8

6 years ago
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.
(Assignee)

Comment 9

6 years ago
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.
(Assignee)

Comment 10

6 years ago
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
(Assignee)

Comment 11

6 years ago
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-]
(Assignee)

Comment 12

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

Comment 13

5 years ago
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]

Updated

4 years ago
backlog: --- → webRTC+
Rank: 36
QA Contact: jsmith
Whiteboard: [getUserMedia]
Mass change P3->P4 to align with new Mozilla triage process.
Priority: P3 → P4
You need to log in before you can comment on or make changes to this bug.