Closed Bug 675533 Opened 13 years ago Closed 7 years ago

Content permission prompts don't notify content when dismissed (X, Not now, click outside, etc.)

Categories

(Toolkit Graveyard :: Notifications and Alerts, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: other, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: DevAdvocacy)

Attachments

(2 files, 7 obsolete files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0.1) Gecko/20100101 Firefox/5.0.1
Build ID: 20110707182747

Steps to reproduce:

When a user is prompted to share their location and chooses "Now Now", the error callback for navigator.geolocation.getCurrentPosition() does not fire as required in the Geolocation API Spec (http://dev.w3.org/geo/api/spec-source.html):
...If the user denies permission, the errorCallback (if present) must be invoked with code PERMISSION_DENIED"
Very simple test page available here http://dented-planet.net/geotest.html
Component: General → Geolocation
Product: Firefox → Core
QA Contact: general → geolocation
Reproducible for me on latest nightly Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0a1) Gecko/20110802 Firefox/8.0a1
This is by design. Not Now hides the popup but allows you to make a decision at a later time, therefore it invokes no callbacks. Never Share will trigger the error callback.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
While I certainly will not argue the difference between "Now Now" and "No", I would point out the major problem with this approach is that there is absolutely no way to determine (Javascript code-wise) if the user has selected "Not Now".

Case in point, because geolocating can take a considerable amount of time, providing visual feedback to the user (e.g. a spinner) is a must. But without any indication that the user has chosen "Not Now", there is no way to cancel the visual feedback.

A timer wouldn't work because the user might sit there trying to decide whether or not to share his location for the whole length of the timer.
All the issues you describe are already present if the user ignores the notification bar altogether (which is what most users do with it, actually).  So you have to solve them anyway....
That is utter nonsense.

And, if you look at the demo I provide (http://dented-planet.net/geotest.html), other UI events (such as clicking links) are ignored while the "notification bar" (which is now a not very ignorable popup, BTW) is being displayed! They only fire events after notification popup has been dismissed.


But whatever.
I have watched a close friend completely disregard the large black popup and attempt to click a link. When nothing appeared to happen, she clicked it again. This is not an imaginary phenomenon.
> while the "notification bar" (which is now a not very ignorable popup, BTW)

Which goes away (but can be reshown) if you click anywhere outside it, by design.

And the "notification bar" is still a notification bar in at least Chrome and mobile Firefox, where users can and will happily ignore it just like they can ignore the doorhanger by clicking outside it.

So I was serious.  Your code needs to gracefully deal with the user never answering the question...  I know it's a pain, but that's the cost of having UI that doesn't force the user to answer (which basically means anything except a modal dialog).
Status: RESOLVED → VERIFIED
I agree wholeheartedly that this is just poor interpretation of the W3C geolocation spec, for the simple reason that it requires a bit of work to fix.

If I as a web-user deny a website permission to retrieve my position (whether I choose 'not now' or 'until the end of time', the client-side function that requests my geolocation NEEDS to be made aware of this. Simply letting hang in limbo (without a success or failure trigger) is simply ludicrous. I am sure if the Mozilla engineers found themselves developing applications that use the Geolocation functionality, they would realize this and take the 5 minutes required to fix this bug.

The comment that an application needs to gracefully deal with the user never answering the question, is the same as saying a radio should deal with a user never turning it off. If the user chooses not to answer the geolocation question, an app has no reason to have to deal with this - either you answer the question and move on, or you don't. The comment also begs the question: HOW exactly would you deal with this? Setting a 20 minute timeout to the function?
Both "Not now" and dismissing the popup should be treated as a NO by the user and thus invoke the error handler.
That's just common sense.
(In reply to Citro from comment #14)
> Both "Not now" and dismissing the popup should be treated as a NO by the
> user and thus invoke the error handler.
> That's just common sense.

Agreed - this is ridiculous. There are two main cases:
1) User allows location
2) User does not allow location

Case 1) is covered. Great. Case 2) has two sub-cases:
2.1) User denies access (temporarily or forever, doesn't matter; for the web developer, any action that dismisses the dialog box without granting permission is the same as explicitly denying in terms of permissions)
2.2) User has not clicked anything to do with location permissions and the dialog box is just sitting there

2.2) should be handled by a timeout; 2.1) doesn't have to be. A developer can react in Javascript to an 2.1) situation to create a more responsive website than if the site has to wait for a timeout that only needs to catch case 2.2).
We just ran into this issue as well.  Judging by the overwhelming comments in this bug I think you should re-evaluate this bug -- "Not now" should absolutely invoke the error handler.  I'd also recommend voting for this bug if you'd like to see it re-opened so hopefully Mozilla will reconsider it.
Also, I think one of the main points we're trying to make here is that while web developers *do* have to deal with a timeout here (and general non-response by the user), we should be able to quickly react to responses the user does give.  In this case, the user clicking "Not Now" indicates that they don't want to allow access to their location for this request, so firefox should respond that it hasn't granted permission in javascript.

Because the user has taken an explicit action, this behavior is far worse than a timeout resulting from either a user not noticing the dialog, or because the location finding service is taking an extremely long time.
Exactly.  Being able to immediately respond to the user's choice is much better than timing out.

The user is clicking a button, so we should respond!
According to https://developer.mozilla.org/en-US/docs/Web/API/PositionError
this "Not Now" chosen by user, is supposed to fall in the case 1 "PERMISSION DENIED" : "The acquisition of the geolocation information failed because the page didn't have the permission to do it."

See also: http://www.w3.org/TR/geolocation-API/#permission_denied_error

What are the use cases covered by this "PERMISSION DENIED" ?
Last but not least, both msie and chrome work fine.

Best Regards.
I'll sound off just like everyone else. This should fire case 1 "PERMISSION DENIED". Although I completely agree that an application should be built to handle a "no response" case gracefully this isn't a "no response" case. The user is responding by saying they'd prefer to deny permission "for now" to retrieve their geolocation. This is a painfully obvious UX case, and causes developers to have to go through additional hoops and whistles to fix a problem that shouldn't be broken in the first place. Not to mention the debugging and searching that has to be done to figure out why Firefox isn't responding like it rightfully should.

Please fix this.
(In reply to Josh Matthews [:jdm] from comment #3)
> This is by design. Not Now hides the popup but allows you to make a decision
> at a later time, therefore it invokes no callbacks. Never Share will trigger
> the error callback.

This is by design. Really?

This is a bug according to Mozilla's own documentation: "the page didn't have the permission to do it" https://developer.mozilla.org/en-US/docs/Web/API/PositionError - or - there is a bug in the documentation.

Anyway this is a non-compliance according to W3C: http://www.w3.org/TR/geolocation-API/#permission_denied_error "The location acquisition process failed because the document does not have permission to use the Geolocation API."

The question is: "Does the document have permission to use the geolocation API"? The reply is either positive or negative (as far as I can see, there's no room for maybe). Therefore, if the reply is negative - by the way, "not now" and "never" are negative values - then a permission-denied must be returned.

We are waiting for 3 years now: PERMISSION ALLOWED to fix this.
:)

After the letter, the spirit: "Doing Good is Part of Our Code", Mozilla affirms.
Yes, by design. When I said "later time", I meant in the same session on the same page - the user can click the geolocation button in the URL bar to reopen the permission dialog after clicking Not Now and grant access.
Which should be considered a secondary request and handled as appropriate. Doesn't change the fact that the initial request should be considered a PERMISSION DENIED. Just because it's "as designed" doesn't constitute it as correct, the amount of complaints in this ticket alone about this should be a heavy indicator that the design intentions were not consistent with how the community feels it should function.
(In reply to Josh Matthews [:jdm] from comment #22)
> Yes, by design. When I said "later time", I meant in the same session on the
> same page - the user can click the geolocation button in the URL bar to
> reopen the permission dialog after clicking Not Now and grant access.

Dear jdm,
This has nothing to do with user ; this is about document!

> The question is: "Does the document have permission to use the geolocation 
> API"? The reply is either positive or negative (as far as I can see, there's 
> no room for maybe). Therefore, if the reply is negative - by the way, 
> "not now" and "never" are negative values - then a permission-denied must be 
> returned.

Any way, "your" design is not compliant with documentations: Mozilla, and W3C as well. RTFM.
> The question is: "Does the document have permission to use the geolocation API"? The reply is 
> either positive or negative (as far as I can see, there's no room for maybe). Therefore, if 
> the reply is negative - by the way, "not now" and "never" are negative values - then a 
> permission-denied must be returned.
> 
> We are waiting for 3 years now: PERMISSION ALLOWED to fix this.

Currently "not now" basically doesn't change the starting condition of the page: while the dialog is showing, the page is running underneath it, with permissions neither granted nor revoked. It's only if the user changes this situation, with a positive or negative response, that an event fires.

The two options I see are:
1) Change the location permission dialog to block processing, appearing modally before the page displays, so the page always knows up front if it has permission or not, or
2) Build your page to work without the permission, and react appropriately if and when it is granted
(In reply to robertlagrant from comment #25)
> The two options I see are:
> 1) Change the location permission dialog to block processing, appearing
> modally before the page displays, so the page always knows up front if it
> has permission or not, or
> 2) Build your page to work without the permission, and react appropriately
> if and when it is granted

