Currently Being ModeratedMar 12, 2013 3:37 AM (in response to alstorp)
I just tested http://jsbin.com/esasix/16/ :
After a couple of page reloads, updating stopped with the dreaded 165 accuracy. At this point, I backgrounded Safari, started MotionX GPS, which promtply acquired a sigal with 10, accuracy, switched back to Safari and it continued updating. This is exactly the same behavior as with my test app - which btw works flawlessly on non iOS devices and on iOS < 6.
Currently Being ModeratedMar 12, 2013 7:08 AM (in response to MikeAtNextBus)
So... Native apps always return correct positions (for me and, I assume, for all others). This means we have some low level hardware api that seems to report correct positions to the native CoreLocation.framework.
Anyway, an interresting thing to know would be if the geolocation code is made by apple themselves or if they get it from webkit and only port it to their hardware layer? If they get it from webkit then is it possible for us to get hold of someone with inside knowledge about this issue? Should we perhaps file a bugrequest in Bugzilla?
If we get hold of the right person assigned to this bug then perhaps we as a community can help with input (and/or perhaps also put some pressure on getting it fixed...)?
Currently Being ModeratedMar 13, 2013 12:42 PM (in response to MikeAtNextBus)
Today was bad, nither me nor a customer of mine could get any proper data even when reopening, restarting, starting native etc. yet iPad running 5.1.1 returned perfect 5 or 10 in accuracy... I can't promote my app or service anymore due to this since most of my customers attempts fail.
I have had the usual problems with position not comming at all in some cases, getting 65 and worse in accuracy together with bad positions in other cases.
Something I have also seen quite a bit lately is steaks of returning error code 3 = TIMEOUT every second for awhile.
Another thing I have been seeing is positions going cracy in linear patterns... In the photo below the guy was standing still aproximately 100m from the blue marker at the top, when suddenly his own position started to move away as shown. Here's a section of the returned positions (nr, time, dist to blue marker, accurracy)
99 01:35.250 P 812m 448a
98 01:34.243 P 812m 448a
97 01:33.309 P 807m 448a
96 01:32.254 P 786m 433a
95 01:31.237 P 786m 433a
94 01:30.305 P 779m 433a
93 01:29.235 P 755m 418a
92 01:28.234 P 755m 418a
91 01:27.370 P 745m 418a
90 01:26.241 P 718m 402a
89 01:25.227 P 718m 402a
88 01:24.303 P 706m 402a
87 01:23.232 P 675m 386a
86 01:22.225 P 675m 386a
85 01:21.288 P 661m 386a
I have seen similar logs from other users on other devices. Anyone else who have experienced results like this? The code behind this is very basic and again, the same code running iOS 5 performs perfect...
(The TDS ticket resulted in nothing, they can't look into bugs...)
(Have also contacted someone at webkit in an effort to get hold of someone with knowledge but no response so far)
Currently Being ModeratedMar 25, 2013 3:37 AM (in response to MikeAtNextBus)
This issue has not been fixed in 6.1.3. Upgraded and tested on two devices. I only get good 5/10 accuracy for short periods on few occasions but most of the time I get faulty positions (with accuracy 65 or worse) or I don't get any signals at all = same as before. Logs for my application now shows that close to 100% of iPhone users fails when geolocation is used to track their position in Safari...
Test using http://jsbin.com/esasix/16/ and share your results (note, test multiple times doing refreshes and open/close of browser).
I've not heard anything from Apple in response to my bug-report. Has anyone received any response? Have they acknowledged the problem? Will it be fixed next month or next year? As I see it this has been a serious problem since the September release of 6.0.
Unfortunately it seems that the number of developers using browser based tracking (geolocation.watchPosition) in real applications is not large enough for Apple to address this problem.
They of course prioritise all their bugs and weigh the benefit of fixing them against the risk of compromising stability and whether they should put recources on fixing bugs in existing versions or working on the next one. I suspect they are very restrictive on which bugs they allow to be fixed in minor version upgrades which can mean we have to wait until 7.0 (September?) or longer...?
If only Apple would talk...
Currently Being ModeratedJul 30, 2013 1:01 AM (in response to CesarBasurto7)
I had reported a bug for this in February - now Apple has responded:
"Does this issue also occur with iOS 7 beta 4 (11A4435d)?"
can anyone check this? (I don't have iOS 7 yet) (my test page www.xctrails.org/gc/locTest.html is still up.
Currently Being ModeratedJul 31, 2013 4:56 AM (in response to XCTrails)
I can no longer get this issue using iOS 7 beta 4 - 11A4435d (seems like it was fixed in beta 2). I've tried hard to provoke it but everything seems to work fine (on iOS 6 it was easy to reproduce).
I encourage everyone using iOS 7 to test and confirm that this bug is fixed or submit bug rapports to apple if problems are still found. We need many positive confirmations or an official statement from Apple before we can conclude that it has really been fixed.
Test using the following links (note: a few positions with cell or wifi type accuracy in the beginning until the gps get it's position is ok):
http://jsbin.com/acokaj/8 (plots your position, code available)
http://maps.google.com (web version of maps should show correct pos as you walk around)
(XCTrails - I tested using your link as well and it seems to work fine).
Updated my own bug report with this information but I have not received any response or confirmation from apple (ask them to check a bug submitted by Alstorp).
Unfortunately we will have to wait until beginning of October until iOS 7 is in widespread use. I wish Apple would release an 6.X update with this fix but it does not seem likely as they have ignored it for so long already...