GNOME Bugzilla – Bug 762594
Find location button doesn't work after denying access to location services
Last modified: 2018-03-26 13:09:55 UTC
Testing Maps with an up to date continuous image: when I launch Maps, the shell shows a permission dialog to provide access to location data. If I deny access, whenever I press the find location button, Maps shows an in-app notification that says "position not found". In other words, after denying access to location services, the find location button doesn't work any more, and the user has to restart Maps to try and fix it. How are they supposed to know this? If the user is pressing find location, they are implicitly requesting access to location services. It would be good if Maps could ask for access to location services again at this point (so the shell shows the permission dialog).
(In reply to Allan Day from comment #0) > Testing Maps with an up to date continuous image: when I launch Maps, the > shell shows a permission dialog to provide access to location data. If I > deny access, whenever I press the find location button, Maps shows an in-app > notification that says "position not found". > > In other words, after denying access to location services, the find location > button doesn't work any more, and the user has to restart Maps to try and > fix it. How are they supposed to know this? > > If the user is pressing find location, they are implicitly requesting access > to location services. It would be good if Maps could ask for access to > location services again at this point (so the shell shows the permission > dialog). This is how it worked before the shell added the permission thing. It looked at a gsetting and if it was off it gave you a notification and a button that sent you to privacy panel. Is that flow still the one we want?
(In reply to Jonas Danielsson from comment #1) > (In reply to Allan Day from comment #0) > > Testing Maps with an up to date continuous image: when I launch Maps, the > > shell shows a permission dialog to provide access to location data. If I > > deny access, whenever I press the find location button, Maps shows an in-app > > notification that says "position not found". > > > > In other words, after denying access to location services, the find location > > button doesn't work any more, and the user has to restart Maps to try and > > fix it. How are they supposed to know this? > > > > If the user is pressing find location, they are implicitly requesting access > > to location services. It would be good if Maps could ask for access to > > location services again at this point (so the shell shows the permission > > dialog). > > This is how it worked before the shell added the permission thing. It looked > at a gsetting and if it was off it gave you a notification and a button that > sent you to privacy panel. > > Is that flow still the one we want? The per-app settings are not stored in gsettings but on xdg-app's permission store service. I think this bug needs to be fixed more on shell and geoclue side: https://bugs.freedesktop.org/show_bug.cgi?id=94267 but Maps need to hook-up to org.freedesktop.GeoClue2.Client.Active property and react accordingly. It should be doing that already anyway actually: "Please keep in mind that geoclue can at any time stop and start the client on user (agent) request. Applications that are interested in in these changes, should watch for changes in this property."
(In reply to Zeeshan Ali (Khattak) from comment #2) > (In reply to Jonas Danielsson from comment #1) > > (In reply to Allan Day from comment #0) > > > Testing Maps with an up to date continuous image: when I launch Maps, the > > > shell shows a permission dialog to provide access to location data. If I > > > deny access, whenever I press the find location button, Maps shows an in-app > > > notification that says "position not found". > > > > > > In other words, after denying access to location services, the find location > > > button doesn't work any more, and the user has to restart Maps to try and > > > fix it. How are they supposed to know this? > > > > > > If the user is pressing find location, they are implicitly requesting access > > > to location services. It would be good if Maps could ask for access to > > > location services again at this point (so the shell shows the permission > > > dialog). > > > > This is how it worked before the shell added the permission thing. It looked > > at a gsetting and if it was off it gave you a notification and a button that > > sent you to privacy panel. > > > > Is that flow still the one we want? > > The per-app settings are not stored in gsettings but on xdg-app's permission > store service. I think this bug needs to be fixed more on shell and geoclue > side: > > https://bugs.freedesktop.org/show_bug.cgi?id=94267 > > but Maps need to hook-up to org.freedesktop.GeoClue2.Client.Active property > and react accordingly. It should be doing that already anyway actually: > > "Please keep in mind that geoclue can at any time stop and start the client > on user (agent) request. Applications that are interested in in these > changes, should watch for changes in this property." Thanks zeeshan! Will look into that! IRC convo below: 1:26 PM <•jonasdn> but my question remains 1:26 PM <•jonasdn> should we not show our custom notification anymore? 1:26 PM <•jonasdn> is this completly handled by shell? 1:26 PM <•jonasdn> what should we do if we find out permissoin is denied? 1:26 PM <•jonasdn> can we do anything? 1:26 PM <•jonasdn> can we find out? 1:26 PM <zeenix> showing of notification, that woudl be a question for aday i guess 1:27 PM <•jonasdn> should it still direct to privacy panel? 1:27 PM <•jonasdn> this is catching me a bit off-guard 1:27 PM <zeenix> i think you get a particular error code 1:27 PM <•jonasdn> since what we have is from designer mockups New messages since you tabbed out 1:27 PM <zeenix> yeah, i know 1:27 PM <zeenix> that's why aday need to be consulted
So the question is, how should the flow be. What I imagine: 1) - Maps start => shell dialog requesting access triggered - Access granted - things work 2) - Maps start => shell dialog requesting access triggered - Access denied - Pressing location button triggers shell dialog again - Access granted - things work 3) - Maps start => shell dialog does not show since we are white-listed - things work 4) - Maps start => shell dialog does not show since we are white-listed - User has explicitly disabled Maps in control center - pressing the button gives error => show in-app notification with button linking to control center as before Am I missing a case? Can one be black-listed so the dialog does not show up, but we do not have access?
(In reply to Jonas Danielsson from comment #4) > So the question is, how should the flow be. > > What I imagine: > > 1) > - Maps start => shell dialog requesting access triggered > - Access granted > - things work > > > 2) > - Maps start => shell dialog requesting access triggered > - Access denied > - Pressing location button triggers shell dialog again > - Access granted > - things work > > 3) > - Maps start => shell dialog does not show since we are white-listed > - things work > > 4) > - Maps start => shell dialog does not show since we are white-listed > - User has explicitly disabled Maps in control center > - pressing the button gives error => show in-app notification with button > linking to control center as before > > > Am I missing a case? Can one be black-listed so the dialog does not show up, > but we do not have access? No, that's it. There is no black-list, except for what you covered in 4).
(In reply to Zeeshan Ali (Khattak) from comment #5) > (In reply to Jonas Danielsson from comment #4) > > So the question is, how should the flow be. > > > > What I imagine: > > > > 1) > > - Maps start => shell dialog requesting access triggered > > - Access granted > > - things work > > > > > > 2) > > - Maps start => shell dialog requesting access triggered > > - Access denied > > - Pressing location button triggers shell dialog again > > - Access granted > > - things work > > > > 3) > > - Maps start => shell dialog does not show since we are white-listed > > - things work > > > > 4) > > - Maps start => shell dialog does not show since we are white-listed > > - User has explicitly disabled Maps in control center > > - pressing the button gives error => show in-app notification with button > > linking to control center as before > > > > > > Am I missing a case? Can one be black-listed so the dialog does not show up, > > but we do not have access? > > No, that's it. There is no black-list, except for what you covered in 4). Good. So an issue at the moment is that from code Maps can not tell the difference from an error from geoclue that is because a user press denied and an error from geoclue because Maps was explicit denied in control center. So we cannot react in a proper way.
I am a bit uneasy about the tight coupling to a shell mechanism as well. So if a user will run Maps as a xdg-app on an older gnome-shell the location-service will not really work? How do other apps that need location-service handle this? How does weather and clocks behave? Should we punt this to 3.22?
(In reply to Jonas Danielsson from comment #7) > I am a bit uneasy about the tight coupling to a shell mechanism as well. If I give you different error codes, you don't have to care about shell mechanism. You'll just be reacting differently to different error codes. The only thing you'll assume is that user can enable location access to Maps from privacy panel (if you get the appropriate error code, e.g 'APP_DISABLED'). > So > if a user will run Maps as a xdg-app on an older gnome-shell the > location-service will not really work? It'll work. Older shell doesn't care about xdg-app and neither does older geoclue. > How do other apps that need location-service handle this? How does weather > and clocks behave? They don't. I think they just allow you to enter a location. > Should we punt this to 3.22? Maybe. I'll want aday's opinion on that.
(In reply to Zeeshan Ali (Khattak) from comment #8) > (In reply to Jonas Danielsson from comment #7) > > I am a bit uneasy about the tight coupling to a shell mechanism as well. > > If I give you different error codes, you don't have to care about shell > mechanism. You'll just be reacting differently to different error codes. The > only thing you'll assume is that user can enable location access to Maps > from privacy panel (if you get the appropriate error code, e.g > 'APP_DISABLED'). > > > So > > if a user will run Maps as a xdg-app on an older gnome-shell the > > location-service will not really work? > > It'll work. Older shell doesn't care about xdg-app and neither does older > geoclue. What I mean is on older shell there will not be a dialog. So my code will look at a failure from geoclue and expect the dialog to be up, right? Or we have to make sure that the error message for explictly denied is the same as before, and the one for dialog denied is a new one, so that Maps will behave the same when there is no shell dialog, right?
(In reply to Jonas Danielsson from comment #9) > (In reply to Zeeshan Ali (Khattak) from comment #8) > > (In reply to Jonas Danielsson from comment #7) > > > I am a bit uneasy about the tight coupling to a shell mechanism as well. > > > > If I give you different error codes, you don't have to care about shell > > mechanism. You'll just be reacting differently to different error codes. The > > only thing you'll assume is that user can enable location access to Maps > > from privacy panel (if you get the appropriate error code, e.g > > 'APP_DISABLED'). > > > > > So > > > if a user will run Maps as a xdg-app on an older gnome-shell the > > > location-service will not really work? > > > > It'll work. Older shell doesn't care about xdg-app and neither does older > > geoclue. > > What I mean is on older shell there will not be a dialog. So my code will > look at a failure from geoclue and expect the dialog to be up, right? Or we > have to make sure that the error message for explictly denied is the same as > before, and the one for dialog denied is a new one, so that Maps will behave > the same when there is no shell dialog, right? I'll get you a different code so newer shell/geoclue doesn't give you the old generic code.
I just realised something more, the error was "Position not found" ? That is only given on timeout, when geoclue gives no answer at all, which is super weird. Does it work when giving access? Zeeshan: Have you seen this before?
(In reply to Jonas Danielsson from comment #11) > I just realised something more, the error was "Position not found" ? > That is only given on timeout, when geoclue gives no answer at all, which is > super weird. Does it work when giving access? Yeah, works fine here. I don't see any timeouts in either case. > Zeeshan: Have you seen this before? Nope.
(In reply to Jonas Danielsson from comment #4) > So the question is, how should the flow be. > > What I imagine: > > 1) > - Maps start => shell dialog requesting access triggered > - Access granted > - things work > > > 2) > - Maps start => shell dialog requesting access triggered > - Access denied > - Pressing location button triggers shell dialog again > - Access granted > - things work No, geoclue should deny here, without launching the dialogue. Oressing the button should pop up a dialogue, in the app itself, asking the user to change the settings in the privacy panel. This probably needs mockups. > 3) > - Maps start => shell dialog does not show since we are white-listed > - things work > > 4) > - Maps start => shell dialog does not show since we are white-listed > - User has explicitly disabled Maps in control center > - pressing the button gives error => show in-app notification with button > linking to control center as before That's the one. > Am I missing a case? Can one be black-listed so the dialog does not show up, > but we do not have access? Yep, in 2)
(In reply to Bastien Nocera from comment #13) > (In reply to Jonas Danielsson from comment #4) > > So the question is, how should the flow be. > > [...] > > > > 2) > > - Maps start => shell dialog requesting access triggered > > - Access denied > > - Pressing location button triggers shell dialog again > > - Access granted > > - things work > > No, geoclue should deny here, without launching the dialogue. Oressing the > button should pop up a dialogue, in the app itself, asking the user to > change the settings in the privacy panel. This probably needs mockups. Thanks! Deny when exactly. When pressing the second time? We already have a inApp notification with a button that sends you to privacy-panel that we use know. But we currently look at the location-service setting that is not meaningful anymore I gather? > > > 3) > > - Maps start => shell dialog does not show since we are white-listed > > - things work > > > > 4) > > - Maps start => shell dialog does not show since we are white-listed > > - User has explicitly disabled Maps in control center > > - pressing the button gives error => show in-app notification with button > > linking to control center as before > > That's the one. > > > Am I missing a case? Can one be black-listed so the dialog does not show up, > > but we do not have access? > > Yep, in 2) Ok, so just so that I understand: Pressing denied once in the dialog should be interpreted as denied until you explicit allow in control panel? Does that control exist today? (This would make it easier for me because then all error-cases means I should send user to privacy-panel as we do today)
(In reply to Bastien Nocera from comment #13) > (In reply to Jonas Danielsson from comment #4) > > So the question is, how should the flow be. > > > > What I imagine: > > > > 1) > > - Maps start => shell dialog requesting access triggered > > - Access granted > > - things work > > > > > > 2) > > - Maps start => shell dialog requesting access triggered > > - Access denied > > - Pressing location button triggers shell dialog again > > - Access granted > > - things work > > No, geoclue should deny here, without launching the dialogue. Oressing the > button should pop up a dialogue, in the app itself, asking the user to > change the settings in the privacy panel. This probably needs mockups. As Jonas said, we already got a button for that but we do not want to show the button in this case. We only want to show the button after user perferences had been saved and later user disabled the application from control-center. I already agreed that Geoclue will have two different errors for this: org.freedesktop.GeoClue2.Error.UserDenied org.freedesktop.GeoClue2.Error.UserBlocked So that Maps know what to do in each case.
I think there's a little problem with how the permissions are handled in geoclue and in gnome-shell. You're only ever supposed to ask once per application. If it's denied, the application will need to show a dialogue telling the user that it didn't work, because location services are disabled, and with a link to the privacy panel explaining how to enable it. If it's accepted, that's it, the app is accepted. If the users changes their mind, or the application is removed and then re-installed, it should ask again[1]. Disabling can only be done in the panel once the application is installed. I don't know why it would ask multiple times, and even less why asking 3 times is any more trustworthy than asking once. [1]: This would be to prevent ID recycling, say, if org.gnome.Maps got bought by malicious hackers and use the information for nefarious needs. (In reply to Zeeshan Ali (Khattak) from comment #15) <snip> > I already agreed that Geoclue will have two different errors for this: > > org.freedesktop.GeoClue2.Error.UserDenied > org.freedesktop.GeoClue2.Error.UserBlocked > > So that Maps know what to do in each case. What's the difference? I'm guessing that geoclue will simply not respond until the agent has answered, correct? If so, then the error is the same, the user has refused access. You might want to have an error specific to the fact that there's no agent though.
(In reply to Bastien Nocera from comment #16) > I think there's a little problem with how the permissions are handled in > geoclue and in gnome-shell. You're only ever supposed to ask once per > application. > > If it's denied, the application will need to show a dialogue telling the > user that it didn't work, because location services are disabled, and with a > link to the privacy panel explaining how to enable it. Except that privacy panel is only relevant if either location services are disabled on a whole or application was disabled from privacy panel. The app only gets on the privacy panel if it had been given access 3 times in a row from the shell dialog at some point. > If it's accepted, that's it, the app is accepted. If the users changes their > mind, or the application is removed and then re-installed, it should ask > again[1]. Disabling can only be done in the panel once the application is > installed. > > I don't know why it would ask multiple times, and even less why asking 3 > times is any more trustworthy than asking once. > > [1]: This would be to prevent ID recycling, say, if org.gnome.Maps got > bought by malicious hackers and use the information for nefarious needs. > > (In reply to Zeeshan Ali (Khattak) from comment #15) > <snip> > > I already agreed that Geoclue will have two different errors for this: > > > > org.freedesktop.GeoClue2.Error.UserDenied > > org.freedesktop.GeoClue2.Error.UserBlocked > > > > So that Maps know what to do in each case. > > What's the difference? I'm guessing that geoclue will simply not respond > until the agent has answered, correct? If so, then the error is the same, > the user has refused access. You might want to have an error specific to the > fact that there's no agent though. The difference is that in one case (UserDenied, where user preference hasn't been saved), privacy panel isn't relevant.
Created attachment 322603 [details] [review] geoclue: Check for DBus ACCESS_DENIED
(In reply to Jonas Danielsson from comment #18) > Created attachment 322603 [details] [review] [review] > geoclue: Check for DBus ACCESS_DENIED Zeeshan: Could you help out finishing this, I get segfault when I start Maps with location service off and then try connecting again after turning it on... Could you debug a bit? Does not seem like a Maps issue, if it is feel free to pong back.
Created attachment 322788 [details] [review] geoclue: Remove timeout functionality Do not start a timeout loop for geoclue. Instead leave the button insensitive until we find a location.
Created attachment 322789 [details] [review] geoclue: Check for DBus ACCESS_DENIED
Review of attachment 322788 [details] [review]: pushed
Review of attachment 322789 [details] [review]: Works fine in my limited testing here, after I pushed a fix to Geoclue.
Review of attachment 322789 [details] [review]: Pushed. Aday: Once a new continous is re-generated with this push and Zeeshans geoclue fix, would you mind testing? Thanks!
Created attachment 322875 [details] Screencast of Maps behaviour after these patches (and geoclue fix)
(In reply to Zeeshan Ali (Khattak) from comment #25) > Created attachment 322875 [details] > Screencast of Maps behaviour after these patches (and geoclue fix) Did something go wrong here? This cast is 3 seconds long for me
Comment on attachment 322875 [details] Screencast of Maps behaviour after these patches (and geoclue fix) I attached the wrong one and bz won't let me attach the correct one for being too large file. :(
This this: https://vid.me/yVsH
With location services disabled in gnome-control-center (privacy panel), gnome-maps 3.20 doesn't do anything when pressing the "Find location" button. There is no notification or dialog or anything.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-maps/issues/52.