Test failure 'Geolocation position is: unavailable' in /testGeolocation/testShareLocation.js

RESOLVED FIXED

Status

Mozilla QA
Mozmill Tests
P1
normal
RESOLVED FIXED
3 years ago
6 months ago

People

(Reporter: cosmin, Assigned: cosmin)

Tracking

({regression})

unspecified
regression

Firefox Tracking Flags

(firefox37 fixed, firefox38 fixed)

Details

(Whiteboard: [mozmill-test-failure], URL)

Attachments

(1 attachment)

(Assignee)

Description

3 years ago
Test:      testVerifyDisplayGeolocationNotification    
Failure:   'Geolocation position is: unavailable'
Branches:  default
Platforms: All

This failed on almost all platforms with latest nightly except for OSX 10.8 and 10.9 
I couldn't reproduce this on OSX 10.7.5 or Ubuntu 14.0 x64

http://mozmill-daily.blargon7.com/#/remote/failure?app=Firefox&branch=All&platform=All&from=2014-12-01&to=&test=%2FtestGeolocation%2FtestShareLocation.js&func=testVerifyDisplayGeolocationNotification
(Assignee)

Comment 1

3 years ago
This runs only on nightly and it reproduces on production nodes so it should be skipped.
Priority: -- → P1
(Assignee)

Comment 2

3 years ago
Created attachment 8534859 [details] [diff] [review]
1109487.patch

Here is the skip patch.
Attachment #8534859 - Flags: review?(mihaela.velimiroviciu)
Attachment #8534859 - Flags: review?(andreea.matei)
Comment on attachment 8534859 [details] [diff] [review]
1109487.patch

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

We need to see what's wrong, maybe we exceeded again a limit here? 
Bug 1060254 was similar a month ago.
Attachment #8534859 - Flags: review?(mihaela.velimiroviciu)
Attachment #8534859 - Flags: review?(andreea.matei)
Attachment #8534859 - Flags: review+
Disabled:
http://hg.mozilla.org/qa/mozmill-tests/rev/08754aef7852 (default)
status-firefox37: affected → disabled
Whiteboard: [mozmill-test-failure] → [mozmill-test-failure][mozmill-test-skipped]
Skipped 4 days ago without any regression test. When can this be done?
Flags: needinfo?(andreea.matei)
Keywords: regression, regressionwindow-wanted
(Assignee)

Comment 6

3 years ago
This is not a regression simply the Google-API for geolocation is down for our production nodes. We have this doubled as functional with mocked coordinates. The test doesn't fail in other networks and reproduces with older builds so it's clearly not a regression. I think the service was blocked for this network due to to many requests. I don't remember last time we had this issue what has been done.
Please look out for the bug then which covered that problem. All should be in there.
(Assignee)

Comment 8

3 years ago
I checked there is nothing, but in bug 1060254 comment 33 was mentioned that Garvan could help.

Garvin what should we do if the Google golocation API's is not working for *.qa.scl3.mozilla.com nodes?
It works perfectly elsewhere.
Flags: needinfo?(andreea.matei)
(In reply to Cosmin Malutan from comment #8)
> Garvan what should we do if the Google golocation API's is not working for
> *.qa.scl3.mozilla.com nodes?
> It works perfectly elsewhere.

It might help to CC or needinfo that person too. :)
Flags: needinfo?(gkeeley)

Comment 10

3 years ago
These qa test machines are having problems reaching GLS, the assumption is too many requests from those nodes. 
Hanno, any suggestions on what is happening here?

Would a curl request to GLS on the command-line return the definitive answer as to what is happening?
Flags: needinfo?(gkeeley) → needinfo?(hschlichting)

Comment 11

3 years ago
Doing a curl call from those machines might indeed give a better error message, you can try via:

curl -i -k -XPOST -H "Content-Type: application/json" https://www.googleapis.com/geolocation/v1/geolocate?key= -d '{}'

where you put our actual official Google API key as the key= query argument. Possible error responses are explained at https://developers.google.com/maps/documentation/business/geolocation/#errors
Flags: needinfo?(hschlichting)
(Assignee)

