First off, this isn't an oversight on your part — this is indeed a known implementation quirk (and arguably a bug) in Safari's handling of getUserMedia permissions compared to Chrome and Firefox. Let’s break down what’s happening:

Key Behavior Differences #

• Chrome/Firefox: Once you deny a getUserMedia request for a specific permission group (like {audio: true, video: true}), all subsequent requests for that same group (or even more specific constraints under it) immediately throw the NotAllowedError without prompting the user again. This aligns with the WebRTC spec’s intent to respect user choices consistently.
• Safari:
  • After first denying a request with {video: true, audio: true}, the second identical request will re-prompt the user (this is the unexpected behavior you observed). Only after rejecting that second prompt will all future identical requests fail immediately.
  • If you switch to a different constraint (such as specifying exact deviceIds for audio/video), Safari skips the prompt and throws NotAllowedError right away — this part matches other browsers’ behavior.

Why JSFiddle Behaves Differently #

Your observation about JSFiddle is correct: Safari treats iframe contexts differently for permissions. When running in an iframe, Safari resets or isolates the permission state more strictly, which is why you don’t see the re-prompt behavior there. This is a browser-specific security measure for embedded content, not a reflection of how your code would behave in a top-level page.

Optional Verification Steps #

If you want to confirm further:

• Check Safari’s Privacy > Website Permissions settings after your first denial — you’ll notice the site isn’t added to the "Denied" list until you reject the second prompt. That’s why Safari allows a second prompt.
• Test with single-permission requests (e.g., {audio: true} only) — you’ll likely see the same re-prompt behavior on the second request before permissions are fully locked down.

Takeaway #

This is a quirk in Safari’s permission management logic, not a mistake in your code. To handle this consistently across browsers, you might want to:

• Track user permission choices in your app’s state (e.g., a flag for whether audio/video permissions were denied)
• Avoid making duplicate identical requests after a denial to prevent unexpected prompts for Safari users

内容的提问来源于stack exchange，提问作者Adam Soto