1114433 - location.reload() in a frame leaves behind dangling gUM permission prompt

Status: VERIFIED FIXED

(Firefox :: Site Permissions, defect)

Description

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

STR:
1. Open URL.
2. Hit [Start!] button to call gUM.
3. Ignore permission prompt and hit [then Reload page with this button!].

Expected result:
- The minimized-doorhanger camera icon in the URL bar should disappear.

Actual result:
- The minimized-doorhanger camera icon sticks around, and if I click it,
  I get a doorhanger that seemingly functions but accomplishes nothing
  (I have to hit [Start!] again to get a doorhanger that actually works.)

Workaround:
- Hit refresh in the url bar.

Comment 1

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

Not sure which side the error is on...  should be easy to track down.

Comment 2

[Florian Quèze [:florian]]

Attachment: Patch v1

(In reply to Randell Jesup [:jesup] from comment #1)
> Not sure which side the error is on...  should be easy to track down.

Well... both: I don't think the media manager code sends any notification when dropping pending requests; and so the UI also doesn't do anything to handle that.

The attached patch works around this by listening to the unload event in the front-end code. This is probably a reasonable thing to do, but if we intend to make gUM requests cancelable (ie. give web pages an API to cancel the request), we should really have a notification from the media manager code to the front-end to signal that.

The f? request is mostly to get a confirmation about whether such a notification exists/is planned in the back-end or if we should move forward with the approach in the attached patch.

Comment 3

[Florian Quèze [:florian]]

Comment on attachment 8544612 [details] [diff] [review]
Patch v1

I discussed this in #media with jesup and jib. jib said the approach of using the unload event seemed good to him. So changing the f? to r?.

I wrote a test for this, but given that I also wrote tests for a bunch of other frame related gUM edge cases, I put the tests separately in bug 1120546.

Comment 4

[Florian Quèze [:florian]]

https://hg.mozilla.org/integration/fx-team/rev/03d7a18981e4

Comment 5

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/03d7a18981e4

Comment 6

[Florian Quèze [:florian]]

Tests were added in bug 1120546.

Comment 7

[Florian Quèze [:florian]]

Comment on attachment 8544612 [details] [diff] [review]
Patch v1

Approval Request Comment
[Feature/regressing bug #]: getUserMedia permission UI, not a recent regression AFAIK.
[User impact if declined]: if web developers reload the frame that did a getUserMedia call to cancel the request (currently the recommended hack, as there's no API to cancel gUM requests), the permission request UI won't be removed.
[Describe test coverage new/current, TreeHerder]: Automated tests added in bug 1120546 for m-c, QA will verify.
[Risks and why]: The patch is in my opinion too complicated to take on beta, but seems (to me) acceptable for aurora at this point.
[String/UUID change made/needed]: none.

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/510873b2ee88

Comment 9

[Bogdan Maris, Desktop Test Engineering]

Reproduced the initial issue using an old Nightly build, verified that the issue does not reproduce anymore on Windows 7 64-bit, Ubuntu 14.04 32-bit and Mac OS X 10.9.5 using latest Aurora and latest Nightly.