The only option I see is:
o Read the f... manuals,
o Change the code to return a "PERMISSION DENIED" status in accordance with the manuals - or explain why this is technically infeasible in which case think of removing this 'Not now' option that comes from nowhere.
Can we please keep a respectful tone here -- I want to see what I (and many of us) view as a bug fixed.  I don't think being belligerent to the people we want to fix this is going to help.

To that end, let's look at a simple use case, and how a web developer can react:

1. A user on the page clicks a "Find stores" button on the page
2. This brings up a dialog/page that:
  a. Requests the users location using navigator.geolocation.getCurrentPosition()
  b. Sets a loading messaging to the effect of "Trying to find stores near you -- you'll need to grant us permission."
  c. Also has a search box for manual searches

There are a number of scenarios the user might encounter:

s1: If the user selects "Share location" or "Always share location" (or had already selected that previously) we can proceed with displaying stores near the user.
s2: If the user selects "Never share location" or had previously, the callback fires with permission denied, so we can update the message to something like "enter a city/region/country/postal code to find stores near you" depending on what the search box can handle.
s3: If the user selects a manual search, we want to ignore the result of the "find location" call to the browser so we can call the navigator.geolocation.clearWatch() method (or just ignore the result).

More relevant to the bug:

s4: If the user selects "not now", no callback fires, so we can't react.  As web developers we have no idea whether or not the browser "share location" UI is still showing.
s5: If a user selects "not now", then clicks the geolocation icon in the url bar, then selects "Share location", the search proceeds.  In practice I think *very* few people will actually do this, and I could see some users being pleasantly surprised, and others being a little freaked out about results coming back (especially if they waited for some time).
s6: Assuming we're in a dialog, If the user selects "not now", then closes the dialog, and re-opens it, the user is again presented with the browser share location options.

If instead "now now" was treated as the user saying "don't grant access to this request, but ask me again if there are future requests", then we can treat s4 just like s3. For users that have taken the explicit action of selecting "not now", we can update our wording to give further instructions on the manual search.  In my view, and in the view of many of the other people here this would be *vastly* preferable.  Given the discussion here I think you're seeing pretty good evidence that the current s4 behavior is not desired.

But then what to do with s5?  If we change the way "not now" is handled, selecting "share location" shouldn't fire the callback to the original search, so it'd effectively do nothing.  Here's where I believe there's another problem, and I think it's what's making it technically difficult to resolve this bug.

Currently Firefox is treating the "Share location" and "Not now" as responses to the current getLocation() request.  One option would be to keep that behavior, but only show the "always allow" and "always deny" options if the user clicks the geolocation icon in the url bar.  Another option would be to treat the "Share location" and "not now" options as relevant to all requests made in the current page view.  This would change the behavior of s5 so that both the first and second launch of the dialog would send the "permission denied" callback (with the user only responding on the first launch).  The user could see the firefox options again by either reloading the page, or by changing their selection by clicking the icon in the url bar.

The following text from the W3C documentation also seems relevant.  There's no discussion of the user "delaying" giving permission, and I think a whole lot of us are viewing the "not now" option as the user "denying" permission to this call.

"If the user grants permission, the appropriate callback must be invoked as described above. If the user denies permission, the errorCallback (if present) must be invoked with code PERMISSION_DENIED, irrespective of any other errors encountered in the above steps. The time that is spent obtaining the user permission must not be included in the period covered by the timeout attribute of the PositionOptions parameter. The timeout attribute must only apply to the location acquisition operation."
Ok, I get it. user can allow, deny, or choose to decide later.

But it would be great if we could have any sort of an event to deal with the "Not Now" senario rather than staying dump. At least to show a default location in a google map.
Or you could change the behavior of "Not Now" to (a) send PERMISSION_DENIED, and (b) if the page re-requests permission, show the permission options to the user again.  If the semantics trip you up, the wording could be changed to "Not this time".

This would be less confusing, and more in the spirit of what the standard currently specifies.  Firefox is currently the "special case" browser here, which is probably why there's so much traffic on this bug.
@Alex the reason some users sound a tad aggressive is because FireFox developers are forcibly imposing this crazy behavior on their web pages. I could try to sound convincing here but there is not point in doing that now. This is bug is 3 years old and should be marked as wont-fix.
So its been 3 years and still in FF to-do list and still thinking? This "Not Now" is such a big problem for web-developers when they are trying to implement good design flow. No error response hammers up the whole design.
How do Chrome, IE, and iOS Safari handle this situation? If someone can provide a test case and show that other browsers provide a consistent, alternate interpretation of the W3C geolocation spec, then that would be a strong argument for changing Firefox.
@chris please note that this issue is now marked and "VERIFY WONTFIX". Unless you are "the" man to convince to change FF behavior I don't think it proper to offer hope on the sufferers.
@chris fwiw, compare using the "x" on the Chrome location toolbar to using "Not Now" in firefox: http://jsfiddle.net/s1hkjzsq/2/ -- in Chrome's case the error callback fires, and the "x" serves basically the same purpose. Hope you can help get some attention here.
Thanks, Alex.

Chrome and Safari (OS X) use persistent permission prompts that, unlike Firefox's door hanger, are not implicitly dismissed when clicking the page or switching tabs. So neither Chrome nor Safari have the indeterminate state of where the permission prompt has been dismissed but the user did not expressly grant or deny permission.

Firefox's design has the unfortunately side effect that clicking the "Learn more ..." link on the "Would you like to share your location?" door hanger opens a new tab (with a geolocation FAQ), which dismisses the door hanger. When the user closes the FAQ tab and switches back to the geolocating website, the door hanger is gone.
At least you could fire timeout event. But no timeout event happens.
How do my application knoy if it got location at all?
According to W3C (http://dev.w3.org/geo/api/spec-source.html#geolocation_interface) I expect: 
"The getCurrentPosition() method takes one, two or three arguments. When called, it must immediately return and then asynchronously attempt to obtain the current location of the device. If the attempt is successful, the successCallback must be invoked (i.e. the handleEvent operation must be called on the callback object) with a new Position object, reflecting the current location of the device. If the attempt fails, the errorCallback must be invoked with a new PositionError object, reflecting the reason for the failure."

So attempt is the one witch getCurrentPosition() makesto get the location. As written it MUST ... attempt.
And then we see if attempt FAIED errorCallback MUST be invoked with a new PositionError object

According to Ditcionary (http://www.oxforddictionaries.com/definition/english/fail) Fail: "Be unsuccessful in achieving one’s goal", "Neglect to do something"...

So when user presses "Not now" the getCurrentPosition() method IS unsuccessful in achieving it's goal (getting location). so it MUST fire PositionError event.

That what is the spec.
Reopening while we reevaluate this.
Status: VERIFIED → REOPENED
Ever confirmed: true
Resolution: WONTFIX → ---
:garvank and I will evaluate what the appropriate thing to fire here is - and update the Geolocation spec if appropriate/needed.
Note that this issue is broader than just geolocation -- basically ALL of Firefox's permission prompts work this way. The reasons for that are not immutable or set in stone, but I do think it's important to have the various prompts work consistently.

/cc Madhava since I think this is on UX's radar.
:Dolske I think that you are wrong. This isn't a broader issue since all we are asking is that you execute the error callback when a user chooses the infamous "Not Now" state. Nobody here is expecting you to change the UI etc.
The point is that other APIs have exactly the same issue (for example, the permission prompt for sharing a microphone/camera). If we should decide to make "Not Now" handled as an error, that should be true of all prompts. Having things work inconsistently is bad for users and developers alike.

Also, this _would_ be a UI change. Once the browser determines to report an error for the request, it can't later report success instead. So after clicking "Not Now" the prompt couldn't be reopened, because the failure has already been reported and it's too late for the user to make an explicit choice. That's a change we can decide to make, but again it should be a consistent experience across the various permission prompts.
:Dolske well in that case this is a bigger bug (broader issue as you said) that I could envisage. Yet, one that FF should address. For example this UI functionality of letting the use "decide later" it is present in other browser also but in a more consistent manner (I would argue). Choosing "Not Now" is a decision! (would you not agree?) So why isn't the web page told that a decision was made? This is definitely a flaw I am afraid. I think that :marosc is right in investigate this issue and if it is a broader issue well that what it is.
(In reply to Justin Dolske [:Dolske] from comment #43)
> The point is that other APIs have exactly the same issue (for example, the
> permission prompt for sharing a microphone/camera). If we should decide to
> make "Not Now" handled as an error, that should be true of all prompts.
> Having things work inconsistently is bad for users and developers alike.

Lets imagine we *did* get these API specs modified to have a "user is delaying choice" state, I argue developers would map this to perform the same action as the "permission denied".

Chrome clearly gets this right in combining non-modal behaviour with requiring an explicit choice to dismiss the question posed. Safari takes the fully modal approach. 

Personally, I like the UI (and comment 7 and comment 35 indicate some of the benefits), but this indeterminate state is a problem that developers shouldn't have to special-case for Firefox. 
 
> Also, this _would_ be a UI change. Once the browser determines to report an
> error for the request, it can't later report success instead. 

Why not? Not being facetious, I am just curious if anyone knows that this is not permissible. If we are allowed to do this, we can solve the problem (except for comment 35, have to solve that). Would it would break web pages that aren't expecting both an error and success callback without reload?
First of All Thank you for reopening this topic I really appreciate this - I even made a fb post about how much I do love Firefox Team after this.

I've got a few arguments here and a decision I wanna share with you:
So, here are the arguments for take a serious look on this issue:

1) Votes in comparison with average votes per issue.
2) Developers. Reorientation back to developers is very good, but it means not only giving them tools to develop, but also hear what they need.
3) Specs as in comment #37. And I think specs is the most important reason.
4) And the last but not least is UX. I mean why do developers need location, camera access or something else: to provide user with something they need, and to do so as soon as possible, for example we are using location to show nearby places of interest to User. Say someone is making WebRTC chat (I like and use already Hello myself) for video conferencing, until user agreed to share camera info the chat can not start conference, what should the application show to user to enplane it? Application can not even react somehow because it has no event to monitor, that user maybe by mistake pressed not now. And I did not knew at all that I could share my location after it by pressing small icon in URL bar after I pressed "not now", I doubt that all users know and use it. Smooth and easy user experience is as important as privacy and security.

