User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 Steps to reproduce: Navigator.getUserMedia displays popup to have access to camera device. Click on "Note Now" Actual results: No feedback is returned when user selects "Not Now" option. Neither errorCallback nor successCallback are executed. Expected results: A call back function must be executed if "Not Now" is selected so that the developer implements the appropriate case

This is by design - the request is still active, and can be brought back and answered at any time by the user using the icon in the Awesome Bar (URL bar). The user has not made a choice (thus: "Not now"). "Don't Share" will fire the failure handler. It would be nice, perhaps, if we could display "Share Selected Device(s)", "Not Now", and "Don't Share" without using a dropdown, but that's at least arguable. My understanding is that currently the Firefox doorhanger code doesn't let us do that. All that said about why things are the way they are, there's a slight disconnect between the spec and how we implement it, in that the spec semi-assumes that the user will be presented a modal dialog and will accept or deny, not defer. However the API doesn't really let us indicate this in any way; to do so we'd need a different API (as Martin proposed at one point, where getUserMedia() returns immediately and later you get notifications about success, failure, etc). We'll probably want to close this as "WONTFIX".

I have a few concerns with the current UX story. I've been looking into the code, and it is possible to have a different structure. Other doorhangers use a different structure, at a fairly marginal cost in complexity. We certainly don't want anything as complex as the identity one, but the plugin one is probably OK complexity-wise, even if it's broken in my current build. For this, I think that "Not Now" is just as easily handled by the close button, or by dismissing the doorhanger. I'd consider that more likely to make sense to a user too. (This option doesn't work for android/b2g. On those platforms, this is far too modal for my taste, but I haven't gotten a good idea on how to proceed there yet.) With respect to the synchronous gUM proposal, that's orthogonal to this issue.

