Closed Bug 935451 Opened 7 years ago Closed 6 years ago

Test failure "Geolocation position is: Position acquisition timed out" in /testGeolocation/testShareLocation.js

Categories

(Mozilla QA Graveyard :: Mozmill Tests, defect, P2)

x86_64
All
defect

Tracking

(firefox27 wontfix, firefox28 fixed, firefox29 fixed, firefox30 fixed, firefox31 fixed, firefox-esr24 unaffected)

RESOLVED FIXED
Tracking Status
firefox27 --- wontfix
firefox28 --- fixed
firefox29 --- fixed
firefox30 --- fixed
firefox31 --- fixed
firefox-esr24 --- unaffected

People

(Reporter: cosmin-malutan, Assigned: AndreeaMatei)

References

()

Details

(Keywords: intermittent-failure, Whiteboard: [mozmill-test-failure])

Attachments

(2 files, 1 obsolete file)

Failed today on Mac 10.8.5 x64, with Aurora de
http://mozmill-daily.blargon7.com/#/functional/report/d17690a112360a2b3155acaa276cfd8c

This is most likely a network issue. If it will fail again I suggest we increse the timeout for retrieving the geolocation.
If its a network issue any increase will not help. And I'm even against it increasing it once more. The timeout we currently have is long enough. If there is an underlying issue that one has to be fixed instead.
Failed again with "Geolocation position is: Unknown error acquiring position"

On Linux 13.04 x86 with Nightly it; 
Machine mm-ub-1304-32-4 
http://mozmill-daily.blargon7.com/#/functional/report/21341f02f219acb032f628de85332c43

I connected on the affected node and "Position acquisition timed out" it reproduced every time for about 10 minutes, then it started  working.
So which API are we using by default on Linux for getting the position? Given that the nodes are not connected to the WLAN it has to be IP address based? We might have to get this information from devs and if it turns out those are network issues, IT has to fix them.
Failed again as in comment 2 "Geolocation position is: Unknown error acquiring position"

This time on Windows 8, 28.0a1, it:
http://mozmill-daily.blargon7.com/#/functional/report/2f1ca72938985fc4b989b7efcce31841
And again today on Mac OS X 10.7.5 (x86_64) with Firefox 28.0a1 fr:
http://mozmill-daily.blargon7.com/#/functional/report/456bebe92845279408c15c03e8f5b904
This is still failing from time to time:
http://mozmill-daily.blargon7.com/#/functional/report/40742e0746fd767e6d2fd586590bea2f
Priority: P5 → P3
Whiteboard: [mozmill-test-failure]
It failed again with "Geolocation position is: Unknown error acquiring position"
on Nightly it / Windows 8.1 x86
http://mozmill-daily.blargon7.com/#/functional/report/94e33fe3d7ec0be6dbbfa0a702160e14
Still fails every now and then.

Not sure what we should/can do about this since this might very well be a network reliability issue in returning the geoposition.
Yes, it is. And that's why the test should have been in the remote testrun. It will be moved together with the other remaining ones on bug 967456.
Duplicate of this bug: 971007
Failed again with Nightly en-US on Windows 8.1 x86
Date: Feb 15, 2014 6:14:28 AM
Node: mm-win-81-32-4

Report:
http://mozmill-daily.blargon7.com/#/functional/report/0100465a763e4862d400405384503970
Failed on Nightly en-US too on the same time frame on Windows 7 x86
Date: Feb 15, 2014 6:28:35 AM
Node: mm-win-7-32-4

Report:
http://mozmill-daily.blargon7.com/#/functional/report/0100465a763e4862d40040538451660d
I wonder if we should update the test page to handle the error callback for the geolocation request call. That way we could pass along a better error message.
Here we already use the Error message returned by the API, what we could do more would be to get the error code also, which is basically the same thing.

http://mxr.mozilla.org/mozilla-central/source/dom/src/geolocation/nsGeolocation.cpp#424
Duplicate of this bug: 974582
Failed on Nightly fr on win 8.1
Date: Feb 21, 2014 6:56:09 AM
Node: mm-win-81-32-1

Report:
http://mozmill-daily.blargon7.com/#/functional/report/6062fdddb60e88657bc78ec1f493d70e
Failed on Aurora en-US on Mac OS X 10.6.8 (x86_64)
Date: Feb 22, 2014 2:33:12 AM
Node: mm-osx-106-3

