Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-20002] iOS: Ti.Geolocation.requestLocationPermissions is not always called?

GitHub Issuen/a
TypeBug
PriorityHigh
StatusClosed
ResolutionFixed
Resolution Date2015-12-04T20:24:05.000+0000
Affected Version/sRelease 5.1.0
Fix Version/sRelease 5.1.2
ComponentsiOS
Labelsgeolocation
ReporterFokke Zandbergen
AssigneeAngel Petkov
Created2015-11-17T11:10:49.000+0000
Updated2016-02-08T15:07:15.000+0000

Description

Both on device and in Simulator I can't get the callback for requestLocationPermissions in the following code to be called, even though - the first time - the dialog requesting permission *is* displayed. Which is weird, because in the [Ti 5.1.0 Sample App](https://github.com/appcelerator-developer-relations/appc-sample-ti510) it does call and is implemented in the exact same way. Removing everything in the button event listener except the request call doesn't change it either. 
var win = Ti.UI.createWindow({
	backgroundColor: 'white'
});
 
var btn = Ti.UI.createButton({
	title: 'Request Permissions'
});
 
btn.addEventListener('click', function(e) {
 
	Ti.API.info('Before Callback');

	Ti.Geolocation.requestLocationPermissions(Ti.Geolocation.AUTHORIZATION_ALWAYS, function(e) {

		Ti.API.info('In Callback');

		Ti.API.info(JSON.stringify(e, null, 2));
	});
 
});
 
win.add(btn);
win.open();
*Notes:* * Don't forget to add <key>NSLocationAlwaysUsageDescription</key><string>Deny or grant permission to test different scenarios.</string> to the tiapp.xml or use the attached project. * For a clean slate either change the app id, reset the Simulator or just _Settings > General > Reset > Reset Location & Privacy_.

Attachments

FileDateSize
requestdenied.zip2015-11-17T17:58:15.000+000010294306

