1340174 - Calling getUserMedia right after stopping a stream sometimes doesn't prompt the user for permission

Status: NEW

(Firefox :: Site Permissions, defect, P3)

Description

[ovidiu boca[:Ovidiu]]

[Affected versions]: 
DeveloperEdition 53.0a2

[Affected platforms]:
 Mac OS X 10.12

[Steps to reproduce]:

1. Go to https://webrtc.github.io/samples/src/content/getusermedia/resolution/
and select all the resolutions(QVGA,VGA,HD,Full HD) that are available
2. Change between resolution (try at leat 5-6 times)

[Expected result]:

All the time when a resolution is changed you need to be prompted with control centre pop-up

[Actual result]:
 After you try 5-6 times to switch between resolutions the control centre pop-up is not displayed on all of them.

Comment 1

[Johann Hofmann [:johannh]]

I can reproduce with 54, but it only happens for me when you quickly select a new stream. This might be related to 1270572, which made it so that the old stream is reused. In this case it might not be garbage collected fast enough? Or there's a race condition on the page? In any case, this is likely not an issue with the permission prompts (assuming this can't be reproduced with other permissions). I'd also say it's not a big issue at all.

Comment 2

[Florian Quèze [:florian]]

This is an edge case of what we implemented in bug 1270572.

What's happening here is that the page is stopping all existing tracks right before doing a new getUserMedia call.

At https://webrtc.github.io/samples/src/content/getusermedia/resolution/js/main.js the getMedia function looks like this:
function getMedia(constraints) {
  if (stream) {
    stream.getTracks().forEach(function(track) {
      track.stop();
    });
  }

  navigator.mediaDevices.getUserMedia(constraints)
  .then(gotStream)
  .catch(function(e) {...});
}

Our code in webrtcUI.jsm sometimes gets the "webrtc:StopRecording" notification first (in which case we show the prompt), and sometimes gets the "webrtc:Request" notification first, in which case we allow the stream without prompting.

There's no security risk here, but it would be nice if we could make the behavior deterministic. Would there be a way to force the "webrtc:StopRecording" notification to always happen before a new "webrtc:Request" notification?