Report
http://mozmill-daily.blargon7.com/#/functional/report/6062fdddb60e88657bc78ec1f498b300

Failed on Nightly en-US on Linux Ubuntu 13.10 (x86_64):
Date: Feb 22, 2014 5:16:45 AM
Node: mm-ub-1310-64-3

Report:
http://mozmill-daily.blargon7.com/#/functional/report/6062fdddb60e88657bc78ec1f4a6d6ad
Failed today several times

Nightly en-US on Max OS X 10.7 (x86_64)
Date: Feb 25, 2014 4:42:30 AM
Node: mm-osx-107-1

Report:
http://mozmill-daily.blargon7.com/#/functional/report/6062fdddb60e88657bc78ec1f4fa6bed
--

On Aurora fr on Ubuntu 12.10 32bits
Date: Feb 25, 2014 4:46:16 AM
Node: mm-ub-1310-32-4

Report:
http://mozmill-daily.blargon7.com/#/functional/report/6062fdddb60e88657bc78ec1f4fb0dbf

--
On Nightly en-US on Mac OS X 10.9 
Date: Feb 25, 2014 4:42:32 AM
Node: mm-osx-109-3 

Report:
http://mozmill-daily.blargon7.com/#/functional/report/6062fdddb60e88657bc78ec1f4fa5e79
--
On Nightly de on Windows Vista 32bits
Date: Feb 25, 2014 4:55:21 AM
Node: mm-win-vista-32-1

Report:
http://mozmill-daily.blargon7.com/#/functional/report/6062fdddb60e88657bc78ec1f4fd1d48
Node: mm-win-vista-32-1

--
On Nightly de on Windows 8.1 x64
Node: mm-win-81-64-2

Report:
http://mozmill-daily.blargon7.com/#/functional/report/6062fdddb60e88657bc78ec1f4fd1917
Feb 25, 2014 4:55:29 AM
Attached patch disable_testGeolocation.patch (obsolete) — Splinter Review
Way too many failures today on this. 
It may occur a lot of network issues when trying to obtain the geolocation data.

Let's skip this test until this calms down.
Attachment #8381420 - Flags: review?(andreea.matei)
Comment on attachment 8381420 [details] [diff] [review]
disable_testGeolocation.patch

Review of attachment 8381420 [details] [diff] [review]:
-----------------------------------------------------------------

It didn't fail anymore, it was certainly a network issue, lets not skip it for now.
Attachment #8381420 - Flags: review?(andreea.matei)
Firefox 28 has merged to release so this is wontfix for Firefox 27.

I'm seeing two Geolocation failures in 28.0build1, not sure if they're related to this:
http://mozmill-release.blargon7.com/#/functional/report/d8c9b09561f242bc8489be43d6065c6f
http://mozmill-release.blargon7.com/#/functional/report/3d7ca01655bfd2044736c8e06f0a76bf
Duplicate of this bug: 984725
As filed as bug 984725 we have massive fallouts of this test in Firefox 31 on Windows and Linux now. Please get this investigated.

http://mozmill-daily.blargon7.com/#/functional/top?app=All&branch=31.0&platform=All&from=2014-03-17&to=2014-03-18

If we can help Juan with the investigation of the problem lets do it on bug 979940.
Depends on: 979940
Priority: P3 → P1
This failed for 100 times and it still fails so we should skip.
Comment on attachment 8381420 [details] [diff] [review]
disable_testGeolocation.patch

Review of attachment 8381420 [details] [diff] [review]:
-----------------------------------------------------------------

Daniel, would you please update this skip patch. Due to massive recent failures we might need to land this.

::: firefox/tests/functional/manifest.ini
@@ +6,5 @@
>  disabled = Bug 930509 - Window has been found.
>  [include:testFindInPage/manifest.ini]
>  [include:testFormManager/manifest.ini]
>  [include:testGeolocation/manifest.ini]
> +disabled = Bug 935451 - Test failure "Geolocation position is: Position acquisition timed out" in /testGeolocation/testShareLocation.js

Please remove the fire reference.