So I suggest to find a compromise somehow. A compromise between the user-friendly experience orientation and privacy and security.
Chrome is investigating using the Firefox-style permissions bubble:
http://www.ghacks.net/2014/02/12/chrome-switch-permission-infobars-bubbles

I wonder if they follow the model that _any_ action other than acceptance the fires the error callback.
:garvank the stable (Version 39.0.2171.71) Chrome fires error callback right at the moment you close alert.

When I enabled those experimental "permissions bubbles", and closed one instead of choosing Allow or Deny, it stuck, and even gave me no ability to reopen this bubble dialog, so I consider it is undocumented behavior due to unfinished realization.

They write: "Please note that this is an experimental feature right now which means that you may experience issues when you enable the feature right now."
So that's not the feature to compare to, it's experimental and there is no developers/users feedback on it at all.
(In reply to Alex Art from comment #48)
> :garvank the stable (Version 39.0.2171.71) Chrome fires error callback right
> at the moment you close alert.
>
> So that's not the feature to compare to, it's experimental and there is no
> developers/users feedback on it at all.

I'll ping the folks at Google to see how they intend to handle this. Will write back here soon.
Just a heads up that we (Moz and Google) are working on a new API for API permissioning that might help with this (and other) use cases. 

https://github.com/w3c/permissions

In particular, I've asked that a "dismissed" state be added to that API to cover the use case/situation discussed here. So, even if you don't get an error callback, you would get a dismissed event and you could check if it had previously been dismissed before prompting (you can even check if it's been dismissed/denied previously). I also understand that that is a bit annoying, because it means doing some indirect checks.
See: https://github.com/w3c/permissions/issues/4

Nevertheless, this new API should allow people to develop complete solutions to cope with all the different prompting situations and dismissals in a way that remains backwards compatible. We would love your feedback on this new API! You can also track implementation of that API in bug #1105827.

Having said that, we might still fix this because it seems to violate the Geo spec.
+1 to having this fixed!  Just ran into this issue and most other browsers manage to handle the 'Not Now' case gracefully, calling the error callback.  Firefox is the only outlier in their interpretation of the Geo spec.  The codes in the PositionError object specify a "PERMISSION_DENIED" code, and the spec includes the language "If the user denies permission, the errorCallback (if present) must be invoked with code PERMISSION_DENIED, irrespective of any other errors encountered in the above steps."
"Not now", should DENY the permission (that's why there is a "not" in there).
THEN, eventually, the browser should adapt its UI to make it easier to re-enable it.

There is no place for a "maybe later" state.
De Niro said: "Whenever there is any doubt, there is no doubt".


PS: Can't wait to celebrate the 4th anniversary of this issue.
Agree with Byron above.  I also just ran into this while testing with Firefox. Current implementation is to prompt the user for feedback (Not Now) and then ignore it.
So yeah, this could get fixed any time and Web apps would work properly.
Just a quick note that we haven't forgotten about this. As I mentioned previously, we are working on an alternative API to fix this not only for geo, but for all device APIs:

https://w3c.github.io/permissions/

FWIW, it's still our intention to fix this. Garvan has been looking into where exactly the error callback is not being called (it's a bit of a tangled mess apparently). We've set aside next Friday to attempt to put a patch together. If people on this bug want to help with the investigation, then please take a look also and throw up some strawperson proposals.
Assignee: nobody → mcaceres
First stab at fixing this.
Flags: needinfo?(ehsan)
Attachment #8591123 - Flags: review?(josh)
Had forgotten to hit save on the "geolocation_dismiss.html" file ^_^.
Attachment #8591123 - Attachment is obsolete: true
Attachment #8591123 - Flags: review?(josh)
Attachment #8591123 - Flags: review?(josh)
Attachment #8591130 - Flags: review?(josh)
Attachment #8591123 - Flags: review?(josh)
argh, bugzilla, y u so confusing. I think that's right now.
The patch here seems to be missing non-test changes.
Marcos: the patch needs the changes to nsBrowserGlue.js _promptGeo() -the added options block.
(you just missed a git add)
Either this bug is cursed, or I shouldn't rush patches at the last minute on a Friday night ... I'm going to go with "it's cursed" :)

Sent to try again: 
https://treeherder.mozilla.org/#/jobs?repo=try&revision=ef654facef50

In this new patch, I removed the HTML file as it was not needed (just loading 'http://example.com' instead). 

Hopefully all good now.
Attachment #8591130 - Attachment is obsolete: true
Attachment #8591130 - Flags: review?(josh)
Attachment #8591754 - Flags: review?(josh)
Marcos, do you recall what happens in this case:
- page requests getCurrentPosition()
- dismiss the notification without making a choice (which now returns an geolocation error) and then,
- re-opening the notification and allowing permission 

This is the only series of actions that I think might cause confusion at this point with developers.
Note that Safari and Chrome, don't have the problem of a dismissed dialog state. They both require a button choice is made for the notification to disappear.
Flags: needinfo?(mcaceres)
> Marcos, do you recall what happens in this case:
> - page requests getCurrentPosition()
> - dismiss the notification without making a choice (which now returns an geolocation error) and then,
> - re-opening the notification and allowing permission 

Should work as expected (notification reopens).Would be trivial to add a test. Want me to add? 

> This is the only series of actions that I think might cause confusion at this point with developers.
Note that Safari and Chrome, don't have the problem of a dismissed dialog state. They both require a button choice is made for the notification to disappear.

Correct. That's a issue with our UI. We should fix that in a different bug. Let's just aim for parity with Chrome here.
Flags: needinfo?(mcaceres)
(In reply to Marcos Caceres [:marcosc] from comment #66)
> > Marcos, do you recall what happens in this case:
> > - page requests getCurrentPosition()
> > - dismiss the notification without making a choice (which now returns an geolocation error) and then,
> > - re-opening the notification and allowing permission 
> 
> Should work as expected (notification reopens).

I mean, after first dismissing the notification, the user clicked to show the notification again, then clicked the button to share location.

I just checked using your patch, this does work. 

> Would be trivial to add a test. Want me to add? 

Yes, because this behavior is a little fragile IMHO. Internally, in C++ land, we have a geolocation request object, whose lifetime is tied to the duration that the getCurrentPosition() is pending. I'll have to check the code, but it seems that this object lifetime is from _after_ the permission prompt returns until a success or error callback is made. Details aside, the way the code is now is good for this patch. This object lifetime could get changed in future without the developer realizing the implications on this specific case.
(In reply to Garvan Keeley [:garvank] from comment #67)

> Yes, because this behavior is a little fragile IMHO. Internally, in C++
> land, we have a geolocation request object, whose lifetime is tied to the
> duration that the getCurrentPosition() is pending. I'll have to check the
> code, but it seems that this object lifetime is from _after_ the permission
> prompt returns until a success or error callback is made.

Again (see comment 43), these doorhangers are part of a common UI, and having geolocation work differently leads to confusing UX. We can choose to make dismissal equivalent to cancellation (ie, report an error) across the board, but I don't think we can currently make them report an error _and_ be recallable. At least, doing so would mean auditing other prompts to make sure they work and are still spec compliant.
(In reply to Justin Dolske [:Dolske] from comment #68)
> (In reply to Garvan Keeley [:garvank] from comment #67)
> 
> > Yes, because this behavior is a little fragile IMHO. Internally, in C++
> > land, we have a geolocation request object, whose lifetime is tied to the
> > duration that the getCurrentPosition() is pending. I'll have to check the
> > code, but it seems that this object lifetime is from _after_ the permission
> > prompt returns until a success or error callback is made.
> 
> Again (see comment 43), these doorhangers are part of a common UI, and
> having geolocation work differently leads to confusing UX.

We are not changing the behavior at the UX level, only at the API level. 

Hence, it's more confusing for users of actual websites because the site is stuck waiting for an error callback that never arrives (which equals all the frustration developers are voicing in this bug, as it means their websites don't work the same in Firefox as they do in other browsers). 

> We can choose to
> make dismissal equivalent to cancellation (ie, report an error) across the
> board, but I don't think we can currently make them report an error _and_ be
> recallable. At least, doing so would mean auditing other prompts to make
> sure they work and are still spec compliant.

The proposed patch makes this spec compliant (as much as it can be, given that the Geospec doesn't deal with a dismissed prompt). I agree that fixing the rest of the prompts in Firefox is a larger project, as the current approach is clearly not correct: switching tabs shouldn't dismiss a prompt, which is a serious bug in our UX, and definitely not a feature! - and certainly not something we should be punishing developers for by denying them the error callback. I also don't see a problem with doing this incrementally across Firefox - if we say we are going to fix this across all prompts in Firefox, then it's likely we will be waiting a long time for a fix.
Attachment #8591754 - Attachment is obsolete: true
Attachment #8591754 - Flags: review?(josh)
Attachment #8593069 - Flags: review?(josh)
Garvan, I added the test you requested in comment #66 in attachment #8593069 [details] [diff] [review]. Can you take a look if I understood your request correctly?
Flags: needinfo?(gkeeley)
Fixed a few typos + converted to HG patch.
Attachment #8593069 - Attachment is obsolete: true
Attachment #8593069 - Flags: review?(josh)
Attachment #8593077 - Flags: review?(josh)
(In reply to Marcos Caceres [:marcosc] from comment #71)
> Garvan, I added the test you requested in comment #66 in attachment #8593069 [details] [diff] [review]
> [details] [diff] [review]. Can you take a look if I understood your request
> correctly?

You added a useful test, but not the case I am concerned about breaking.

Steps would be:
1. show geo notification and then dismiss it.
2. verify error was called
3. show the popup again, click the button to accept
4. verify success was called
Flags: needinfo?(gkeeley)
Comment on attachment 8593077 [details] [diff] [review]
0001-Bug-675533-Share-location-Not-Now-Doesn-t-fire-error.patch

Review of attachment 8593077 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/tests/mochitest/geolocation/browser_dismiss_permission.js
@@ +26,5 @@
> +  });
> +});
> +
> +// This makes geolocation:
> +//  1. show its notification and then dimisses it.

dismisses

::: dom/tests/moz.build
@@ +32,5 @@
>      'mochitest/whatwg/mochitest.ini',
>  ]
>  
> +
> +

remove ws change
(In reply to Justin Dolske [:Dolske] from comment #68)
> Again (see comment 43), these doorhangers are part of a common UI, and
> having geolocation work differently leads to confusing UX. We can choose to
> make dismissal equivalent to cancellation (ie, report an error) across the
> board, but I don't think we can currently make them report an error _and_ be
> recallable. At least, doing so would mean auditing other prompts to make
> sure they work and are still spec compliant.

We should ensure the camera and microphone popups get bugs filed for them. They likely have the same bug as this.
(In reply to Garvan Keeley [:garvank] from comment #73)
> 3. show the popup again, click the button to accept

I should have said, show the popup again without calling getCurrentPosition(), as if the user clicked to re-show it.
See Also: → 1155229
(In reply to Garvan Keeley [:garvank] from comment #76)
> (In reply to Garvan Keeley [:garvank] from comment #73)
> > 3. show the popup again, click the button to accept
> 
> I should have said, show the popup again without calling
> getCurrentPosition(), as if the user clicked to re-show it.

ok, got it. Will write another test.
(In reply to Marcos Caceres [:marcosc] from comment #77)
> (In reply to Garvan Keeley [:garvank] from comment #76)
> > (In reply to Garvan Keeley [:garvank] from comment #73)
> > > 3. show the popup again, click the button to accept
> > 
> > I should have said, show the popup again without calling
> > getCurrentPosition(), as if the user clicked to re-show it.
> 
> ok, got it. Will write another test.

Ok, did some investigating. When it comes to .watchPosition() Chrome also doesn't support what you are describing (user initiated resuming). When you try to do that, you get a door hanger that says:

"New site permission settings will take effect after reloading the page <button>reload</button>". 

UX aside, the API behavior at the moment matches Chrome: i.e., if you deny or dismiss permission on a watchPosition(), then the user can't recover from that without reloading the page.

I think this behavior is ok. WDYT? 

## Chrome + getCurrentPosition(): 
When it comes to getCurrentPosition(), if you "accept", then manually "deny", you get the door-hanger above BUT getCurrentPosition() continues to work (this is bad on their part, IMO - we should not do this! reloading the page might mean loss of data, etc.). 

## Patched ff + getCurrentPosition()
if you "accept", then manually "deny" or dismiss, Firefox then denies the request. You can then re-enable it and it just works. I think that is the right behavior.

WDYT?
(In reply to Marcos Caceres [:marcosc] from comment #78)
> Ok, did some investigating. When it comes to .watchPosition() Chrome also
> doesn't support what you are describing (user initiated resuming). When you
> try to do that, you get a door hanger that says:
> 
> "New site permission settings will take effect after reloading the page
> <button>reload</button>". 
> 
> UX aside, the API behavior at the moment matches Chrome: i.e., if you deny
> or dismiss permission on a watchPosition(), then the user can't recover from
> that without reloading the page.

So, it doesn't resume a dead* watchPosition(), but if you call it watchPosition() again, it starts working. This is good, because it obviously makes getCurrentPosition() and watchPosition() work the same.  

*dead: a watchPosition() that got denied at some point.
Added two additional tests based on Garvan's description: one for getCurrentPosition() and one for watchPosition(). 

Garvan, can you check if they are ok, then I can bug JDM again for review. Let me know if there are more we should add.
Attachment #8593077 - Attachment is obsolete: true
Attachment #8593077 - Flags: review?(josh)
Attachment #8593570 - Flags: feedback?(gkeeley)
Thanks for researching the watchPosition() case. I think is is hard to say what is right exactly when we are band-aiding a notification UI that doesn't jibe with the W3C spec. Fixing the UI would be the right step, but years are ticking by and this doesn't seem to be on the roadmap, so, continuing with the bandaid...

We have questions of :
- Should a single getCurrentPosition() potentially get an error callback followed by a success callback? Will this create new problems for developers who aren't expecting that sequence of events?
- Should a single watchPosition() call behave the same?
- If the above 2 didn't happen, instead, is it a bug that a user could click off the dialog causing it to dismiss, then re-show the dialog and click to "Share Location", and have nothing happen? 

Moreover, if UX team is adamant that the current UI is the correct approach, then we need W3C spec changes ASAP to properly support an error code on the callback for the permission request being dismissed with no choice being made.
(In reply to Garvan Keeley [:garvank] from comment #81)
> We have questions of :
> - Should a single getCurrentPosition() potentially get an error callback
> followed by a success callback?

No. IIUC, getCurrentPosition() is a 1 shot call. Thus, manually enabling geolocation after it has returned won't ever do anything. 

> Will this create new problems for developers who aren't expecting that sequence of events?

This won't ever happen. That would be a violation of the spec. 

> - Should a single watchPosition() call behave the same?

Yes. 

> - If the above 2 didn't happen, instead, is it a bug that a user could click
> off the dialog causing it to dismiss, then re-show the dialog and click to
> "Share Location", and have nothing happen? 

That's for the developer to deal with. Once they get the error callback, they can provide a button to "try to request location again".

> Moreover, if UX team is adamant that the current UI is the correct approach,
> then we need W3C spec changes ASAP to properly support an error code on the
> callback for the permission request being dismissed with no choice being
> made.

We can make those changes in the Permissions API (I co-edit that one) to detect dismissed. However, changing Geo API now seems pretty unlikely given how long it's been out.
After some further chat with Marcos, here is what I learned, 
1) the current patch does not change the behaviour of the permission notification recallable from its collapsed (anchored) state. 
2) after recalling the dialog and the user clicking to always share location, it does not recall the getCurrentPosition/watchPosition.

I agree this is correct API behaviour. The UX is a bit strange of not having a clear action after having clicked the button, but this bug is concerned with correct API behaviour. Now that I am straight on that, I'll look at the patch and test cases again...
Comment on attachment 8593570 [details] [diff] [review]
0001-Bug-675533-Share-location-Not-Now-Doesn-t-fire-error.patch

Review of attachment 8593570 [details] [diff] [review]:
-----------------------------------------------------------------

This test is placed as a browser test in dom/tests/mochitest/geolocation. IIRC browser mochitests vs plain mochitests are in separate directories. 
I prefer what you have here though, as I don't see sufficient distinction between browser/plain that this is needed, and I prefer to see these tests together under a single directory.
I'll leave that for your final reviewer to clarify.

Even though some of these tests were triggered by my confused comments earlier, I think they are all valid and worth keeping as they make the behaviour clear, and defend against future breakage.

::: dom/tests/mochitest/geolocation/browser_dismiss_permission.js
@@ +27,5 @@
> +
> +// This tests uses getCurrentLocation:
> +// 1. Shows geo notification, but then dismiss it.
> +// 2. Verifies error callback was called.
> +// 3. Show the notification again without using geolocaiton API,

spelling

@@ +39,5 @@
> +    function*(browser) {
> +      const geo = browser.contentWindow.navigator.geolocation;
> +
> +      // 1. shows geo notification, but then dismiss it.
> +      yield new Promise((resolve, reject) => {

can this be a utility function like,
showGeoNotification(geo.getCurrentPosition, reject, resolve)

@@ +49,5 @@
> +        // 2. verifies error callback was called (by calling resolve)
> +        geo.getCurrentPosition(reject, resolve);
> +      });
> +
> +      // 3. show the notification again without using geolocaiton API,

spelling

@@ +51,5 @@
> +      });
> +
> +      // 3. show the notification again without using geolocaiton API,
> +      //    as if the user clicked to re-show it.
> +      yield new Promise((resolve) => {

utility function here: fakeClickToReshowPopup()

@@ +80,5 @@
> +
> +// This tests uses watchPosition:
> +// 1. Shows geo notification, but then dismiss it.
> +// 2. Verifies error callback was called.
> +// 3. Show the notification again without using geolocaiton API,

spelling

@@ +144,5 @@
> +  yield BrowserTestUtils.withNewTab({
> +    gBrowser: gBrowser,
> +    url: 'http://test:80/'
> +  }, function*(browser) {
> +    // Alias geoloction

spelling

@@ +161,5 @@
> +      PopupNotifications.panel.addEventListener('popupshown', secondPopupShow);
> +    };
> +    PopupNotifications.panel.addEventListener('popupshown', firstPopupShown);
> +
> +    // Ask to access goelocation for first time.

spelling

::: dom/tests/moz.build
@@ +32,5 @@
>      'mochitest/whatwg/mochitest.ini',
>  ]
>  
> +
> +

remove ws change
Attachment #8593570 - Flags: feedback?(gkeeley) → feedback+
Ok, cleaned up a bit... let's see how we go. 

Garvan (or anyone else interested), I'm out of town until this Wednesday so please feel free to address any feedback from jdm. Otherwise, will address any feedback this coming Friday.
Attachment #8593570 - Attachment is obsolete: true
Attachment #8594288 - Flags: review?(josh)
@jdm, friendly ping. If you are too busy, please let us know and we can bounce this to someone else.
Flags: needinfo?(josh)
Comment on attachment 8594288 [details] [diff] [review]
Fixed typos, cleaned code a bit based on Garvan's suggestions.

Review of attachment 8594288 [details] [diff] [review]:
-----------------------------------------------------------------

Sorry for taking so long to reply; I don't think I'm the right person to review this the actual browser modifications, unfortunately.

::: dom/tests/mochitest/geolocation/browser_dismiss_permission.js
@@ +41,5 @@
> +      panel.removeEventListener('popupshown', popupShown);
> +      dismissNotification();
> +    });
> +    yield new Promise((resolve) => {
> +      geo.getCurrentPosition(noop, (err) => {

Seems like the success callback should be a test failure here.

@@ +49,5 @@
> +    });
> +  });
> +});
> +
> +// This tests uses getCurrentLocation:

getCurrentPosition?

@@ +54,5 @@
> +// 1. Shows geo notification, but then dismiss it.
> +// 2. Verifies error callback was called.
> +// 3. Show the notification again without using geolocation API,
> +//    as if the user clicked to re-show it.
> +// 4. Try getCurrentLocation() again, verify success was called.

getCurrentPosition?

@@ +131,5 @@
> +        let id = geo.watchPosition(() => {
> +          ok(true, 'Expected a position because user re-enabled geolocation');
> +          navigator.geolocation.clearWatch(id);
> +          resolve();
> +        });

Reject if error?

@@ +157,5 @@
> +      panel.addEventListener('popupshown', function popupShown() {
> +        panel.removeEventListener('popupshown', popupShown);
> +        dismissNotification();
> +      });
> +      geo.getCurrentPosition(noop, resolve);

Shouldn't this be a rejection if the success callback occurs?

@@ +168,5 @@
> +      });
> +      geo.getCurrentPosition(() => {
> +        ok(true, expected);
> +        resolve();
> +      });

Reject if error?
Attachment #8594288 - Flags: review?(josh) → feedback+
Doug, are you the right person to review this?
Attachment #8594288 - Attachment is obsolete: true
Flags: needinfo?(josh)
Attachment #8599546 - Flags: review?(dougt)
Try: 
ttps://treeherder.mozilla.org/#/jobs?repo=try&revision=1252a3ac95d7
Comment on attachment 8599546 [details] [diff] [review]
Fixed typos and rejections, as per jdm's suggestions

Review of attachment 8599546 [details] [diff] [review]:
-----------------------------------------------------------------

jdm just about did the review, so let him finish it. r+ on the general approach.
Attachment #8599546 - Flags: review?(dougt) → review?(josh)
Doug's question: how compliant is this with other browsers? 
Two part answer:
1) No other browser has a dismissed-popup-without-making-a-choice state, we are band-aiding to remove this state. By that thinking it is more compliant with other browsers.

2) Chrome beta now uses a nearly identical UI element to firefox (I think that is a compliment!) but the popup only disappears when the user has made a choice. This is the _best_ UI for this IMHO.
Bug 1155229 describes this.
The patch in this bug is still needed for bug 1155229.
Blocks: 1155229
See Also: 1155229
I really don't know much about the actual frontend dialog code; that's why I think one of the Firefox peers should be signing off on that change.
Comment on attachment 8599546 [details] [diff] [review]
Fixed typos and rejections, as per jdm's suggestions

Doug asked me to look at this…

(In reply to Garvan Keeley [:garvank] from comment #81)
> We have questions of :
> - Should a single getCurrentPosition() potentially get an error callback
> followed by a success callback? Will this create new problems for developers
> who aren't expecting that sequence of events?
> - Should a single watchPosition() call behave the same?
> - If the above 2 didn't happen, instead, is it a bug that a user could click
> off the dialog causing it to dismiss, then re-show the dialog and click to
> "Share Location", and have nothing happen? 

Yes, it's unacceptable to have a button in the UI which is useless. It seems like both getCurrentPosition and watchPosition both get called again after an initial dismissal with this patch though. Is that sometimes not the case? Does it have to do with whether the function is still alive?

> Moreover, if UX team is adamant that the current UI is the correct approach,
> then we need W3C spec changes ASAP to properly support an error code on the
> callback for the permission request being dismissed with no choice being
> made.

I think the current UX is still preferred as it doesn't force users to make a decision until they need to and IMO it's an advantage over the competitors.

I wonder if this change will lead to more annoyance for users as sites will interpret dismissals and denying permission rather than delaying the decision and put up annoying, possibly modal, UI just because a user clicked on something else on the page.

I haven't heard a good reason why web pages can just go down the denied route by default until the permission is granted. Progressive enhancement is what developers had to do before the geolocation API was ubiquitous. What are cases where an immediate decision is absolutely necessary and deserves forcing users to drop everything and decide?

I agree with dolske that we should be consistent across APIs so I don't think this should land piecemeal. Btw. the list of Firefox reviewers can be found at https://wiki.mozilla.org/Modules/Firefox
Attachment #8599546 - Flags: feedback-
(In reply to Matthew N. [:MattN] from comment #93)
> Comment on attachment 8599546 [details] [diff] [review]
> Fixed typos and rejections, as per jdm's suggestions
> 
> Doug asked me to look at this…
> 
> (In reply to Garvan Keeley [:garvank] from comment #81)
> > We have questions of :
> > - Should a single getCurrentPosition() potentially get an error callback
> > followed by a success callback? Will this create new problems for developers
> > who aren't expecting that sequence of events?
> > - Should a single watchPosition() call behave the same?
> > - If the above 2 didn't happen, instead, is it a bug that a user could click
> > off the dialog causing it to dismiss, then re-show the dialog and click to
> > "Share Location", and have nothing happen? 
> 
> Yes, it's unacceptable to have a button in the UI which is useless. It seems
> like both getCurrentPosition and watchPosition both get called again after
> an initial dismissal with this patch though. Is that sometimes not the case?
> Does it have to do with whether the function is still alive?

The function is not alive. But dismissal does not equal deny. 
 
> > Moreover, if UX team is adamant that the current UI is the correct approach,
> > then we need W3C spec changes ASAP to properly support an error code on the
> > callback for the permission request being dismissed with no choice being
> > made.
> 
> I think the current UX is still preferred as it doesn't force users to make
> a decision until they need to and IMO it's an advantage over the competitors.

This is only true if the API changes proposed here are accepted. The UX is hardly "advantage over the competitors" in it's currently broken form: if you accidentally switch apps or switch tabs, the user loses the ability to make a choice. That's extremely poor and misguided UX... it also punishes developers, because they can't get a sense of what is going on and recover. They are left waiting for a call back that never arrives, so their only recourse is hurling abuse at us on this bug because of it. 

> I wonder if this change will lead to more annoyance for users as sites will
> interpret dismissals and denying permission rather than delaying the
> decision and put up annoying, possibly modal, UI just because a user clicked
> on something else on the page.

I'm working on a separate API to address that:
https://w3c.github.io/permissions/

> I haven't heard a good reason why web pages can just go down the denied
> route by default until the permission is granted. Progressive enhancement is
> what developers had to do before the geolocation API was ubiquitous. What
> are cases where an immediate decision is absolutely necessary and deserves
> forcing users to drop everything and decide?

Cross browser compatibility and consistent cross-browser behavior. 
 
> I agree with dolske that we should be consistent across APIs so I don't
> think this should land piecemeal. Btw. the list of Firefox reviewers can be
> found at https://wiki.mozilla.org/Modules/Firefox

Thanks for the pointer!
Attachment #8599546 - Flags: review?(josh)
>> I haven't heard a good reason why web pages can just go down the denied
>> route by default until the permission is granted. Progressive enhancement is
>> what developers had to do before the geolocation API was ubiquitous. What
>> are cases where an immediate decision is absolutely necessary and deserves
>> forcing users to drop everything and decide?
>
> Cross browser compatibility and consistent cross-browser behavior. 

Also, the actual location check can take several seconds to complete when allowed. We ran into this when bringing up a store finder in a small part of our web application.  We wanted to start by trying to find the user's location, but if they disallowed replace our instruction text to use a search field (which is available while we're searching for the location). Since the "Not Now" UI doesn't give us any feedback, we don't have a good trigger to replace the "finding location / check the browser to give permission" text with "enter a city/zip code". Getting the "not allowed" callback right after the user clicks "not now" will give us a better trigger to update our text. Also, getting the callback sometime later in this case is totally worthless, since it was specific to an immediate user workflow.

@Marcos -- thanks for working on this. It's great to see this finally getting some traction.
>>  What are cases where an immediate decision is absolutely necessary and deserves 
>> forcing users to drop everything and decide? 

Note that no one is forcing the user to do anything (UI/UX behavior is not affected by this patch). The user can still dismiss the request by switching tabs, clicking the [x], or alt-tabbing to a different application. That's not changing. The only thing that is changing is that the web application gets notified that the notification has been dismissed.
Here is a flowchart showing the various problems with our popup notification system for W3C permissions, and comparing it to Chrome Beta, which does a much better job.

The patch proposed here improves this flow by reducing the number of choices that lead to no js callback to the page.
As people seem to be misunderstanding the flaws with the UX/UI, I've made a video that clearly shows the problem. It compares our pop-up notifications to Chrome, and shows how applying this patch addresses the problem at the API level (even if we don't fix the UX... which we should do, but not in this bug):

https://www.youtube.com/watch?v=CNF0js2hDG0
(In reply to Marcos Caceres [:marcosc] from comment #94)
> (In reply to Matthew N. [:MattN] from comment #93)
> > (In reply to Garvan Keeley [:garvank] from comment #81)
> > > We have questions of :
> > > - Should a single getCurrentPosition() potentially get an error callback
> > > followed by a success callback? Will this create new problems for developers
> > > who aren't expecting that sequence of events?
> > > - Should a single watchPosition() call behave the same?
> > > - If the above 2 didn't happen, instead, is it a bug that a user could click
> > > off the dialog causing it to dismiss, then re-show the dialog and click to
> > > "Share Location", and have nothing happen? 
> > 
> > Yes, it's unacceptable to have a button in the UI which is useless. It seems
> > like both getCurrentPosition and watchPosition both get called again after
> > an initial dismissal with this patch though. Is that sometimes not the case?
> > Does it have to do with whether the function is still alive?
> 
> The function is not alive. But dismissal does not equal deny. 

Doesn't this patch make them equal to the page though? When I tested the patch the callback got called for both APIs. Is this what you intend? I'm guess not since you say the function isn't alive but it doesn't match what I saw.

> > > Moreover, if UX team is adamant that the current UI is the correct approach,
> > > then we need W3C spec changes ASAP to properly support an error code on the
> > > callback for the permission request being dismissed with no choice being
> > > made.
> > 
> > I think the current UX is still preferred as it doesn't force users to make
> > a decision until they need to and IMO it's an advantage over the competitors.
> 
> This is only true if the API changes proposed here are accepted. The UX is
> hardly "advantage over the competitors" in it's currently broken form: if
> you accidentally switch apps or switch tabs, the user loses the ability to
> make a choice. That's extremely poor and misguided UX... it also punishes
> developers, because they can't get a sense of what is going on and recover.
> They are left waiting for a call back that never arrives, so their only
> recourse is hurling abuse at us on this bug because of it. 

That's not the case though. The user can continue to make a choice by reopening the panel. The could also click the geolocation button on the page again to have it re-open.

> > I wonder if this change will lead to more annoyance for users as sites will
> > interpret dismissals and denying permission rather than delaying the
> > decision and put up annoying, possibly modal, UI just because a user clicked
> > on something else on the page.
> 
> I'm working on a separate API to address that:
> https://w3c.github.io/permissions/

My understanding is that it was intentional that the geolocation API didn't have a way to check whether permission was granted without asking for location but it seems like this spec changes that.

> > I haven't heard a good reason why web pages can just go down the denied
> > route by default until the permission is granted. Progressive enhancement is
> > what developers had to do before the geolocation API was ubiquitous. What
> > are cases where an immediate decision is absolutely necessary and deserves
> > forcing users to drop everything and decide?
> 
> Cross browser compatibility and consistent cross-browser behavior. 

That doesn't answer my question. I was asking for website use cases. Also, Chrome is considering changing their behaviour to be more like ours.

(In reply to Alex Dixon from comment #95)
> >> I haven't heard a good reason why web pages can just go down the denied
> >> route by default until the permission is granted. Progressive enhancement is
> >> what developers had to do before the geolocation API was ubiquitous. What
> >> are cases where an immediate decision is absolutely necessary and deserves
> >> forcing users to drop everything and decide?
> >
> > Cross browser compatibility and consistent cross-browser behavior. 
> 
> Also, the actual location check can take several seconds to complete when
> allowed. We ran into this when bringing up a store finder in a small part of
> our web application.  We wanted to start by trying to find the user's
> location, but if they disallowed replace our instruction text to use a
> search field (which is available while we're searching for the location).
> Since the "Not Now" UI doesn't give us any feedback, we don't have a good
> trigger to replace the "finding location / check the browser to give
> permission" text with "enter a city/zip code".

Why do you believe you need this text in the first place? Many other large sites have store finders that don't have this problem.

> Also, getting the callback sometime later in this case
> is totally worthless, since it was specific to an immediate user workflow.

You're free to ignore it then.

(In reply to Marcos Caceres [:marcosc] from comment #96)
> >>  What are cases where an immediate decision is absolutely necessary and deserves 
> >> forcing users to drop everything and decide? 
> 
> Note that no one is forcing the user to do anything (UI/UX behavior is not
> affected by this patch). The user can still dismiss the request by switching
> tabs, clicking the [x], or alt-tabbing to a different application. That's
> not changing. The only thing that is changing is that the web application
> gets notified that the notification has been dismissed.

The UX is affected because currently dismissing has no effect on what the website knows but after this it will have an effect. That means I may not want to just click outside to dismiss as it's possible the website may not have an easy way to bring it back (assuming I'm understanding correctly that simply re-opening the panel and clicking the button isn't always going to work).

(In reply to Garvan Keeley [:garvank] from comment #97)
> which does a much better job.

Only if you assume a JS response is better. That's still not clear to me.
See Also: → 1064257
Depends on: 1154742
De-assigning myself. Will try to fix this through the Permission API instead. That way developers can avoid interacting with this dialog as little as possible (or hopefully this will get fixed in the redesign).
Assignee: mcaceres → nobody
(In reply to Marcos Caceres [:marcosc] from comment #100)
> De-assigning myself. Will try to fix this through the Permission API
> instead. That way developers can avoid interacting with this dialog as
> little as possible (or hopefully this will get fixed in the redesign).

Procrastination? Anyway, Marcos, many thanks for your contribution. Glad to read you :)
Damn. I read through the whole thread, starting to get excited that I can tell my client that the bug they've reported is now fixed (or worst-case, will be in the next Firefox release)... and then it just stops.

Marcos, your effort, your patch and your video are great. There should be a petition to have vetoing-the-patch developers resign from Mozilla if they still don't understand fundamental usability issues like this.

(One additional point: pressing the close button on the Chrome dialog is equivalent to Firefox's "Not Now" answer: it is what users do if they want the dialog to go away, don't want to allow location access now, but do want to be asked next time they are here. In Chrome it sends a deny result to the JavaScript immediately.)
This got reported at 2011-07-31 16:08 and still no fix ??

It should fire error callback on not now or on popup closing.. 
The way it handles things now makes geolocation nearly worthless and breaking websites that are using it, please fix it ..
It is painful yes. The current status is that this bug is supposed to be fixed as part of the refactor that fixes the permission popup:
https://bugzilla.mozilla.org/show_bug.cgi?id=1064257
^^^ that bug is also nearly a year old.
Correction, it is now this bug https://bugzilla.mozilla.org/show_bug.cgi?id=1154742, which is marked ui review+. I don't know what uireview+ means in terms of implementation and landing in code.
I have the same issue. I'm not receiving an error when the user clicks not now or closes the popup. I do get this in chrome and safari. My work around is setting a timer and if it never hears back from it to assume it failed which really isn't what I want to do. I hope you consider making it consistent with other browsers.
I am suffering also on Mozilla/5.0 (Windows NT 10.0; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
I launched a new Google JS API map page internally several days ago, making use of the Geolocation spec, and I've been getting a lot of negative feedback because if a user clicks don't share, then the page is frozen. I found this bug and read through all the comments, and I'm very disappointed. Been forced to tell users that Firefox is just broken and to use Chrome or Edge.
(In reply to Andy Mercer from comment #109)
> I launched a new Google JS API map page internally several days ago, making
> use of the Geolocation spec, and I've been getting a lot of negative
> feedback because if a user clicks don't share, then the page is frozen. I
> found this bug and read through all the comments, and I'm very disappointed.
> Been forced to tell users that Firefox is just broken and to use Chrome or
> Edge.

You can simple use custom timeout over getCurrentPosition, and show hint on timeout to force user to click cancel or allow. But hell you're right it's so inconvenient for the developers.
(In reply to Alex Art from comment #110)
> (In reply to Andy Mercer from comment #109)
> > I launched a new Google JS API map page internally several days ago, making
> > use of the Geolocation spec, and I've been getting a lot of negative
> > feedback because if a user clicks don't share, then the page is frozen. I
> > found this bug and read through all the comments, and I'm very disappointed.
> > Been forced to tell users that Firefox is just broken and to use Chrome or
> > Edge.
> 
> You can simple use custom timeout over getCurrentPosition, and show hint on
> timeout to force user to click cancel or allow. But hell you're right it's
> so inconvenient for the developers.

Problem with that is that getting the geolocation response can take a long time. I tried an 8 second timeout that hides my loading overlay, but that sometimes isn't enough time to process the request if the user accepts.

I shouldn't have to user a timeout. In Chrome and Edge, I don't. Regardless or work arounds, the simple fact is that it's broken in Firefox.
Yes the specs are not implemented correctly: https://bugzilla.mozilla.org/show_bug.cgi?id=675533#c37

And we all hope it will be fixed one day.

But today I think we can forgive it to this wonderful browser because it has the best support best CSS3 support: (http://css3test.com/) and the best ES6 support (http://kangax.github.io/compat-table/es6/), and is not so memory greedy as other browsers(http://www.hanselman.com/blog/FindingALowmemoryBrowser.aspx).
All that we can do is try to keep this topic alive until someone will fix this, and support our favorite browser! Because we do truly love Firefox for such a great progress Mozilla brought to the Internet.
"we all hope it will be fixed one day." IIUC, it has been fixed, by Marcos, but the patch got rejected as whoever is responsible didn't understand the need. So Marcos made a video (see comment #98) to explain. And they still rejected it. :-(
The delay in accepting a fix for this is really frustrating. Hoping that one day soon a fix is accepted.
(In reply to Alex Art from comment #114)
> Then let's try to vote for this:
> https://ffdevtools.uservoice.com/forums/246087-firefox-developer-tools-ideas/
> suggestions/10151820-make-share-location-geolocation-navigation-to-wokr
> To arise more attention to this topic.

This wouldn't help. That user voices is for developer tools, not Firefox features.
I see, Marcos.
But the votes here are ignored, so where else the community can provide feedback?
(In reply to Alex Art from comment #117)
> I see, Marcos.
> But the votes here are ignored, so where else the community can provide
> feedback?

Part of it is probably the number of votes. Only 29 as of right now.

Btw, Marcos, thank you for doing all the work to create the patch.
(In reply to Andy Mercer from comment #118)
> (In reply to Alex Art from comment #117)
> > I see, Marcos.
> > But the votes here are ignored, so where else the community can provide
> > feedback?
> 
> Part of it is probably the number of votes. Only 29 as of right now.

<dirty-secret>
Votes are not considered when prioritizing features (I don't even know of a way of seeing them ranked in bugzilla). Votes were only introduced to stop people adding "+1" to comments, as that generates an email every time :) ... i.e., votes are pretty much just a feel-good (tm) feature that prevent spam but have no actual value. 
</dirty-secret>
 
> Btw, Marcos, thank you for doing all the work to create the patch.

No probs. Ok, the only way we are getting this fixed is to cut through the political BS. We need to make sure that the patch does, in fact, do what it says it does (people here, please do take a look at the patch ... it's literally like 5 lines of JavaScript + tests, nothing scary) - and to probably escalate this within Mozilla's engineering chain of command. 

We can try to convince Matthew N. by addressing the feedback in comment 99.
(In reply to Marcos Caceres [:marcosc] from comment #119)
> people here, please do take a look at the patch ... it's
> literally like 5 lines of JavaScript + tests, nothing scary) - and to
> probably escalate this within Mozilla's engineering chain of command.

Any good tutorials on how to apply a patch to Firefox and test? Didn't build firefox anytime before and it sounds scary to me :)
(In reply to Matthew N. [:MattN] from comment #93)
> I haven't heard a good reason why web pages can just go down the denied
> route by default until the permission is granted. 

When should you take the denied route if you never know the user won't grant the permission?

> Progressive enhancement is
> what developers had to do before the geolocation API was ubiquitous.

This is a different route. There are 3 routes:
* No geolocation API (which you take via feature detection)
* API is present and user denied access (which you take after you prompted the user for geoloc info and they explicitly refused)
* API is present and user accepted access (which you take after you prompted the user for geoloc info and they explicitly accepted)

Of course, there are ways to work around the lack reject callback (like a timer racing against the accept callback as mentioned above), but it'd be better to know the user refused when they did.

For use cases, consider the following inspired by [1]:
You have a button in the webpage where the user clicks to indicate the websites they want to share their geolocation. In the "no geolocation API" case, there is no such button at all.
As a website, based on their decision, we want to update the color of the button based on whether they have accepted or denied the geolocation request. If they accept, it's green and we write down whatever info. If they refuse via "Not now" (and some will, because humans are irrational or just wanted to try out that button or tapped it by mistake), we want to have the button red as a visual reminder to the user that they refused recently.

Note that in that use case, the "no geoloc API" and the "user denied geoloc" are very different. This use cases makes use of progressive enhancement while still being handicapped by Firefox current behavior as demonstrated by Marcos.

Does this make sense?

[1] https://youtu.be/3dAwZVsS8wo?t=960 (the whole talk is otherwise interesting, but the relevant part is 16'40'' to 17'15'')
Flags: needinfo?(MattN+bmo)
See Also: → 1236352
I see why it would makes sense to allow dismissal of the geolocation prompt but I think the UI is currently a bit counterintuitive. My problem is that (to me) "Not Now" does not imply dismissal. To me it's more like "No I don’t want to share my location right now, but ask me again next time", in which case it would make sense to trigger the error callback. I think if you want to allow the user to dismiss the prompt the option should probably read "Dismiss". Personally I think the options should be: "Allow" or "Block" (like Chrome) or possibly "Dismiss". Or perhaps don’t explicitly make dismiss an option and just have it implied when the prompt is closed.
See Also: → 1241749
I'm wondering if anyone has figured out a workaround for this yet ? Since Firefox seems to be the only browser that doesn't let you know when the user has denied the geolocation request. Does this mean (yuk) you have to write browser specific code and detect browser version to make sensible forms that can handle Firefox as well as spec-compliant browsers ?
Status: REOPENED → NEW
Component: Geolocation → Notifications and Alerts
OS: Mac OS X → All
Product: Core → Toolkit
Hardware: x86 → All
Summary: Share location- "Not Now" Doesn't fire error callback → Content permission prompts don't notify content when dismissed (X, Not now, click outside, etc.)
Version: 5 Branch → Trunk
(In reply to David Bruant from comment #121)
> (In reply to Matthew N. [:MattN] from comment #93)
> > I haven't heard a good reason why web pages can just go down the denied
> > route by default until the permission is granted. 
> 
> When should you take the denied route if you never know the user won't grant
> the permission?

My point is that the denied state and the not yet requested state can be the same.

> > Progressive enhancement is
> > what developers had to do before the geolocation API was ubiquitous.
> 
> This is a different route. There are 3 routes:
> * No geolocation API (which you take via feature detection)
> * API is present and user denied access (which you take after you prompted
> the user for geoloc info and they explicitly refused)
> * API is present and user accepted access (which you take after you prompted
> the user for geoloc info and they explicitly accepted)

You're missing:
* API is present and user didn't click a button to request access yet.

I think this button should stay available to click even once it has been clicked once. This is what Google Maps does and it seems to work fine. If a user accidentally dismisses, they simply click the geolocation button again and it will re-open the doorhanger.
Flags: needinfo?(MattN+bmo)
Matthew - I can give you our reason, I want to send some info to the server that will record the location at which the user did something. A dialog pops up asking permission. If they accept, I send the form contents to the server with location, if they reject I send with no location - and the server can act accordingly.   This works in every other browser, but not in Firefox because I never know they have rejected.
(In reply to Mitra Ardron from comment #131)
> Matthew - I can give you our reason, I want to send some info to the server
> that will record the location at which the user did something. A dialog pops
> up asking permission. If they accept, I send the form contents to the server
> with location, if they reject I send with no location - and the server can
> act accordingly.   This works in every other browser, but not in Firefox
> because I never know they have rejected.

A quick workaround is to request the permission and, after X seconds, if the user hasn't accepted yet, assume they dismissed the prompt.
(In reply to Marco Castelluccio [:marco] from comment #132)
> A quick workaround is to request the permission and, after X seconds, if the
> user hasn't accepted yet, assume they dismissed the prompt.

And you have to write more workaround to deal with permission that is granted after you've already timed out and assumed the prompt was dismissed.
Any update on the implementation of this workaround or a longer term fix?
The long term fix is use the Permissions API. You can see examples in the spec to see how you would detect the permission being denied:

https://w3c.github.io/permissions/#examples

Unfortunately, this is still busted in Firefox (though the API is in Nightly) :( Clicking off or clicking the "X" is supposed to fire the onchange event. Sadly, it's still doesn't.
(In reply to Elijah Reale from comment #126)
> I see why it would makes sense to allow dismissal of the geolocation prompt
> but I think the UI is currently a bit counterintuitive. My problem is that
> (to me) "Not Now" does not imply dismissal.

Sure, it's just dismissed for the session. But it's still a dismissal.

> To me it's more like "No I don’t
> want to share my location right now, but ask me again next time",

That's fine. But, again, still a dismissal. The Permission API deals with this by allowing the developer to re-prompt until the user outright says "no!". At that point, that dismissal is final. 

> in which
> case it would make sense to trigger the error callback.

Yes, but it still applies in both cases. Session-based permission (i.e., "not now") and permanent ban. They both reflect a state change that MUST be reflected back to the developer (or we a) are in violation of the spirit of the geo specification; b) we are in direct violation of the Permissions API).  

> I think if you want
> to allow the user to dismiss the prompt the option should probably read
> "Dismiss". Personally I think the options should be: "Allow" or "Block"
> (like Chrome) or possibly "Dismiss". Or perhaps don’t explicitly make
> dismiss an option and just have it implied when the prompt is closed.

What the labels are is definitely important (and we should strive to improve them with user testing) - but I would be ok with keeping them as they are. Right now, we could just fix this behavior and solve a bunch of web compat issues for a large number of users.
(In reply to csongor from comment #138)
 
> The second half of this specification does not work. And it hasn't been
> working for five years. Fix it, please.

They have decided not to fix it. The answer here is to detect Firefox and tell users to stop using a broken browser. Posting here just gets marked as advocacy and hidden.
It's hard for Mozilla to regain market share if they don't make sensible developers happy first.

@Firefox team, please seriously consider fixing this before the point of no return to all your loyal folks.
Web application developer here. Just came across this issue and it's enough of a headache that I am ABANDONING GEOLOCATION as a feature.

There's no sane way to engineer a decent user experience with the API in its current state.

I NEED to be able to distinguish between "no" and "no answer". I'm AMAZED that there's any debate over this.

Please fix the API. Until then my application will be feature-incomplete.
I've emailed Mark Mayo (Firefox lead) to see if we can get some movement on this. It's seriously ridiculous that this is still not fixed.
FYI my team is currently working on a redesign of permission management in Firefox (prompts, control center, etc.) that will fix this issue. There are too many bugs to follow, but I'm marking the user story bug 1188147 as a dependency so that people can be notified when the most relevant part of that project is done.
Depends on: 1188147
(In reply to Panos Astithas [:past] from comment #143)
> FYI my team is currently working on a redesign of permission management in
> Firefox (prompts, control center, etc.) that will fix this issue. There are
> too many bugs to follow, but I'm marking the user story bug 1188147 as a
> dependency so that people can be notified when the most relevant part of
> that project is done.

If you're working on permission management, I'd like to make a suggestion. As a user it's nice that the request for e.g. geolocation us unintrusive, and this should be the default approach, but as a developer I'd like the option to make it a synchronous, in-your-face modal input dialog where necessary.
(In reply to spraff from comment #144)
> If you're working on permission management, I'd like to make a suggestion.
> As a user it's nice that the request for e.g. geolocation us unintrusive,
> and this should be the default approach, but as a developer I'd like the
> option to make it a synchronous, in-your-face modal input dialog where
> necessary.

Sync modal dialogs have a whole bunch of problems, which is why all permission request APIs are async. Also, user's needs are a higher priority than developer needs - which should explain why we would be unlikely to make model sync dialogs. Having said that, an modal async dialog might work ok, as it does in iOS - but that's up to individual products to implement and not in scope for this bug, which relates to executing a particular callback.
Hi y'all! I received some fantastic news from the Firefox team [1]. They are working on redoing the permissions UI right now, which will do away with both the "x" and "not now" options (rendering this bug a non-issue). 

They have these beautiful mock-ups up of the new prompts (not final, but you will get the idea): 
https://mozilla.invisionapp.com/share/AF71R266U#/screens/142999157

We are working on the final details (in particular, what happens wrt the error callback when the user presses the "esc" key) - but I'm quite excited that we are, after 5 years, really close to actually seeing this fixed!  

It will take a few more months to land (we expect Q3 or 4) - but exciting nonetheless. 

[1] https://groups.google.com/d/msg/mozilla.dev.platform.ux/NFAPsr4Opb0/6hMoSozoBgAJ
These look great. I'm wondering, if a user checks the "Remember my decision" checkbox, will that decision then be returned via the API on subsequent requests?
(In reply to Andy Mercer from comment #147)
> These look great. I'm wondering, if a user checks the "Remember my decision"
> checkbox, will that decision then be returned via the API on subsequent
> requests?

Yes. They should be reflected via the Permissions API - or the appropriate callback, in the case of Geo.
(In reply to Marcos Caceres [:marcosc] from comment #146)
> Hi y'all! I received some fantastic news from the Firefox team [1]. They are
> working on redoing the permissions UI right now, which will do away with
> both the "x" and "not now" options (rendering this bug a non-issue). 
> 
You're definitely The Magic Marcos. Thanks a lot.
In case you missed the fireworks, this is now fixed in 53 with the new permission prompt redesign.
Status: NEW → RESOLVED
Closed: 13 years ago7 years ago
Resolution: --- → FIXED
(In reply to Panos Astithas [:past] from comment #150)
> In case you missed the fireworks, this is now fixed in 53 with the new
> permission prompt redesign.

More information here https://bugzilla.mozilla.org/show_bug.cgi?id=1282768, in case anyone is wondering.
Product: Toolkit → Toolkit Graveyard
You need to log in before you can comment on or make changes to this bug.