User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.84 Safari/537.36 Steps to reproduce: I click a button that perform a getUserMedia specifying mediaSource: 'window', this opens the door hanger popup, but then if I press the esc button (maybe because I pressed the wrong button and I want to cancel the getUserMedia request) the permission to share the screen is blocked for the entire session. Actual results: After I press "esc" key to cancel the screen sharing GUM request, I cannot request other screen sharing requests for the session. Expected results: I expect that on "esc" key press the popup hide canceling the GUM request without prevent future screen sharing GUM as in Google Chrome for example. This would allow developers and users to cancel the current GUM request not preventing future requests.

It seems to be intentional, see 46985f01d9ac Johann Hofmann — Bug 1320719 - The Esc key should deny permission requests for persistent prompts. r=florian

(In reply to Alice0775 White from comment #1) > It seems to be intentional, see > 46985f01d9ac Johann Hofmann — Bug 1320719 - The Esc key should deny > permission requests for persistent prompts. r=florian Is it possible to discuss about the intentionality of this? I don't get the whole point of why "The Esc key should deny permission requests for persistent prompts". I don't think that is correct to use esc button to imply a denial of something. Esc button is often used as "undo" action or something similar. Furthermore there is no way to dismiss the door hanger without allowing a source or denying all the future requests, making impossible for developers to handle those cases where a user click the button to request screen sharing permissions by mistake, plus a checkbox to "remember the choice" is showed to the user but it can't actually be used with screen sharing, making the whole user experience even more confusing.

(In reply to simone.mazzoni13 from comment #2) > I don't think that is correct to use esc button to imply a denial of > something. Esc button is often used as "undo" action or something similar. The assumption was that Esc means "don't bother me", so we prevent the website from showing more of the same prompt. The block is only temporary. Reloading the page waves it.

(In reply to Florian Quèze [:florian] from comment #3) > (In reply to simone.mazzoni13 from comment #2) > > > I don't think that is correct to use esc button to imply a denial of > > something. Esc button is often used as "undo" action or something similar. > > The assumption was that Esc means "don't bother me", so we prevent the > website from showing more of the same prompt. > > The block is only temporary. Reloading the page waves it. I got your point, but where did that assumption came from? Assuming that pressing esc not to get bothered again is the intended behaviour for the average user, how can a developer or the user itself, cancel the action without completely deny the permission?

(In reply to simone.mazzoni13 from comment #4) > Assuming that pressing esc not to get bothered again is the intended > behaviour for the average user, how can a developer or the user itself, > cancel the action without completely deny the permission? Reloading the page cancels the action. Or you just press esc (or click deny) and then remove that temporary permission with the [x] from the control center panel (the panel in your screenshot).

(In reply to Florian Quèze [:florian] from comment #5) > (In reply to simone.mazzoni13 from comment #4) > Reloading the page cancels the action. Or you just press esc (or click deny) > and then remove that temporary permission with the [x] from the control > center panel (the panel in your screenshot). I understand, but that process is far more complicated than it needs. An average user will just resign using that functionality and this leads to poor UX though. There are several cases where reload the page isn't possible, and explain users how to manually re-enable permissions is painful and often not easy due to different UI among different versions of the browser. Why just don't give the option to dismiss the prompt without deny the permissions? Or event better, why don't show a dedicated button or checkbox to enable the permanent denial instead of make it the default behaviour?

https://github.com/w3c/permissions/issues/48 this issue already highlighted the question years ago.

(In reply to simone.mazzoni13 from comment #6) > I understand, but that process is far more complicated than it needs. > An average user will just resign using that functionality and this leads to > poor UX though. An "average user" won't know the Esc key exists. > Why just don't give the option to dismiss the prompt without deny the > permissions? That's the behavior we used to have, and it led to lots of users dismissing the prompt and forgetting about it, leaving the page in an unknown state because it didn't know if the user was ever going to make a decision. Due to that feedback we had from web developers, we changed our prompts to require a decision.

(In reply to Florian Quèze [:florian] from comment #8) > (In reply to simone.mazzoni13 from comment #6) > > > I understand, but that process is far more complicated than it needs. > > An average user will just resign using that functionality and this leads to > > poor UX though. > > An "average user" won't know the Esc key exists. > That's even worst since that user will click the "Don't allow" button totally denying the access to screen sharing. > > Why just don't give the option to dismiss the prompt without deny the > > permissions? > > That's the behavior we used to have, and it led to lots of users dismissing > the prompt and forgetting about it, leaving the page in an unknown state > because it didn't know if the user was ever going to make a decision. Due to > that feedback we had from web developers, we changed our prompts to require > a decision. If I'm not wrong, the problem with prompt decision was about the fact that press the Esc key won't resolve or reject the getUserMedia promise/callback hanging that promise indefinitely. The approach I'm thinking about is more to provide also an option to the user to dismiss the prompt, without denying the entirely permission, and reject the GUM promise with a message or code that explains developers what the user did (denied the permission, dismissed the prompt without answering) like google chrome does. This would increase UX since it will clearly explain a user what it's choice will cause. I had clients that on firefox denied screen permissions for the entire session just because they clicked by mistake on the screen sharing button and found that the only way to dismiss the panel was click "Don't Allow" or press Esc, preventing future usage of the screen sharing functionality.

I understand your issue, but giving the developer an opportunity to re-prompt before user-initiated navigation will lead to sites spamming repeated permission prompts (either in good faith because they think surely the user meant to allow this feature or just because they're malicious and annoying). If the user denies a permission prompt we show a little crossed-out icon in the identity block. With these restrictions it is imaginable that a few users may find it hard to revert permissions when they made a wrong decision, but I can't see how we could improve on this without compromising on the protection we provide to everyone who chooses correctly and/or knows how to revert their decision. Thank you for your feedback. Closing this bug.

(In reply to Johann Hofmann [:johannh] - slow to respond, digging out of PTO backlog from comment #10) > I understand your issue, but giving the developer an opportunity to > re-prompt before user-initiated navigation will lead to sites spamming > repeated permission prompts (either in good faith because they think surely > the user meant to allow this feature or just because they're malicious and > annoying). If the user denies a permission prompt we show a little > crossed-out icon in the identity block. > > With these restrictions it is imaginable that a few users may find it hard > to revert permissions when they made a wrong decision, but I can't see how > we could improve on this without compromising on the protection we provide > to everyone who chooses correctly and/or knows how to revert their decision. > I understand your concern, but not giving a choice to dismiss a permission prompt without denying the permission itself does not sounds right to me (and others I'm sure). Google Chrome addressed the spam problem you mentioned allowing up to 3 permission prompt requests before automatically deny the permission. That sounds like a reasonable trade off to me. I know spam permission prompts is a problem and is a fact, but Firefox approach looks a little bit brutal to me. Anyway since you closed the issue and you marked it as won't fix, I have no choice but to suggest to use another browser to my users. Or wrap GUM permission request with another custom prompt to ask if the user is really sure he wants to share its screen o whatever action involves a permission request. Very annoying but I don't see other options though. > Thank you for your feedback. Closing this bug.