6

So the standard way that navigator.webkitGetUserMedia is used is like such:

function success() {
    console.log('User accepted');
}

function deny() {
    console.log('User rejected');
}

navigator.webkitGetUserMedia({video: true, audio: true}, success, deny);

The site I'm developing absolutely needs the use of the user's webcam and microphone (actually, using Flash, but that seems to go through this API now), so I'm trying to do everything to ensure the user always knows what they need to click for the site to work.

  • If neither function is called, assume the dialog is showing, and display instructions to the user.
  • If deny is called, explain that webcam access is needed, and show them they can click the camera icon in Chrome's URL bar to change their decision.
  • Of course, if success is called, then the user has accepted, and continue as normal.

Here's the kicker; and you could follow along by pasting the above Javascript into any site you like (in Chrome). If the user navigates to a new webpage, or refreshes the current page without either accepting, denying, or dismissing the dropdown, they will not see a permissions dialog again for the current domain for the browser session.

Calling navigator.webkitGetUserMedia(...) again will not show a permissions dialog, nor will the camera icon even appear in the URL bar. The console doesn't even log "User rejected". What's more, for many users this dropdown is very easy to accidentally ignore. The only fix available is to close the browser entirely and re-open it (or, to manually navigate through complicated settings menus that we DON'T want to force our users into).

Can I confirm with anyone here whether this is 'somehow' intended, or if there's something I'm missing?

Katana314
  • 8,429
  • 2
  • 28
  • 36
  • It seems to work for me (Chrome 27 on Windows Vista). If I refresh the page, the permission bar ups up again. If I navigate to another page, and then back to the initial page it also pops up again. Maybe check if you've already got an exception set for that hostname: chrome://settings/contentExceptions#media-stream – James Holderness Jul 13 '13 at 14:03
  • Try this way: Go here: http://www.testwebcam.com/ then click Allow inside of Flash. Then, do not click the Chrome banner at all, but refresh the page. Click Allow on Flash again - no banner. No site exceptions set; we clear that menu each time to re-test. – Katana314 Jul 13 '13 at 15:00
  • I don't ever get the permission banner on that page - just the Flash permission dialog. I can specifically block media permissions in Chrome for that domain and it won't make any difference. In the settings it says "Adobe Flash Player camera and microphone exceptions are different." so I guess that makes sense. I'm assuming it's different for you - what OS are you using? – James Holderness Jul 13 '13 at 15:20
  • I'm at home, using Windows 8 (happens here). At work where the issue cropped up, we use Windows 7. Also, Chrome 27 is not the latest. – Katana314 Jul 13 '13 at 15:22
  • Upgraded to Chrome 28 and I can reproduce the problem on the testwebcam page with Flash. So it looks to me like it might be a bug introduced somewhere between version 27 and 28. – James Holderness Jul 14 '13 at 14:10

1 Answers1

6

It seems that this is a known bug.

Issue 252904: Infobar popup on mic/cam permission results in unexpected permission state; causes unrecoverable lack of permission on reload

There are currently two patches in the comment thread on that bug, so at least you know they are working to fix the issue. Unfortunately there don't appear to be any real workarounds for the bug in the mean time.

One thing worth mentioning: if you close the tab and then reopen the url, that does seem to force the permission dialog to show again. I know that's not a real solution, but at least it's better than closing the whole browser (which I think is what you've been doing up to now).

James Holderness
  • 22,721
  • 2
  • 40
  • 52
  • Thanks very much for the info; I'll likely give this answer the bounty unless someone finds some amazing workaround. Good to know it's being worked on. Unfortunately, our site has a lot of state-preservation that could get messed up if a user closes and reopens a tab at the same URL. Plus, it's still less intuitive than we'd like for our users. – Katana314 Jul 16 '13 at 13:24