::: firefox/tests/functional/testGeolocation/testShareLocation.js
@@ +68,5 @@
>    }
>  }
> +
> +setupModule.__force_skip__ = "Bug 935451 - Test failure \"Geolocation position is: Position acquisition timed out\" in /testGeolocation/testShareLocation.js";
> +teardownModule.__force_skip__ = "Bug 935451 - Test failure \"Geolocation position is: Position acquisition timed out\" in /testGeolocation/testShareLocation.js";

Please remove the file reference and to simplify things a bit change the double quotes to single quotes so we won't need to escape them.
Attachment #8381420 - Flags: review-
Updated the disable patch.
Attachment #8381420 - Attachment is obsolete: true
Attachment #8392766 - Flags: review?(andrei.eftimie)
I checked with an older Firefox and we get the same Error, also with other browsers(Google).
Comment on attachment 8392766 [details] [diff] [review]
disable_testGeolocation2.patch

Review of attachment 8392766 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks for the quick update.

Disabled: http://hg.mozilla.org/qa/mozmill-tests/rev/c5925afd6eb1 (default)
Attachment #8392766 - Flags: review?(andrei.eftimie)
Attachment #8392766 - Flags: review+
Attachment #8392766 - Flags: checkin+
I'm unable to get my position vie Bing either...

We'll need to disable this test across all branches.
As mentioned on bug 979940 let get logging enabled for geo location, and run the tests manually to see the corresponding failure details.
Andrei, so esr24 is not affected? Can you please check which version started to fail? I think that would help a lot here. Best is to comment on bug 979940 with that info.
Added the pref as requested.

