979940 - geolocation not working on Windows

Status: RESOLVED WORKSFORME

(Core :: DOM: Geolocation, defect)

Description

[juan becerra [:juanb]]

Geolocation doesn't work on Windows (except XP) and Mac OS X 10.8. This works on all platforms with Fx25.0.1, but it starts failing after that on some platforms. For complete results, see: https://wiki.mozilla.org/QA/Desktop_Firefox/Geolocation/February_2014

I will be looking into a regression range, but bug 978798 may point to something outside Firefox.

Comment 1

[Lukas Blakk [:lsblakk] use ?needinfo]

We need to look into this but especially if it's outside of FF there's nothing to be done at this stage for FF28 except to perhaps bring this up to the google mailing list and see if an API change needs to occur or something else.

Comment 2

[Lukas Blakk [:lsblakk] use ?needinfo]

Gavin, do you have any ideas about this? Is it correct to look to external issues here or is there something we've done recently in product that you might suspect for regression?

Comment 3

[:Gavin Sharp [email: [e-mail]]]

Bug 978798 looks like an Ubuntu-specific issue.

There were other recent bugs similar to this: bug 970112, bug 928898.

dougt is probably in a better position to comment.

Comment 4

[Doug Turner (:dougt)]

Lukas,

Hi there,  IMO, this is kind of a stop ship bug until we know what's going on.  Geolocation is basically a core part of this HTML5 thing that we are doing, and shipping a browser without it is bad.

I've asked QA to provide regression range, and include logging (geo.wifi.logging.enabled = true)?



Juan,

Bug 978798 is basically about ubuntu (and other down stream consumers) not supplying and API key when they build.  The failures I am worried about in builds that are generated by Mozilla.

The report that was generated didn't include the logging that would be helpful to analysis this problem.  

Are all of the machines exactly the same that were tested?  For example, the row that is " Windows Vista " -- is test on identical hardware?  Are they on wired or wireless networks?

Comment 5

[juan becerra [:juanb]]

We had another round of testing last night after finding out that geolocation worked again in Windows 8 on Fx28beta (latest) and it turns out that geolocation is working on Windows except Win7 and only on Fx27. Testing was done on the same hardware, on wireless networks.

I am going to double on Fx28(latest) and report back.

Comment 6

[juan becerra [:juanb]]

Google maps seems to work on Fx28 across platforms using a wireless network. I tried this as well https://www.mozilla.org/en-US/firefox/geolocation/#geo-demo

The "new" google maps centers the map, but doesn't display the creepy blue dot where it shows I am. On Linux, on the new google maps the option to share your location (tiny button above street view icon) is not even presented.

Has this been a problem with the site all along? I can't tell, but Fx28 beta seems to be working with at least our reference demo and the "old" google maps today.

Comment 7

[Doug Turner (:dougt)]

lets not make editorial comments about the creepiness of the google ui.  Heck, lets not even look at gmaps right now.  

Use this site instead:
   http://dougt.org/mozilla/geo.html


Do you getting numbers back?

Comment 8

[juan becerra [:juanb]]

I'm getting numbers back, and these are different between machines.

These numbers also appear in the google maps URL. The numbers are consistent between the old and new google maps, but they differ from the ones returned by the site you mention in comment #7

Comment 9

[Doug Turner (:dougt)]

jaun, it should be clear that the bug might not be directly related to the OS, but instead the machine that it is running on.

Please provide more information.

Also, stop using google maps as your test case -- instead, just use the simple test I provided.  This is because, there are millions of more things the google maps site is doing.  We need to focus only if/where geolocation is busted and that simple test will help with that.

Comment 10

[juan becerra [:juanb]]

I tested on several machines today and Fx28 and up are all working with the site in comment #7, meaning all versions prompt me to share my location and numbers appear. For example:

Thinkpad T60, Vista Ultimate
Fx28beta
37.3879356 -122.08321569999998
Fx29aurora
37.3879406 -122.0832445
Fx30nightly
37.388255799999996 -122.08314969999998

Vaio, Win7 pro, guest network
fx28beta
37.3881162 -122.08330289999999
fx29aurora
37.3880221 -122.0834461
fx30nightly
37.388110999999995 -122.08331129999999

HP Compac 8510, WinXP
Similar results

Surface Pro 2, Win8.1
Similar results

However, visiting the site using Fx27.0.1 on the Win7 and Win8 machines did not prompt me to share my location, and the numbers never showed. Looking at the web console with "geo.wifi.logging.enabled = true" only showed the following on the Win7 machine:

15:10:36.361 The character encoding of the HTML document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the page must be declared in the document or in the transfer protocol. geo.html
15:10:36.426 GET http://dougt.org/favicon.ico [HTTP/1.1 404 Not Found 155ms]
15:10:36.386 NS_ERROR_FILE_ACCESS_DENIED: Component returned failure code: 0x80520015 (NS_ERROR_FILE_ACCESS_DENIED) [nsIFile.create] FileUtils.jsm:70
15:10:36.599 GET http://dougt.org/favicon.ico [HTTP/1.1 404 Not Found 90ms]

And the following on the Win8 machine:

