Well then, it seems I need to build a test app from scratch, maybe there are some side effects in my actual app. But the code for that app ran just fine on iOS5 and still does on other mobile OSes ...
But this comment in the above mentioned approach makes me wonder if this isn't some sort of twisted timing issue which popped up only in iOS 6 after all ...
"make this setTimeout delay one second longer than your watchPosition() timeout"
Ok, I created a basic UI for the code in http://stackoverflow.com/a/14410106/818266. It acquires the position on page load and has a refresh button for position updates on the open page. See here: http://xctrails.org/gc/locTest.html
After the page load, wait a bit, or task switch to another app and back, then press refresh, sooner or later, in my tests on a 6.1 4S and a 6.1 3GS the accuracy will increase significantly and the position data will be basically be worthless. At that point, the browser needs to be terminated and restarted to get out of that state. This goes in line with what the author of the above code said in his post: "this doesn't seem to work as consistently if the execution of this code it delayed at some point after initially launching the app".
As mentioned, running a native app with continuous GPS access in the background "solves" this problem.
Seems to be working fine with the 6.1.2 update. Once the website is loaded, the watch fires right away, and keeps updating the location accordingly. When the safari window is closed, the location service seems to go into some kind of idle status. When you expand the Safari window again, the location service resume the updating... I had the same issues as described in the above posts, but installing iOS 6.1.2 first on iPhone4, then on iPad2 was the trick Enjoy folks!
This issue seems to be a real disaster for anyone writing webbased geolocation applications. Please all make sure you have submitted a bug report to apple at bugreport.apple.com! (I have also submitted a TDS ticket).
Has anyone tested this with iOS 6.1.3 beta?
The discussion here as well as these two SO posts seems to be the same problem:
I have put together a testpage that you can use if you want to investigate this problem:
Open http://jsbin.com/esasix/16/ in your iPhone or iPad.
Walk around outside, refresh the page and try other test scenarious.
Watch how your position is being reported.
I have done a lot of testing myself with the following results:
Own tests using this simple test page: jsbin.com/esasix/16/
Own tests using maps.google.com mobileweb map
Own tests using my application
Many logs from external users of my application
Tested using different devices
At the same testsituation I often get perfect positioning regularly with 5m accuracy as well as poor reception caused by the bug. This means that the device, location, weather, time of day etc. is the same in both situations.
Sometimes only one position is returned after loading page.
Sometimes a few positions are returned after loading page.
Sometimes a number of good positions are returned then suddenly it stops returning positions (sometimes this occurs after standing still for a while) and it goes into a bad state, possibly returning positions again but often bad ones.
Sometimes many positions are returned with accuracy 65m.
Sometimes many positions are returned with varying bad accuracy (typically 50-300m).
These series of positions with bad accuracy are sometimes close to series of perfect ones with 5m accuracy (after it has entered the bad state?).
Sometimes everything works fine for many tests in succession...
These behaviours seems to appear in various combinations.
In some situations re-opening Safari seems to re-set something and it starts working again. However, in some of those situations it then only worked for a while and in other situations it had no effect att all so it can be used as a reliable work-around(?). The same behaviour is shown when opening the built in maps application, sometimes it helps, sometimes it does not...
Have tested with code that uses navigator.geolocation.watchPosition as well as code that calls navigator.geolocation.getCurrentPosition in a loop at regular intervalls and it has not made any difference, same type of problems can be seen in both cases.
Seems to occur for iOS version 6.0 to 6.1.2 I am not using the apple-mobile-web-app-capable meta tag.
I have found that sometimes a particular testsituation appears to show a specific behaviour leading to conclusions being made but then another test proves that conclusion wrong. I have not yet been able to find any behaviour (nor solution) that is reliably reproducable.
I posted on this forum a few months ago when when watchPosition wasn't updating correctly in a chromeless web app saved to your homepage from safari (worked fine IN Safari). Since the last 2 IOS point releases it has worked fine. The issue seems to have been fixed. Now while driving, it continuously updates my position.
I think this thread has become convoluded with different issues that are all related due to the fact that they use geolocation. As far as I can tell the issue this thread was created for has been fixed. At least on my iphone5.
I agree with 73Hpilo.
My suspicion is that one stabilty issue is the root of it all but since it is not predictable in its behaviour it may sometime seems that the problem is gone. However, I can be wrong on this and in that case I would be really happy!
travisdahl and 73Hpilo can you do me a big favour? Can you open http://jsbin.com/esasix/16/ in your phones, go outside and walk around for a bit? Do you get steady 5 or 10 accurracy levels, even after re-loading the page a couple of times? As you can see on jsbin this is really basic watchPosition code.
When I did this just now I first got great numbers as these:
count timediff distdiff accuracy
4 00:01.065 1 5
3 00:01.003 3 5
2 00:00.980 0 5
1 00:00.765 0 5
0 00:01.157 0 5
But after my forth re-loading of the page I started getting just one position then nothing, at some occation 3 signals then nothing (tried 2 different devices).
I get logging from many users with different devices in different locations for my service and from what I see there is a lot of weird behaviour on 6.1.2 as well...?
iOS 6.1.3 beta users can't talk about it but they can perhaps tell us if they think that geolocation api users have a stable future ahead of them or something ;-)
I still really think nothing has been done to fix this issue. This has been introduced in iOS6 since now apps prompts user for permission to do something locally (which is good, i guess). Since a chromeless HTML view is not inside Safari, it can't inherit its geolocation access permission. But since it's not an installed app neither, i does not exists in Settings, neither registered in iOS as an app.
That's why i really think the geolocation API asks for a permission to get this data, but can't figure out which app is asking for it (no app unique identifier) so the process kinda fail. I guess if Safari has been opened in the last few seconds, its "session" makes the chromeless app inherits its permission.
Just my $0.00002...
Apple has nothing to gain by fixing this bug. Webapps don't make Apple money.
Apple has not updated their webapp page in years. Which speaks volumes on their incentive to fix bugs like this in Safari.
Okay, it is a simple issue to replicate in just a few seconds. I feel it is not a safari, but an IOS issue. It’s almost as if Google wrote the bios for the IOS to meet the WC3 html geo location spec and took it with them when IOS6 kicked them off the bus.
Using an IOS device go here:
- Click start, watch should return result almost every second.
- Then click the Google link to leave this page.
- Then user browser back button to return
- Click start.
- Watch will return 1 to 3 records and hang.
Thats it. untill it does not hang, the issue remains.
Tried your simple app now alstorp... im actually indoor to make it even more interesting... refreshed your page 10 times with Safari as the only application running on iPad 2 with iOS 6.1.2. No other maps or anything else in the background. Watch returns good points indicating accuracy 5 to 10 and correct location on the map. I aborted each test at 100 good returns. This is exactly the same experience i have with my own application - everything changed after i updated from an early iOS 6 to iOS 6.1.2...
I even tried my application driving through some tunnels in Norway, testing the error catching functions and it responded correctly; GPS signal lost, reverting to other means of getting approximate position. Immediately when getting out of the tunnel, the app resumed tracking with accurate positions without any user intervention at all.
I really cant say that my initial problem persist anymore.
Just as a footer, i left my iPad running your app one last time, and it has now passed 500 good returns with a rate of 1 pr sec...
Thanks 73Hpilot! That was very interresting...
Did a few more tests, every time walking back and forth outside the house:
(the script simply logs watchPosition responses for those that have not looked at it)
1. Tested an iPad1 running 5.1.1, reload 10+ times and no problems as expected.
2. Closed all apps and all pages on my iPhone 4S running 6.0.1 and rebooted. Worked 3 reloads then I got 3 pos, 1 pos a few more etc. all the time. Each time I closed Safari and re-opened the positions started coming again (this often fixes the problem but not all the time according to my experience)
3. Tested on my girlfriends iPhone 4S running 6.1.2, closed all apps & pages and rebooted. Already on 2:nd reload I only got 1 position, then similar results 1 or a few positions, always restarted after reopening Safari.
Tried turning off wifi, but got exactly the same behaviour.
Example of a typical testresult after page refresh:
2 00:00.431 11 65
1 00:00.181 4 165
0 00:00.709 0 65
...got 3 positions then nothing...
mark00153, tested you page and got exactly the same result as above. Positions stopped as you describe and as I experience above, restarted if I reopened Safari. This was as expected as both our test run very basic code.
So, now to the interresting part: what is different in 73Hpilot and my tests? Here's what I can think of:
* We obviously have different hardware
* We are at different pysical positions meaning different satellites etc. (I am in Sweden)
* I was walking back and forth outdoors, 73Hpilot was indoors (being still?)
I tested indoors sitting still and then I could actually refresh the page > 10 times with continous positions (I think I have read that if the GPS chip does not detect enough differences in signals it returns the previous position....?)
73Hpilot, it would be very interresting to hear what results you get if you go outside and walk while doing the tests...?
Anyone else who can try testing? travisdahl?