Closed Bug 1114433 Opened 5 years ago Closed 5 years ago

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


(Firefox :: Site Permissions, defect)

Not set



Firefox 38
38.1 - 26 Jan
Tracking Status
firefox37 --- verified
firefox38 --- verified


(Reporter: jib, Assigned: florian)





(1 file)

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.)

- Hit refresh in the url bar.
Not sure which side the error is on...  should be easy to track down.
Flags: needinfo?(florian)
Attached patch Patch v1Splinter Review
(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.
Assignee: nobody → florian
Flags: needinfo?(florian)
Attachment #8544612 - Flags: feedback?(rjesup)
Summary: location.reload() leaves behind dangling gUM permission prompt → location.reload() in a frame leaves behind dangling gUM permission prompt
Blocks: 1120546
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.
Attachment #8544612 - Flags: feedback?(rjesup) → review?(felipc)
Points: --- → 5
Component: WebRTC: Audio/Video → Device Permissions
Flags: qe-verify+
Flags: firefox-backlog+
Product: Core → Firefox
Version: 34 Branch → Trunk
Iteration: --- → 37.3 - 12 Jan
Iteration: 37.3 - 12 Jan → 38.1 - 26 Jan
Attachment #8544612 - Flags: review?(felipc) → review+
Closed: 5 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → Firefox 38
Tests were added in bug 1120546.
Flags: in-testsuite+
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.
Attachment #8544612 - Flags: approval-mozilla-aurora?
Attachment #8544612 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
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.
You need to log in before you can comment on or make changes to this bug.