16:54:54.215 GET http://dougt.org/mozilla/geo.html [HTTP/1.1 200 OK 165ms]
16:54:54.358 The character encoding of the HTML document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the page must be declared in the document or in the transfer protocol.

Compared with what is displayed when geolocation works (in Fx28) using the same machines:

The character encoding of the HTML document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the page must be declared in the document or in the transfer protocol. geo.html
GET http://dougt.org/favicon.ico [HTTP/1.1 404 Not Found 170ms]
GET http://dougt.org/favicon.ico [HTTP/1.1 404 Not Found 80ms]
*** WIFI GEO: startup called.  testing mode isfalse

*** WIFI GEO: watch called

*** WIFI GEO: onChange called, highAccuracy = FALSE

*** WIFI GEO: ************************************* Sending request:
https://www.googleapis.com/geolocation/v1/geolocate?key=AIzaSyD-s-mXL4mBzF7KMRkhTCIbG2RKnRGXzJc

...

So this seems to work on the machines I tried (including a Ubuntu laptop and a MB Air) using Fx28.

How would I go about getting more logging information from the two machines that fail when I run Fx27.0.1?

Comment 11

[Doug Turner (:dougt)]

Juan, Are there other door hangers busted in Fx27.0.1 on the Win7 and Win8 machines?

Comment 12

[u279076]

One other data-point for this bug, I noticed a lot of failures today with our Geolocation Mozmill test with Firefox Nightly 31.0a1. All failures are on Windows:

http://mozmill-daily.blargon7.com/#/functional/failure?app=Firefox&branch=31.0&platform=Win&from=2014-03-17&to=2014-03-18&test=%2FtestGeolocation%2FtestShareLocation.js&func=testVerifyDisplayGeolocationNotification

Juan, I wonder if this gives you any leads to test.

Comment 13

[u279076]

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #12)
>  All failures are on Windows

Strike that, the URL was filtering out the Mac and Linux results. This failure is occurring across all platforms:

http://mozmill-daily.blargon7.com/#/functional/failure?app=Firefox&branch=31.0&platform=All&from=2014-03-17&to=2014-03-18&test=%2FtestGeolocation%2FtestShareLocation.js&func=testVerifyDisplayGeolocationNotification

Comment 14

[juan becerra [:juanb]]

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #13)
> (In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #12)
> >  All failures are on Windows
> 
> Strike that, the URL was filtering out the Mac and Linux results. This
> failure is occurring across all platforms:
> 
> http://mozmill-daily.blargon7.com/#/functional/failure?app=Firefox&branch=31.
> 0&platform=All&from=2014-03-17&to=2014-03-
> 18&test=%2FtestGeolocation%2FtestShareLocation.
> js&func=testVerifyDisplayGeolocationNotification

Looking at the test case I can't tell what resource it is using to prompt for the geolocation permission, but the URL in comment #7 is working properly on the latest nightly Fx31 on Mac. We should look into why that test is failing.

Comment 15

[juan becerra [:juanb]]

(In reply to Doug Turner (:dougt) from comment #11)
> Juan, Are there other door hangers busted in Fx27.0.1 on the Win7 and Win8
> machines?

Other door hangers like the prompt for password saving are working on Win7 and Win8.

Comment 16

[Doug Turner (:dougt)]

On all failures, please report what logging says: geo.wifi.logging.enabled = true

Comment 17

[u279076]

(In reply to Doug Turner (:dougt) from comment #16)
> On all failures, please report what logging says: geo.wifi.logging.enabled =
> true

I don't think our Mozmill test supports this as currently implemented. Henrik?

Comment 18

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #17)
> > On all failures, please report what logging says: geo.wifi.logging.enabled =
> > true
> 
> I don't think our Mozmill test supports this as currently implemented.
> Henrik?

Not right now, but we could simply set this pref for the particular geolocation test, which we run through Mozmill. Andreea, could you make a patch on the other bug to get this added?

Comment 19

[Andreea Matei [:AndreeaMatei]]

Here's the output after we enabled the pref, I ran on Linux cause at this moment the geolocation is down for every platform/browser:

*** 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 | {

Comment 20

[Henrik Skupin [:whimboo][⌚️UTC+2]]

https://www.googleapis.com does only report a 404. So something happened on Google's side here.  No wonder why our geolocation feature doesn't work at all.

Comment 21

[Andreea Matei [:AndreeaMatei]]

Yes, but I'm not sure if the error Juan saw 2 weeks ago it's the same, since then it only affected Windows. But right now we can't investigate that since it fails everywhere.

Comment 22

[Henrik Skupin [:whimboo][⌚️UTC+2]]

It looks like the underlying issue is already tracked in https://code.google.com/p/chromium/issues/detail?id=154096

Comment 23

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to Andreea Matei [:AndreeaMatei] from comment #21)
> Yes, but I'm not sure if the error Juan saw 2 weeks ago it's the same, since
> then it only affected Windows. But right now we can't investigate that since
> it fails everywhere.

People having this problem intermittently for a long time. But looks like recently the number of fallouts raised dramatically.

Comment 24

[Hanno Schlichting]

I don't see any actionable information in this bug at this point. Geolocation is not always successful, as not everyone's position can be determined. Outside transient events like network connectivity issues or Google account rate limits can also influence this.