Closed Bug 1114433 Opened 5 years ago Closed 5 years ago
.reload() in a frame leaves behind dangling g UM permission prompt
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.
Not sure which side the error is on... should be easy to track down.
(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
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
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
Product: Core → Firefox
Version: 34 Branch → Trunk
Attachment #8544612 - Flags: review?(felipc) → review+
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 38
Tests were added in bug 1120546.
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.