Closed Bug 925346 Opened 6 years ago Closed 6 years ago

Test failure "Geolocation position has been found" in /testGeolocation/testShareLocation.js

Categories

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

x86
All
defect

Tracking

(firefox27 fixed)

RESOLVED FIXED
Tracking Status
firefox27 --- fixed

People

(Reporter: cosmin-malutan, Assigned: cosmin-malutan)

References

()

Details

(Whiteboard: [mozmill-test-failure])

Attachments

(1 file, 1 obsolete file)

This failed twice today on Mac 10.8.5 (x86) with Nightly it and on Windows 8 (x86) with Nightly de.

I tried to reproduce this on the affected machine (mm-win-8-32-3) without success.


http://mozmill-daily.blargon7.com/#/functional/report/6d6f6a58b02eeffc06eafa8beac909b2
Priority: -- → P3
It seems this will fail if we don't have WiFi enabled, see bug 923618
But if this would be the case shouldn't we fail *every* time on OSX?

I'll set it as a blocker since a patch is in review and will probably land soon.
We have 1 instance of it failing on Windows, has to be a different reason for it on Windows.

Assigning this to Andreea since she has the most knowledge about geolocation as the author of the test.
Assignee: nobody → andreea.matei
Status: NEW → ASSIGNED
Depends on: 923618
Yeah, I don't see a hard connection between both. But if it is really related to WIFI why it hasn't been failed earlier? I strongly believe that's another issue here.
I'll run some testruns on a free OS X machine to see if it reproduces at some point.
Good news: Cosmin and I were able to get it reproduced on a Windows 7 VM, once out of 10 testruns. Now I can fully investigate this and get at the bottom of the issue. But first I need to get the metro work done as it has higher priority.
Reproduced manually? If that is the case someone should file a bug for Windows. Also which version of Firefox? I wonder if that is the same as reported lately on bug 888252.
Not manually, in testruns only. It was with Nightly, only there we have the test so far. On CI the failures were on Windows 7 and on OS X only. But with OS X I couldn't reproduced, tried about 30 testruns.
Reassigning to Cosmin who wants to work on this and I have metro as a priority at the moment.
Assignee: andreea.matei → cosmin.malutan
Hi, I had a look in to this.
When it fails the actual error is "Position acquisition timed out". It fails at least once in 100 runs. So I will try to find a fix and return with a patch soon.
Attached patch patch_v1.0 (obsolete) — Splinter Review
I increased the timeout for geolocation call, and for assertion, and I also updated the assertion fail message, so if it will fail in the future we will know the actual reason we did't get the position.

Reports:
http://mozmill-crowd.blargon7.com/#/functional/report/95c9c51e8c2d9f14917fc749dd61ee15
http://mozmill-crowd.blargon7.com/#/functional/report/95c9c51e8c2d9f14917fc749dd61fbb6
http://mozmill-crowd.blargon7.com/#/functional/report/95c9c51e8c2d9f14917fc749dd61e775
Attachment #822215 - Flags: review?(andrei.eftimie)
Attachment #822215 - Flags: review?(andreea.matei)
Comment on attachment 822215 [details] [diff] [review]
patch_v1.0

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

::: data/geolocation/position.html
@@ +16,5 @@
>        result = document.getElementById("result");
>  
>        if (navigator.geolocation)
>          navigator.geolocation.getCurrentPosition(handlePosition, handleError,
> +                                                 {enableHighAccuracy: false, timeout: 30000});

Don't forget to update this file in the testcase-data repository too.
Comment on attachment 822215 [details] [diff] [review]
patch_v1.0

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

Seems reasonable.

Only 2 small nits to fix:

::: tests/functional/testGeolocation/testShareLocation.js
@@ +62,5 @@
> +  try {
> +    assert.waitFor(function () {
> +      return regExp.test(result.getNode().textContent);
> +    }, "", TIMEOUT_POSITION);
> +  } catch (e) {

nit: new line here

@@ +63,5 @@
> +    assert.waitFor(function () {
> +      return regExp.test(result.getNode().textContent);
> +    }, "", TIMEOUT_POSITION);
> +  } catch (e) {
> +    assert.fail("Geolocation position got : '" + result.getNode().textContent + "'");

"Geolocation position is: "
Attachment #822215 - Flags: review?(andrei.eftimie)
Attachment #822215 - Flags: review?(andreea.matei)
Attachment #822215 - Flags: review-
Attached patch patch_v1.1Splinter Review
I updated the patch.
Thanks
Attachment #822215 - Attachment is obsolete: true
Attachment #822246 - Flags: review?(andrei.eftimie)
Attachment #822246 - Flags: review?(andreea.matei)
Happened again today on Windows with Nightly 27 'de':
http://mozmill-daily.blargon7.com/#/functional/report/95c9c51e8c2d9f14917fc749dd86d06f
Depends on: 930959
Comment on attachment 822246 [details] [diff] [review]
patch_v1.1

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

Great! Lets see if this fixes the issue.

Pushed:
http://hg.mozilla.org/qa/mozmill-tests/rev/67600b9f0842 (default)

This will be merged today along with the test in aurora as well. For beta I will backport the test and this fix in a single patch in bug 758187, so we can close this bug now.
Attachment #822246 - Flags: review?(andrei.eftimie)
Attachment #822246 - Flags: review?(andreea.matei)
Attachment #822246 - Flags: review+
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Product: Mozilla QA → Mozilla QA Graveyard
You need to log in before you can comment on or make changes to this bug.