Comment 12

3 years ago
I don't know from where to take that query argument, Firefox uses GOOGLE_API_KEY which I don't know from where to read. Can you give me some pointers?
I have sent an email to Cosmin with the API key. So he can test that.
(Assignee)

Comment 14

3 years ago
This is what i'when I've done the request, as I guest we exceeded the limit, I don't know who's  in charge of that account or what's the procedure for requesting reactivation of service. 
https://developers.google.com/maps/documentation/business/geolocation/#usage_limits
>HTTP/1.1 403 Forbidden
>Vary: X-Origin
>Content-Type: application/json; charset=UTF-8
>Date: Wed, 21 Jan 2015 09:19:46 GMT
>Expires: Wed, 21 Jan 2015 09:19:46 GMT
>Cache-Control: private, max-age=0
>X-Content-Type-Options: nosniff
>X-Frame-Options: SAMEORIGIN
>X-XSS-Protection: 1; mode=block
>Server: GSE
>Alternate-Protocol: 443:quic,p=0.02
>Accept-Ranges: none
>Vary: Origin,Accept-Encoding
>Transfer-Encoding: chunked
> 
>{
> "error": {
>  "errors": [
>   {
>    "domain": "usageLimits",
>    "reason": "dailyLimitExceededUnreg",
>    "message": "Daily Limit for Unauthenticated Use Exceeded. Continued use requires signup.",
>    "extendedHelp": "https://code.google.com/apis/console"
>   }
>  ],
>  "code": 403,
>  "message": "Daily Limit for Unauthenticated Use Exceeded. Continued use requires signup."
> }
>}
(Assignee)

Comment 15

3 years ago
Hanno do you know whom should we talk to to get the service re-enabled for those nodes?
Flags: needinfo?(hschlichting)

Comment 16

3 years ago
The error message you posted says it's "unauthenticated use exceeded". Did you use the API key Henrik sent you?

For any insights or debugging on the Google account side, dougt@mozilla.com is the person to talk to. He's the one with the account login and contacts.
Flags: needinfo?(hschlichting)
(Assignee)

Comment 17

3 years ago
Yes the key he sent me.
Dougt could you give us some indication on how we could fix this, we ran automated test on *.qa.scl3.mozilla.com host nodes, and it seems we got forbidden access for the geolocation service on those nodes(comment 14).  

We ran only against nightly builds, that's about 30 runs per day, if we can't get unblocked here I think it will be best to remove this test, we have it covered with mock-up, and we ran against the real service just to be sore that the service is working as well.
Flags: needinfo?(dougt)

Comment 18

3 years ago
I think we should leave this test in. Nightly has just switched to Mozilla Location Service, so there will be no limitation. Due to this switch, this test is even more valuable than before so we can catch bugs caused by the transition to MLS.
(Assignee)

Comment 19

3 years ago
Wow, great, Andreea could you backout the skip patch, I tested this and is fixed indeed.
Flags: needinfo?(dougt) → needinfo?(andreea.matei)
Enabled on default:
http://hg.mozilla.org/qa/mozmill-tests/rev/2eddc7eace4b (default)

Will do aurora tomorrow if all is well.
status-firefox38: --- → fixed
Flags: needinfo?(andreea.matei)
(Assignee)

Comment 21

3 years ago
No failures, also this test runs only on Nightly so we could backout the skip from aurora right away and close the bug. Andreea, could you do that?
Flags: needinfo?(andreea.matei)
(Assignee)

Updated

3 years ago
Assignee: nobody → cosmin.malutan
https://hg.mozilla.org/qa/mozmill-tests/rev/c350e116d5a2 (aurora)
Status: NEW → RESOLVED
Last Resolved: 3 years ago
status-firefox37: disabled → fixed
Flags: needinfo?(andreea.matei)
Resolution: --- → FIXED
Whiteboard: [mozmill-test-failure][mozmill-test-skipped] → [mozmill-test-failure]
Keywords: regressionwindow-wanted
You need to log in before you can comment on or make changes to this bug.