Thank you for your explanations. The question remains: given your current design, how can the developer know that the user selected "Not Now" case? For example is there a function that returns the state of the dialog (so that we know when it's closed)? Brief description of the scenario that we are dealing with: The user can upload a profile picture from the camera, so our application waits for the user's decision. If they share their camera we display a view where they can take a picture and upload it. However if they deny the camera access, we switch to a different view. The problem is: if the user chooses "Not Now" the flow of our application stops because we don't receive any feedback that the "Not Now" case was chosen.

(In reply to yousra.harkat from comment #3) > The question remains: given your current design, how can the developer know > that the user selected "Not Now" case? For example is there a function that > returns the state of the dialog (so that we know when it's closed)? No, there is no such function. That is entirely intentional. A user that dismisses the doorhanger does so for their own reasons, and we don't want to give applications more information than the user might expect to have revealed as a result. Maybe they are looking for the control panel to enable their fancy new camera. Given that "dismiss" is passive and might simply be as a result of loss of focus, conveying information to an application would also do the application a disservice. > The problem is: if the user chooses "Not Now" the flow of our application > stops because we don't receive any feedback that the "Not Now" case was > chosen. That's right. If you don't get a response, then I suggest you run your own timers and gently remind the user that the option to use their camera still exists. The problem with "Not Now" is that is does imply some sort of action or communication on the part of the user, which is confusing. If we remove that, then things are improved.

Chrome will fire errorCallback handler when the userMedia dialogue is intentionally closed (with the X) or "Deny" is selected. Why do we have to implement special case hackish timers for this in Firefox? Consider this scenario: User clicks to getUserMedia and a transition occurs on the page which will flip a card to show the video when "Accept" is clicked. When accept is clicked, a websocket connection occurs for the signaling, room might not be available and user gets an alert, transition gets undone (flipped back) and stream destroyed/reset. Also, when socket disconnect transition gets undone (flipped back) and stream destroyed/reset. If a transition occurs to show local video element before getUserMedia request to show the local video, and user opts not to show video by choosing "Not Now" or "Close" a timer is responsible to flip the card back to undo the transition? Seems very hackish, especially considering the UserMedia selection may still be visible and chosen to show video. In this case the transition to undo or card flip already occurred. Firefox errorCallback only gets called when explicitly denied. Not when intentionally closed (which is also denied) and not "Not now" which is also a denied userMedia access - is it not? If the user has bypassed or closed the media access request (clicked "X") or chose "Not Now" then these should be considered an implied PERMISSION_DENIED or a new fuzzy state PERMISSION_IGNORED in addition to the former NOT_SUPPORTED_ERROR and MANDATORY_UNSATISFIED_ERROR. PERMISSION_IGNORED might be a good option and gives developers more flexibility and consistency. Any use of a timer does not tell us if the getUserMedia dialogue is currently is opened or closed, and we have no option to get opened or closed state when userMedia dialogue if firefox timer expired. Please reconsider to fix this so that the behavior similiar as Chrome. There's something to be said about consistency especially when dealing with what should be cross-browser API's.

(In reply to Gary from comment #5) > Chrome will fire errorCallback handler when the userMedia dialogue is > intentionally closed (with the X) or "Deny" is selected. Why do we have to > implement special case hackish timers for this in Firefox? I think Martin has answered this question. We don't think it's something we should be conveying to the application. > > Firefox errorCallback only gets called when explicitly denied. Not when > intentionally closed (which is also denied) and not "Not now" which is also > a denied userMedia access - is it not? I don't think so, since you can always resurrect the dialog and grant permissions. > Any use of a timer does not tell us if the getUserMedia dialogue is > currently is opened or closed, and we have no option to get opened or closed > state when userMedia dialogue if firefox timer expired. > > Please reconsider to fix this so that the behavior similiar as Chrome. > There's something to be said about consistency especially when dealing with > what should be cross-browser API's. Consistency could equally be achieved by changing Chrome.

Now that's the kind of response I expected since there's still no fix for the Server Sent Events bug too: https://bugzilla.mozilla.org/show_bug.cgi?id=814144 <<Given that "dismiss" is passive and might simply be as a result of loss of focus, conveying information to an application would also do the application a disservice.>> How's that a disservice of any type? We could at least make sure we're not in "ready to show video mode" at the very least. Now that's a problem with the implementation and design of said "modal" doorhanger. When focus is lost, it disappears - and also no notification is sent to the developer. So in that sense, "Not now" or closing it is the exact same result. There is no way to query if it's visible or not and a timer solution wouldn't help because the doorhanger could still be visible and doesn't disappear or isn't closed automatically when the timer expires. Scenario: Run a transition on the page to prepare to show video maybe show a hidden div. IF user accepts the userMedia request, video is shown in the div as normal. IFF user does not accept and clicks close, or it loses focus or clicks "Not Now" you have no way to know if you should transition back to hide said div. If user doesn't respond right away before said timer expiration, and timer expires div gets hidden. Then what if the user accepts video request ... too bad, div is now hidden from said timer. Only now we can show said div when user selects. The current design imposes developers application design when using userMedia in Firefox. I guess there's no fix with the current design of this doorhanger since losing focus is also the same result other than a page reload at timer expiration so user can re-request userMedia access (lame).

(In reply to Eric Rescorla (:ekr) from comment #6) > I don't think so, since you can always resurrect the dialog and grant permissions. How are we supposed to know to communicate to the user that they need to do this? How is the user even supposed to know? > I think Martin has answered this question. We don't think it's something we should be conveying to the application. Right now it's effectively denying permission, just without the callback. Which means broken apps. An asynchronous call should never not call one of its success/failure callbacks! In Chrome M26 dismissing the bar (clicking the x) fires the error callback with error.name === 'PermissionDismissedError' - the main difference for a developer between that and a PermissionDeniedError is that Chrome remembers a Deny, where as a PermissionDismissedError allows the application to ask again (without reloading the page). I believe Firefox should do the same thing. From my perspective as a developer, not knowing this dialog has been closed makes it a lot harder to communicate to users how to gain access to an application. Especially because you just don't know why the dialog has gone away (did the page lose focus? did the user click X meaning no?) Best case, from my perspective, Chrome's behavior is much better.

(In reply to Patrick Quinn-Graham from comment #8) > (In reply to Eric Rescorla (:ekr) from comment #6) > > I don't think so, since you can always resurrect the dialog and grant permissions. > > How are we supposed to know to communicate to the user that they need to do > this? How is the user even supposed to know? > > > I think Martin has answered this question. We don't think it's something > we should be conveying to the application. > > Right now it's effectively denying permission, just without the callback. > Which means broken apps. An asynchronous call should never not call one of > its success/failure callbacks! > > In Chrome M26 dismissing the bar (clicking the x) fires the error callback > with error.name === 'PermissionDismissedError' - the main difference for a > developer between that and a PermissionDeniedError is that Chrome remembers > a Deny, where as a PermissionDismissedError allows the application to ask > again (without reloading the page). I believe Firefox should do the same > thing. > > From my perspective as a developer, not knowing this dialog has been closed > makes it a lot harder to communicate to users how to gain access to an > application. Especially because you just don't know why the dialog has gone > away (did the page lose focus? did the user click X meaning no?) > > Best case, from my perspective, Chrome's behavior is much better. I agree - that's why I will just tell users who want to use this new draft feature to use a real browser -- Chrome, and forget Firefox and IE since they both dictate application design.

(In reply to Martin Thomson [:mt] from comment #2) > For this, I think that "Not Now" is just as easily handled by the close > button, or by dismissing the doorhanger. I'd consider that more likely to > make sense to a user too. My takeaway here is that we should remove the 'Not Now' button. It is an inaction disguised as an action, it makes the application look unresponsive, and it violates everyone's expectations. That said, I like that Firefox users are free to ignore doorhangers for as long as they want or forever. This naturally makes it harder for applications to challenge the user linearly, which seems to be the intent. This has to be accounted for in the design of the application. (In reply to yousra.harkat from comment #3) > Brief description of the scenario that we are dealing with: > The user can upload a profile picture from the camera, so our application > waits for the user's decision. If they share their camera we display a view > where they can take a picture and upload it. However if they deny the camera > access, we switch to a different view. > > The problem is: if the user chooses "Not Now" the flow of our application > stops because we don't receive any feedback that the "Not Now" case was > chosen. Have you considered workflows that don't block on the user? For instance: - Stay where you are until both [Upload picture] button has been hit AND user has allowed camera, or - Go to the alternate (non-picture) view immediately and "upgrade" the user to the picture-view later once or if they ever allow camera (they may never do this). This way they'' still be able to use the rest of your app. I'm not claiming to have a solution for every application here, as this is obviously a tricky problem in general, but I hope some of this helps.

(In reply to Jan-Ivar Bruaroey [:jib] from comment #10) > My takeaway here is that we should remove the 'Not Now' button. It is an > inaction disguised as an action, it makes the application look unresponsive, > and it violates everyone's expectations. I definitely agree with that. I'd argue that the "X"/close button suffers from the same problem. I'm not necessarily arguing that the doorhanger hiding because of the firefox tab/window losing focus should be disabled or should cause the PermessionDeniedError here, but if the close button is there then it should trigger. That it is so easy to lose the doorhanger means even webrtc developers like myself can lose it, and think things are broken or that I've already clicked & allowed it (the icon in the address bar looks the same) and that the peerconnection has failed, tells me that I want to know when this happens to users of the API/applications I work on. > - Go to the alternate (non-picture) view immediately and "upgrade" the user > to the picture-view later > once or if they ever allow camera (they may never do this). This way > they'' still be able to use the > rest of your app. While this will work for some kinds of apps, others (such as any kind of video conferencing application) essentially cannot gracefully degrade. So while the doorhanger going away is not necessarily a bad behaviour, the fact that moving to another window/tab causes it to disappear (and returning does not bring it back) combined with this and the user clicking the

(In reply to Patrick Quinn-Graham from comment #11) > I definitely agree with that. I'd argue that the "X"/close button suffers > from the same problem. I think I agree. Hitting "x" doesn't really close the hanger, it just minimizes it, which is unexpected. I think a "minimize" icon would be more appropriate given what it does. An "x" I would expect would make it go away for good, which by inference would have to mean "Deny", which, as Gary points out in comment 5 would match what Chrome does. > While this will work for some kinds of apps, others (such as any kind of > video conferencing application) essentially cannot gracefully degrade. In an ideal world, one would think you could still connect the call, such that you could at least see and hear the other side, even if they couldn't see or hear you. Unfortunately, the current spec and API make this difficult. > while the doorhanger going away is not necessarily a bad behaviour, the fact > that moving to another window/tab causes it to disappear (and returning does > not bring it back) That's Bug 1004061.

(In reply to Jan-Ivar Bruaroey [:jib] from comment #12) > In an ideal world, one would think you could still connect the call, such > that you could at least see and hear the other side, even if they couldn't > see or hear you. Unfortunately, the current spec and API make this difficult. That kind of behaviour is entirely possible with the permission dialog being dismissed (minimized, focus lost) with something like Chrome's PermissionDismissedError, but also provides a way for the application to message the user with how to recover. Would need Bug 1004061 though, otherwise the losing window/tab focus would need to trigger it too, and that's less awesome!

(In reply to Martin Thomson [:mt] from comment #4) > That's right. If you don't get a response, then I suggest you run your own > timers and gently remind the user that the option to use their camera still > exists. > > The problem with "Not Now" is that is does imply some sort of action or > communication on the part of the user, which is confusing. If we remove > that, then things are improved. If the "Not Now" button is not removed then detection of it being pressed is absolutely necessary. As it stands it breaks pretty much any UX workflow. Your suggestion to use a timer is unfortunately not really a workable solution. Also if you run a timer and recall getUserMedia() in order to make the Firefox share request dialog popup again, if it eventually gets accepted this then causes a bug where the app can no longer close the created media stream. Calls to stream.stop() no longer work (or because there have been multiple requests, you are unable to close them all within your app) It just keeps sharing forever until the user refreshes the page or manually denies the sharing. We are finding this very frustrating at the moment, and for the the life of us cannot understand why there is any reluctance to either remove the "Not Now" button or to create some form of feedback to the application.

(In reply to gordon from comment #14) > Also if you run a timer and recall getUserMedia() in order to make the > Firefox share request dialog popup again, if it eventually gets accepted > this then causes a bug where the app can no longer close the created media > stream. I think Martin's point was to use a timer to either move on without a camera or remind users about the existing doorhanger (and/or admittedly help them locate it), not trigger a new one which I would classify as annoying the user. > We are finding this very frustrating at the moment, and for the the life of > us cannot understand why there is any reluctance to either remove the "Not > Now" button or to create some form of feedback to the application. I sense more support here for removing the "Not Now" button than detecting it, so I've renamed the bug. We've not heard from UX people here though. Supporting observations: Less interaction-demanding doorhangers like the secure website doorhanger (click the padlock symbol in the URL bar above) come with no dismissive buttons whatsoever, not even the little [x] close button, so there's precedence for doorhangers being ephemeral and not needing dismiss options to get rid of them. Our existing "Don't share" option seems sufficient and does everything people here want.

(In reply to Jan-Ivar Bruaroey [:jib] from comment #15) > Supporting observations: > > Less interaction-demanding doorhangers like the secure website doorhanger > (click the padlock symbol in the URL bar above) come with no dismissive > buttons whatsoever That's neither a doorhanger (a.k.a. popup notification) nor interaction-demanding.

This sounds like a Firefox UI proposal - in which case it's in the wrong component. I agree with Dao that the site identity panel is not a useful data point. The purpose of the "Not Now" button is to make it obvious that these notifications can be dismissed - removing the button would not change that. These notifications are designed such that they can be dismissed and later recalled (by clicking the icon in the URL bar), which is incompatible with sending a "don't share" signal to the web app in the dismissal case. Bug 1004061 or bug 1004055 seem to better cover the core issues here, but in any case if we're going to make changes to this UI, we're not going to do it without considering the overall design and intent of this UI, and we also won't do it piecemeal for the WebRTC prompt only.

(In reply to :Gavin Sharp [email: gavin@gavinsharp.com] from comment #17) > These notifications are designed such that they can be dismissed and later > recalled (by clicking the icon in the URL bar), which is incompatible with > sending a "don't share" signal to the web app in the dismissal case. You're using "dismiss" to mean different things in the same sentence here. I'll pick on it because I think the terminology problem is relevant. Presumably: 1. "dismissed and later recalled" speaks to the visibility of the UX element itself. 2. "dismissal case" is the case of rejection in the context of the request (sharing). These are different things that our UX arguably conflates, hence this bug. For the sake this discussion, lets call them: 1. minimize/ignore 2. reject and avoid the inherently ambiguous "dismiss" term in this thread. I can't unlearn how doorhangers work, but my first encounter with them is still fresh in my mind since it was less than two years ago that I realized the webrtc doorhangers were essentially still around in a minimized form even after I'd hit the [x] close button. I had two reactions: "That's useful!" and "surprising!" Had the doorhanger instead had a [_] minimize button, I might have been less confused, though to be honest, I don't recall that being the culprit, except perhaps in it contributing to the feeling that I was staring at a traditional modal dialog: .-------------. | [x]| | Share? | | [yes][no]| '-------------' and those things never come back (at least not when you want them to). I don't have a simple answer, but I think: 1. people expect close buttons to close, not minimize. 2. people consider in-context buttons to be resolve in context. i.e. a perceivable container/message separation is violated: .- container -. | dialog | '-------------' An immediate reduction of choices would solve this: [] .-/\--------------. | Share? | | [ allow ]| '-------|disallow|' '--------' I'll leave it to someone else to explain what problems this would cause, then we can compare trade-offs. > I agree with Dao that the site identity panel is not a useful data point. > > The purpose of the "Not Now" button is to make it obvious that these > notifications can be dismissed - removing the button would not change that. I take away two data-points: 1. No-one wonders how to disappear the site identity panel. 2. To a naive observer, the site identity panel, as a carrier-mechanism for a message, seems to have the same shape, spatial origin, and basic behaviors as doorhangers, with the exception of the message and buttons it carries, and that doorhangers appear to the left of a ">" separator in the URL bar, and panels to the right? So if we distinguish between attributes of the container vs. the message it carries, then doorhangers should be safe without close and not now buttons. Though, one difference perhaps is that #1 never appears on its own, so it has a much narrower attentive audience of inquisitive users.

(In reply to Jan-Ivar Bruaroey [:jib] from comment #18) > (In reply to :Gavin Sharp [email: gavin@gavinsharp.com] from comment #17) > > These notifications are designed such that they can be dismissed and later > > recalled (by clicking the icon in the URL bar), which is incompatible with > > sending a "don't share" signal to the web app in the dismissal case. > > You're using "dismiss" to mean different things in the same sentence here. > I'll pick on it because I think the terminology problem is relevant. No, same thing. "Dismissal" in PopupNotifiations terminology includes: - clicking "Not Now" in the dropdown - clicking the "x" - clicking anywhere else on the screen These are all distinct from the "negative" response ("Don't share"), intentionally. All result in the notification "disappearing", and the associated icon remaining in the location bar (unless the notification has its "removeOnDismissal" set to true, but we don't use that for permissions notifications). > I take away two data-points: > > 1. No-one wonders how to disappear the site identity panel. You would probably be surprised. See bug 615318 and bug 615315. For many people, when something pops up on their screen with a question, it is not obvious that the question can be deferred or ignored. > 2. To a naive observer, the site identity panel, as a carrier-mechanism > for a message, seems to have the same shape, spatial origin, and > basic behaviors as doorhangers, with the exception of the message > and buttons it carries, and that doorhangers appear to the left of > a ">" separator in the URL bar, and panels to the right? There is an important fundamental distinction in interaction between a prompt (i.e. it appears when you might not be expecting it, and you must react to it) and an information panel (which appears only when you explicitly cause it to appear, and does not require further interaction).

(In reply to :Gavin Sharp [email: gavin@gavinsharp.com] from comment #19) Thanks for clarifying and for the links. Sorry for misunderstanding. I appreciate and applaud the direction away from modal dialogs, and I buy that users need hints to learn that doorhangers are non-modal. Hopefully, fixing bug 1004055 will help users not misinterpret doorhanger minimization as an app that hangs when they say no. But "Not Now" still sounds negative and final, as in "Not this time", as in "Not this session", rather than "I haven't decided yet and want to keep my options open in this same session without telling the app". The latter is not an answer to the question but appears in the list of choices, making users think they completed the communication circle, when in reality they've unwittingly halted the conversation, and then blame the app for being unresponsive. > You would probably be surprised. See bug 615318 and bug 615315. For many > people, when something pops up on their screen with a question, it is not > obvious that the question can be deferred or ignored. Agreed, but I notice that bug 615318 landed first. Perhaps the "Not Now" choice is no longer needed now that the close button is there? Bug 650247 says "Not Now" is a problem for geo location as well. If we removed "Not Now" and reworked the [x] close button be a [-] minimize button would that solve the problem here (and may even help bug 1004055)?

I don't see having "Not Now" being a choice as causing actual user problems. It's been an important part of the original doorhanger design for a long time, has been used by a lot of different permission prompts since then, and I've not seen any sign of it being a problem. It might be fair to revisit the overall design (although I don't think it's worth doing so). But as noted in comment 17 and bug 895971 comment 21 -- this is a standard Firefox UI, and WebRTC prompts need to follow convention.

(In reply to Justin Dolske [:Dolske] from comment #21) > It's been an important part of the original doorhanger design for a long > time, has been used by a lot of different permission prompts since then, and > I've not seen any sign of it being a problem. We collect stats around users of our platform, the most relevent here is: getUserMedia neither allow or deny: Chrome: 9.8%, Firefox: 42.1% Now, how many of those 42.1% click the X or not now meaning "NO!" vs how many miss the doorhanger entirely? I cannot tell you because Firefox does not give me the tools to evaluate whether my users don't want to or they just haven't seen the doorhanger. FWIW Chrome think their design isn't good enough, and have an opt-in now to see a new UI that looks quite a lot like door hangers with two exceptions: it doesn't dismiss easily, and clicking the X errors with a PermissionDismissedError (which unlike a PermissionDeniedError in chrome is not permanent - a second gUM call in the page will bring up a prompt again). Here's their post about that https://groups.google.com/forum/#!topic/discuss-webrtc/0Oh7JYXyITg

(In reply to Patrick Quinn-Graham from comment #22) > We collect stats around users of our platform, the most relevent here is: > > getUserMedia neither allow or deny: Chrome: 9.8%, Firefox: 42.1% That seems to suggest people are minimizing the doorhanger instead of hitting deny (do you have the allow/deny numbers?) We could add telemetry probes to figure out how many of those who minimize the doorhanger ever reopen it, and of those how many ultimately make a choice. If those numbers are low (which I suspect they are) then people may effectively be using it as deny, and it seems fair to ask whether we intended for our leading deny workflow to not have any notification, and whether having the app never adapt to the user's preference is a desirable vs. inferior experience. > Now, how many of those 42.1% click the X or not now meaning "NO!" vs how > many miss the doorhanger entirely? I cannot tell you because Firefox does > not give me the tools to evaluate whether my users don't want to or they > just haven't seen the doorhanger. We could add telemetry probes to find out: How many clicked the button vs. outside (and how quickly outside, for Bug 1004061). > FWIW Chrome think their design isn't good enough, and have an opt-in now to > see a new UI that looks quite a lot like door hangers with two exceptions: > it doesn't dismiss easily, and clicking the X errors with a > PermissionDismissedError (which unlike a PermissionDeniedError in chrome is > not permanent - a second gUM call in the page will bring up a prompt again). > Here's their post about that > https://groups.google.com/forum/#!topic/discuss-webrtc/0Oh7JYXyITg Look at that. Kudos to the firefox UX team for paving the way on doorhangers! Interestingly, their design seems to address this problem.

(In reply to Jan-Ivar Bruaroey [:jib] from comment #23) > (and how quickly outside, for Bug 1004061). I mean bug 1004055.

(In reply to Jan-Ivar Bruaroey [:jib] from comment #23) > That seems to suggest people are minimizing the doorhanger instead of > hitting deny (do you have the allow/deny numbers?) The numbers vary, but the Deny numbers are typically around 0.3% for Chrome, and between 0-0.3% for Firefox. > We could add telemetry probes to figure out how many of those who minimize > the doorhanger ever reopen it, and of those how many ultimately make a > choice. If those numbers are low (which I suspect they are) then people may > effectively be using it as deny, and it seems fair to ask whether we > intended for our leading deny workflow to not have any notification, and > whether having the app never adapt to the user's preference is a desirable > vs. inferior experience. I agree. > We could add telemetry probes to find out: How many clicked the button vs. > outside (and how quickly outside, for Bug 1004061). I'd be curious how many hit X vs hit Not Now vs accidentally dismissed it (all the bug 1004055 possibilties) > Interestingly, their design seems to address this problem. I'll be very interested to see if it lowers the Chrome number down.

I think bug 1004055 is a real problem worth solving, and I think that some indication to the web page that the prompt was dismissed (but not denied) is worth exploring, because I see the value from a web author's perspective (though I'm not sure how that would work given the existing prompt API design).

I'm a chrome user and i only went to my site to test it out in firefox. I pressed the [x] button and was surprised to not getting a PermissionDismissedError. Almost created a new bug for this, its not until i read this topic that i realized that the dialog had been minimized and that there were small icon in the address bar (totally missed that out) were i could still set or deny I must say that a PermissionDismissedError is very useful and that lets us address the issue. I would vote for a PermissionDismissedError like chrome dose. If you are not going to do that then i suggest you to to fix the UI flaws by changing the [x] button to a minimize and use the same enter-animation but reverse. Grow animation means a new or existing dialog/program is being open Shrink animation means a new or existing dialog/program is being minimized No animation means a dialog/program is being closed But there is still a win-win for chrome because you always know when there is a visible request dialog. (Now i'm using geolocation as an example but it goes the same for getUserMedia) Pressing esc key is like saying to a website "No! I don't want to give you my location this time, so what should you do about it instead?" I don't know I don't get any feedback, i could show you a input how to get from point A to B. but again i don't get any feedback Its not like i want to permanently deny access to geoLocation when i'm pressing ESC-key and i'm not going to tell it to you at any later point either, I just to know from another A/B point then were i'm currently at

PermissionDismissedError is a chrome-specific extension. If you think that this is a good idea, then you should make a proposal to the appropriate groups (public-geolocation@w3.org, public-media-capture@w3.org, etc...) Google, thus far, have never mentioned or proposed this feature. Mozilla seems divided on the subject thus far, so I can't predict how successful you would be. Note that there is a new permissions experience planned, so that may change the situation.

I just stumbled upon this and upvoted, as I think the current behaviour leads to a very confusing UI design in the app, since you cannot react on the users dismissal of the dialog. What makes things worse is that it is sufficient to click anywhere else than the dialog to dismiss it. At least for me, this means: "I want to deny this request." It actually took me this very bug description to understand that you can answer the dialog later by clicking on the camera icons. Never ever would I tried this without these explanations. IMHO, being able to defer this dialog doesn't make any sense at all. I either want to accept the request, or I want to deny it. Anything in between is more confusing than helping. If you want to keep this behaviour, it should be at least possible for an app to react on this situation, e.g. by offering the user an explicit button to re-request permissions (the native FF button is just not eye-catching enough).

+1 on comment 27 about the difference between "shrink animation" == minimize and "no animation" == close, and similarly [x] vs [_]. This bug is actually about the similarly conflating "Not Now" non-choice choice in the doorhanger itself, but it's the same confusion. See also bug 1004055. Note that Chrome only needs PermissionDismissedError because it implicitly denies access permanently otherwise, something Firefox does, and therefore would not need PermissionDismissedError, it could just respond with the regular denied error, if it decided to conflate minimize with close properly. I have an opinion, but would just note for now that these UX bugs can be addressed whether Mozilla stands by its minimize behavior or not.

s/something Firefox does/something Firefox NEVER does/

I think that a permission request that was minimized (not now) should call the error callback with a dismiss error so that the developer can implements the appropriate case cuz it happens right at that moment. Wouldn't want them to wait for an answer forever until you can proceed. If the design was that it can later change then what it really should be doing is emitting a event to the new Permission api that has a onchange event when you query for one permission. That is built more for detecting at a later state if something was changed to the permission navigator.permission.query({name: 'geolocation'}).then(status => status.onchange = changed)

This would make "Not Now" indistinguishable from "Don't Share", i.e. redundant, so lets just remove it. Minimize is more Bug 1004055, but I'll say that IMHO making minimize the same as dismiss is not the answer. The fact that minimize looks like dismissal is in fact the problem. We're discussing two approaches: 1. Make doorhanger shrink but not disappear entirely on minimize, or 2. Drop minimize. Encouragingly, the UX overhaul in bug 1267607 has no trace of "Not Now".

The new permission prompt design in 53 removes "Not Now".