Here's the output:
*** WIFI GEO: startup called.
*** WIFI GEO: Sending request: https://www.googleapis.com/geolocation/v1/geolocate?key=AIzaSyD-s-mXL4mBzF7KMRkhTCIbG2RKnRGXzJc
*** WIFI GEO: sending {"wifiAccessPoints":[]}
*** WIFI GEO: gls returned status: 404 --> {"error":{"errors":[{"domain":"geolocation","reason":"notFound","message":"Not Found"}],"code":404,"message":"Not Found"}}
*** WIFI GEO: shutdown called
ERROR | Test Failure | {
Assignee: nobody → andreea.matei
Status: NEW → ASSIGNED
Attachment #8393370 - Flags: review?(andrei.eftimie)
(In reply to Andreea Matei [:AndreeaMatei] from comment #35)
> *** WIFI GEO: gls returned status: 404 -->
> {"error":{"errors":[{"domain":"geolocation","reason":"notFound","message":

Interesting that the URL does not exist. I wonder if we can get this error message into the error details of the geolocation test. Is that possible?
(In reply to Henrik Skupin (:whimboo) from comment #34)
> Andrei, so esr24 is not affected? Can you please check which version started
> to fail? I think that would help a lot here. Best is to comment on bug
> 979940 with that info.

We don't have this test landed on ESR24.

Now, where do we gather the geolocation position from?
I assume it's through some 3rd party API? Is the OS providing us with the actual data?
I find this functionality broken across multiple browsers (Firefox, Chrome, Safari) and providers (Google, Bing).
Comment on attachment 8393370 [details] [diff] [review]
patch v1 - add pref

Review of attachment 8393370 [details] [diff] [review]:
-----------------------------------------------------------------

This looks ok.

Just wondering it its ok to expose our GOOGLE_API_KEY...
Attachment #8393370 - Flags: review?(andrei.eftimie) → review+
Everyone by setting this pref or with a network sniffer can get it, right?
I think you're right that it is being sent in clear.

The test is skipped right now, so I'm landing this across branches directly.

Landed:
http://hg.mozilla.org/qa/mozmill-tests/rev/b9692eb7d405 (default)
http://hg.mozilla.org/qa/mozmill-tests/rev/0b4b99489361 (mozilla-aurora)
http://hg.mozilla.org/qa/mozmill-tests/rev/f1e47c68fae4 (mozilla-beta)
http://hg.mozilla.org/qa/mozmill-tests/rev/fe08defe3a0c (mozilla-release)
We talked about this problem in the qa desktop meeting. What we got out of it is that we might also want to check other providers like our own one, or/and have a mockup services via mozqa.com or httpd. The latter would not be affected by network glitches.

Information about our own service can be found here:
http://mozilla-ichnaea.readthedocs.org/en/latest/api/geolocate.html
(In reply to Henrik Skupin (:whimboo) from comment #41)
> We talked about this problem in the qa desktop meeting. What we got out of
> it is that we might also want to check other providers like our own one,
> or/and have a mockup services via mozqa.com or httpd. The latter would not
> be affected by network glitches.

Yeah, that's a good idea to also test mozilla's API's.

I can't understand the second point, which is to mock the service? In what way? Always return the same or maybe a random position? Will that really help us in any way? I don't think we would be able to properly geolocate any position. I fail to see how we could have this test run without network connectivity.
A mock service exists to fake a specific feature you want to test. In this case it would be the geolocation API backend. Whatever we want to get tested, all could be setup via a static or dynamic reply. Personally I would propose to use httpd.js.
This is working again, re-enabled:
http://hg.mozilla.org/qa/mozmill-tests/rev/35ecfeba55e7 (default)
http://hg.mozilla.org/qa/mozmill-tests/rev/78f132c07bb9 (aurora)
http://hg.mozilla.org/qa/mozmill-tests/rev/34f261f1e0d3 (beta)
http://hg.mozilla.org/qa/mozmill-tests/rev/232961d727f6 (release)

Leaving this open as we might want to use a mockup service after all and to check it's not failing again intermittently.
Hi Andreea, I noticed the tests are failing still, up to 4-11-2014. Should you reopen the bug? 
http://mozmill-daily.blargon7.com/#/functional/top?app=All&branch=All&platform=All&from=2014-03-26&to=2014-04-16
Flags: needinfo?(andreea.matei)
Hi Liz, the bug is still open, but the test was skipped in bug 994040 and was failing since April 9th due to another issue (a regression). 
This failure in particular we haven't seen it since it was enabled on March 26th. We left the bug open in case this kept failing and we'd want a mockup service. Since it was skipped a week later, I'll keep this open a bit longer, to re-enable it and see what's the state then.
Flags: needinfo?(andreea.matei)
Which backend failures did we get for those test failures? We enabled the output in the logs. So it would be helpful to know here.
This has been unskipped by bug 994040 on Friday, didn't fail since then, I'll keep an eye for the next days.
Priority: P1 → P2
Failed with Aurora (Firefox 32.0a2 en-US) on mm-win-8-32-3 (20140614004002)

05:35:04 TEST-START | testGeolocation\testShareLocation.js | setupModule
05:35:05 TEST-START | testGeolocation\testShareLocation.js | testVerifyDisplayGeolocationNotification
05:35:05 *** WIFI GEO: startup called.
05:35:35 ERROR | Test Failure | {
05:35:35   "exception": {
05:35:35     "message": "Geolocation position is: Position acquisition timed out", 
05:35:35     "lineNumber": 79, 
05:35:35     "name": "Error", 
05:35:35     "fileName": "file:///c:/jenkins/workspace/mozilla-aurora_functional/data/mozmill-tests/firefox/tests/functional/testGeolocation/testShareLocation.js"
05:35:35   }
05:35:35 }
05:35:35 TEST-UNEXPECTED-FAIL | testGeolocation\testShareLocation.js | testVerifyDisplayGeolocationNotification
05:35:35 TEST-START | testGeolocation\testShareLocation.js | teardownModule
05:35:35 TEST-END | testGeolocation\testShareLocation.js | finished in 30570ms

I also see this at the end of the testrun:

05:36:57 *** WIFI GEO: shutdown called
05:36:57 
Several lines with:
05:36:57 ###!!! [Child][DispatchAsyncMessage] Error: Route error: message sent to unknown actor ID
05:36:57 

We can make this test not depending on google geolocation with a local input data file, like in bug 1008913.
Isn't this test obsolete when we get all the other tests landed?
No, the test was unskipped by bug 994040.
Since this test was unskipped again, adding a need info to recheck in a few days if we encountered the failure again.
Flags: needinfo?(andreea.matei)
Hasn't failed anymore.
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Flags: needinfo?(andreea.matei)
Resolution: --- → FIXED
Product: Mozilla QA → Mozilla QA Graveyard
You need to log in before you can comment on or make changes to this bug.