Comments

  1. Fokke Zandbergen 2015-11-17

    Attached sample project.
  2. Fokke Zandbergen 2015-11-17

    Simplified test case in description and attached new project with that code. I've used the latest 5_1_X now (5.1.0.v20151116164430) and reset the Simulator and deleted build but still the same: 
       [DEBUG] Application booted in 210.619986 ms
   [INFO]  Before Callback
  3. Eric Merriman 2015-11-17

    Using code above, and with SDK 5.1.0.v20151116164430, I never get "In Callback" when I choose either approve or deny the request for permission.
  4. Fokke Zandbergen 2015-11-17

    [~emerriman] thanks for confirming I'm not crazy [~cng] I'm afraid this is a blocker :(
  5. Hans Knöchel 2015-11-17

    PR (master): https://github.com/appcelerator/titanium_mobile/pull/7460 PR (5_1_X): https://github.com/appcelerator/titanium_mobile/pull/7461 Summary: This issue is related to a bad practice (not checking already granted permissions). Anyway, this PR fixes that use-case.
  6. Fokke Zandbergen 2015-11-17

    Correct on that summary: Without this fix I can reproduce it with a clean build on a reset Simulator with a changed App ID as well so it's not related to a bad practice. More likely is it a result of the 3rd bullet of TIMOB-20004 where an empty string error message triggered the errorMessage != nul condition: https://github.com/appcelerator/titanium_mobile/pull/7461/files#diff-d8125f3a683a79e2b840cb8359e9d474L890
  7. Hans Knöchel 2015-11-17

    Also covers the issues in TIMOB-20004, is the backport needed? Feels more like a 5.1.1 or 5.2.0 fix.
  8. Chee Kiat Ng 2015-11-18

    we'll keep the back port for 5.1.1.
  9. Chee Kiat Ng 2015-11-23

    PRs approved and merged.
  10. Harry Bryant 2015-11-23

    Verified as fixed, Imported the attached sample app and built with SDK 5.1.1.v20151122191220. Received the following in the console when requestLocationPermissions is called: 
        [INFO] :   Before Callback
    [INFO] :   In Callback
    [INFO] :   {
    [INFO] :     "success": true,
    [INFO] :     "code": 0
    [INFO] :   }
    Tested on: Devices: iPhones 6S+ (9.1) Simulators: (9.1) & (8.4) Mac OSX El Capitan 10.11 (15A284) Ti SDK: 5.1.1.v20151122191220 Appc Studio: 4.4.0.201511182122 Appc NPM: 4.2.2 Appc CLI: 5.1.0-60 Alloy: 1.7.26 Xcode 7.1(7B91b) Node v0.12.7 *Closing Ticket.*
  11. Chee Kiat Ng 2015-11-26

    To Note: This ticket is marked 5.1.2 but PR was merged in 5.1.1GA
  12. Srikanth Sombhatla 2015-12-01

    [~fokkezb] Just a quick rehash of this issue - it is happening when the permission is either allowed/denied before and then presenting requestLocationPermissions ?
  13. Srikanth Sombhatla 2015-12-02

    When callback is nullified here https://github.com/hansemannn/titanium_mobile/blob/463fde3094356ae366a0ecd3e749779c1444c3f0/iphone/Classes/GeolocationModule.m#L890 The actual result of user approved/denied is never called because of condition here https://github.com/hansemannn/titanium_mobile/blob/463fde3094356ae366a0ecd3e749779c1444c3f0/iphone/Classes/GeolocationModule.m#L1080 Reopening the ticket.
  14. Srikanth Sombhatla 2015-12-02

    master PR: https://github.com/appcelerator/titanium_mobile/pull/7526 5_1_X PR: https://github.com/appcelerator/titanium_mobile/pull/7527 Additional test cases Case 1: Clear privacy settings. Shows permission alert and invokes callback *after* user acted on the alert. Case 2: Permission is either approved or denied earlier. Invokes callback. Permission alert is *not* shown.
  15. Chee Kiat Ng 2015-12-02

    CR and FT Passed. APPROVED! [~fokkezb] can you have a look as well before i merge? thanks!
  16. Chee Kiat Ng 2015-12-02

    PRs merged
  17. Harry Bryant 2015-12-02

    [~ssombhatla] Testing your PR for release 5.1.2 : Case 1: Privacy settings are clear, upon clicking Request Permissions , Before Callback is returned, and I am prompted to Allow or Deny Location Permissions. After selecting either, In Callback is not returned. Case 2: With Permissions now Denied or Approved, clicking Request Permissions returns the following: 
        [DEBUG] :  User already approved access to location services.
    [INFO] :   In Callback
    [INFO] :   {
    [INFO] :     "success": true,
    [INFO] :     "code": 0
    [INFO] :   }
    Permission alert is not shown in this case. To clarify, is the expected result for *Case 1* as described above? or should the user receive the In Callback after denying / approving permission request? Tested with: iPhone 6s Plus Device (9.1) & Simulator (9.1), (8.4) Mac OSX El Capitan 10.11 (15A284) Studio: 4.4.0.201511241829 Ti SDK: 5.1.2.v20151202061227 Appc NPM: 4.2.2 App CLI: 5.1.0 Xcode 7.1(7B91b) Node v4.2.2 production
  18. Chee Kiat Ng 2015-12-03

    in Case 1, In callback should be returned. I'll check this again later.
  19. Chee Kiat Ng 2015-12-03

    [~htbryant] Sorry i was confused. in case 1, the callback will not be returned and that's the expected behavior. It's the same in 5.1.1.GA.
  20. Fokke Zandbergen 2015-12-03

    Now I'm confused [~cng], because case 1 was exactly why I created this ticket. The callback should be returned at all times.
  21. Srikanth Sombhatla 2015-12-03

    Issue seems to be with not running on main thread which I was unable to emulated when running in Xcode. This PR should address the issue. PR master: https://github.com/appcelerator/titanium_mobile/pull/7539 PR 5_1_X: https://github.com/appcelerator/titanium_mobile/pull/7540
  22. Angel Petkov 2015-12-03

    New PR: (Master) https://github.com/appcelerator/titanium_mobile/pull/7541. New PR :(5_1_X) : https://github.com/appcelerator/titanium_mobile/pull/7542 This will fix the issue where the callback will be called before the user grants/deny's permissions , the call back will now also display success if the user grants permission.
  23. Harry Bryant 2015-12-07

    Verified as fixed, tested the sample code with sdk build 5.1.2.v20151206185250 and following callbacks are received: Case 1: Permissions Granted 
        [INFO] :   Before Callback
    [INFO] :   In Callback
    [INFO] :   {
    [INFO] :     "success": true,
    [INFO] :     "authorizationStatus": 3,
    [INFO] :     "code": 0
    [INFO] :   }
    Case 2: Permissions Denied 
        [INFO] :   Before Callback
    [INFO] :   In Callback
    [INFO] :   {
    [INFO] :     "success": false,
    [INFO] :     "code": 1,
    [INFO] :     "authorizationStatus": 2,
    [INFO] :     "error": "The user denied access to use location services."
    [INFO] :   }
    Before Callback is returned once clicking "Request Permissions", and In Callback is returned after setting either Allow, or Don't Allow. Tested on: iPhone 6s Plus Device (9.1) & Simulators (9.1) , (8.4) Mac OSX El Capitan 10.11 (15A284) Studio: 4.4.0.201511241829 Ti SDK: 5.1.2.v20151206185250 Appc NPM: 4.2.2 App CLI: 5.1.0 Xcode 7.1(7B91b) Node v4.2.2 production *Closing ticket.*
  24. Collin Price 2015-12-31

    Callback is being invoked but on the wrong thread. Pull request discussion (https://github.com/appcelerator/titanium_mobile/pull/7597).
  25. Wilson Liaw 2016-01-20

    still facing this problem occasionally on SDK 5.1.2
  26. Angel Petkov 2016-01-20

    Hello , are you able to reproduce the issue using the code presented above or your own ? If you are using your own could you please post it here and the steps required to reproduce it. Thank you! If the issue persists we'll re-evaluate the fix. Thank you!
  27. Wilson Liaw 2016-01-21

    can't find a way to reproduce so far, once I find it will update here, thanks
  28. Fokke Zandbergen 2016-01-21

    I've also seen it with 5.1.2.GA, where I was using it as a fallback in a timeout after monitoring for location changes (which don't fire if the user is not moving apparently). Could that be related since under the hood this method uses the same listener? https://github.com/appcelerator/titanium_mobile/blob/master/iphone/Classes/GeolocationModule.m#L580
  29. John Dalsgaard 2016-02-08

    I have this problem pretty consistently for Android 6.0 - and it also seems to work in the Ti 5.1.0 demo app... :-/ I first load the map and then call a function to verify the permissions - and parse a callback function to set the position if user has permission - or gives it (in which case it fails)
  30. Hans Knöchel 2016-02-08

    [~jda] This ticket is iOS related and fixed in 5.2.x, I think there is another one android-related, [~fokkezb] will be able to assist.
  31. John Dalsgaard 2016-02-08

    Ok, thanks Hans :-)

JSON Source