839724 - Geolocation cannot get current position

Status: RESOLVED INVALID

(Firefox OS Graveyard :: General, defect)

Description

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

## Environment :
Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/71ddeff45ec2
Gaia   cff23a80c41b7de223d27c6a6f1f82f95c9c5f6b
BuildID 20130208070201
Version 18.0
Unagi
  
## Repro :
1. launch browser
2. go to http://people.mozilla.com/~nhirata/html_tp/geo_testpage.html
3. accept geolocation permission

## Expected :
location of your current position

## Actual :
Your location cannot be determined overlay

## Note :
1. works fine on Mac Firefox Desktop and Fennec 18.0.2
2. regression from bug 833940 ?
3. I tried with and without high accuracy and I get the same result.

Comment 1

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Makes maps a little less useful without this feature.

Comment 2

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

to note: stephend and I were talking about this issue the other day.  his idea for me to look into it.  :)

Comment 3

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Looks like a library load failure, cert failure and then a authentication failure :

02-21 15:32:53.030: E/LocSvc_afw(532): E/const ulpInterface* loc_eng_get_ulp_inf(), dlopen for libulp.so failed, error = Cannot load library: load_library[1091]: Library 'libulp.so' not found
02-21 15:32:53.030: E/LocSvc_eng(532): I/===> int loc_eng_init(loc_eng_data_s_type&, LocCallbacks*, LOC_API_ADAPTER_EVENT_MASK_T, void (*)(void*, void*)) line 245 
02-21 15:32:53.030: E/LocSvc_api_rpc_glue(532): I/---> loc_open line 354 loc client open
02-21 15:32:53.030: E/LocSvc_adapter(532): [ZTE-GPS] efs file doesn`t exist in ARM9 need to inject
02-21 15:32:53.030: D/RPC(532): 3000008c:00050000 sending call (XID 1).
02-21 15:32:53.030: D/RPC(532): 3000008c:00050000 received REPLY (XID 1), grabbing mutex to wake up client.
02-21 15:32:53.030: D/RPC(532): 3000008c:00050000 call success.
02-21 15:32:53.040: E/LocSvc_adapter(532): [ZTE-GPS] Create cert file
02-21 15:32:53.070: E/LocSvc_adapter(532): [ZTE-GPS] certfilesize=0 
02-21 15:32:53.070: E/LocSvc_adapter(532): [ZTE-GPS] No cer file 
02-21 15:32:53.070: E/LocSvc_eng(532): I/===> void loc_eng_agps_init(loc_eng_data_s_type&, AGpsCallbacks*) line 795 
02-21 15:32:53.070: E/LocSvc_api_rpc_glue(532): I/---> loc_ioctl line 557 RPC_LOC_IOCTL_SET_SUPL_VERSION
02-21 15:32:53.070: E/LocSvc_eng(532): I/===> int loc_eng_set_position_mode(loc_eng_data_s_type&, LocPosMode&) line 583 
02-21 15:32:53.070: E/LocSvc_eng(532): I/===> int loc_eng_start(loc_eng_data_s_type&) line 444 
02-21 15:32:53.070: E/RPC(532): 3000008c:00050000 call failed with an authentication error.
02-21 15:32:53.070: E/LocSvc_api_rpc_glue(532): E/loc_ioctl:559] failure code 11
02-21 15:32:53.070: E/LocSvc_api_rpc_glue(532): loc_ioctl failed select_id = 0, ioctl_type RPC_LOC_IOCTL_SET_SUPL_VERSION, returned RPC_LOC_API_RPC_FAILURE
02-21 15:32:53.070: E/LocSvc_adapter(532): W/virtual loc_api_adapter_err LocApiAdapter::setSensorControlConfig(int): default implementation invoked
02-21 15:32:53.070: E/LocSvc_adapter(532): W/virtual loc_api_adapter_err LocApiAdapter::setSensorPerfControlConfig(int, int, int, int, int): default implementation invoked
02-21 15:32:53.070: D/LocSvc_adapter(532): loc_eng_set_position mode, client = 0, interval = 1000, mode = 1
02-21 15:32:53.070: D/LocSvc_adapter(532): [ZTE-GPS]loc_eng_set_position mode(final), client = 0, interval = 1000, op_mode = 2(1-df,2-msb,3-msa,4-st)
02-21 15:32:53.070: E/LocSvc_api_rpc_glue(532): I/---> loc_ioctl line 557 RPC_LOC_IOCTL_SET_FIX_CRITERIA
02-21 15:32:53.070: E/LocSvc_api_rpc_glue(532): I/---> loc_start_fix line 432 loc start fix

Comment 4

[Kan-Ru Chen [:kanru] (UTC+9)]

(In reply to Naoki Hirata :nhirata from comment #3)
> Looks like a library load failure, cert failure and then a authentication
> failure :

They are not fatal errors AFAIK.

We had too many bugs like this. Plain GPS is slow generally, it may take 10 minutes to find a fix in outdoors. When in indoors, you might not get a fix at all.

Comment 5

[Doug Turner (:dougt)]

exactly

Comment 6

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Hi Kanru, I'm trying to understand the situation better.

If the library fails to load, wouldn't that cause an issue with getting the location in the first place?

I'm also trying to understand why Android and iOS are able to detect the geolocation indoors, where ours fail.

Comment 7

[Doug Turner (:dougt)]

do not reopen bugs because you want to get a better understanding.  send him and email so that you don't waste people's time.

Comment 8

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Hi Dougt, thanks for the feedback.  I agree that I don't want to waste dev time on reopened bugs that are not fruitful and I also believe that the bug isn't invalid from an end user perspective.

That is why I reopened the bug.  I believe that a better explanation should be in the bug to explain why the bug is invalid, so that more bugs like this are not created, which in turn would waste more of the developer's time.  Esp if it's only said in email and not in the open like this bug.  
  
If the feature isn't performant on a mobile device, it impacts usability in apps that rely on it such as e.me apps (foodspot, etc.)

I also looked at several other bugs and found that we are using nokia's test server. It appears that I should conduct more tests to gather data and measure the performance of GPS.  Currently the server that the geolocation is pointing to, will cause issues on a mobile device.

Thanks.