Closed Bug 1147897 Opened 5 years ago Closed 4 years ago

Testing for network geolocation on Windows 7 and earlier

Categories

(Core :: DOM: Geolocation, defect)

39 Branch
x86
Windows XP
defect
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: garvan, Unassigned)

References

()

Details

Attachments

(2 files)

Creating this bug for getting reports from oneanddone.

Results go here of having tested Wi-Fi geolocation on Firefox Nightly on all Windows platforms that are version 7 and earlier (XP, Vista).
Adding link to the oneanddone task in the URL for this bug.
Platform: Windows XP under virtual box (on a Mac host), with an external TP-Link 802.11n USB wi-fi adapter

Result: negative, result is *** WIFI GEO: sending {}

Notes: The XP VM _is_ connected to Wi-Fi, but I am assuming this is such an artificial/unusual environment that we can't use it for testing this scenario. Just getting the wifi working was very difficult.
Version: 31 Branch → 39 Branch
We don't need screenshots, but those who are interested, this screenshot captures all the steps. And shows a failed result in the jsconsole window :(.
Platform: Windows 7 Service Pack 1

It works fine. '*** WIFI GEO: sending' is sending non-empty data. 11 MAC-addresses are shown.
Windows 7 Pro SP1
Tested OK, '*** WIFI GEO: sending' is sending non-empty data with 9 MAC-addresses
Windows 7 Pro SP1
sent 7 or 9 Mac addresses in different trials (which is legit, a couple distant neighbors whose wifi signal comes and goes as seen by other devices).
Worked absolutely fine for me. (non-empty string and the shown position on the map was correct)

It said
EqualCells:false
though despite the cells aren't changing, because my notebook only has a wifi adapter.

Win7 64bit
Toshiba Satellite A660
Broadcom 802.11n wifi adpater (type: Version : 2.1 + EDR (BCM2070 integrated into BCM94313, at least that's what the support website says)
Thanks :Djfe, if the geo requests are within 5-10 seconds of each other, EqualWifis should be true. Correct that EqualCells will be false on desktop -the same code is used on desktop and FxOS, so that check is performed on both.
Win 7 pro 64bits + Firefox Nightly 64bits 2015-04-09
Worked fine for me
Equalwifis is true

it's just the wording that was a little bit missleading too me, because if there aren't any cells then they won't change at all -> so that the result will always be equal (0 cells)
Blocks: 1122393
Windows XP, Home Edition, Version 2002, Service Pack 3

Nightly downloaded on 2015-04-12 (approximately 20:45 EDT). Running on a Dell Inspiron 910, connected via WiFi at the time to a home network.

Result: Negative - *** WIFI GEO: sending {}

So, it may not be the VM that's the issue for you.
Hopefully we can get some more XP testing. I don't know what else it could be other than a bug in Firefox wifi scannning code, so I should just file a bug for this. I was thinking perhaps the wifi hardware could be problematic (or sometimes produce blank AP scans), but I suspect you know that not to be the case or you would have mentioned that.
Windows 7 (64 bit, SP1):

The very first "*** WIFI GEO: sending" said just "{}", but now it lists around 17 MAC addresses and it is working fine.
Thanks Daniel, an occasional blank WiFi scan is normal. Typically if there hasn't been a scan in a while, the first scan can come back empty, or with 1-2 WiFis (when there are actually far more available).
WFM on Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:40.0) Gecko/20100101 Firefox/40.0 ID:20150414030205 CSet: 7f343964210b

*** WIFI GEO: startup called.

*** WIFI GEO: Use request cache:false reason:No cached data

*** WIFI GEO: Sending request

*** WIFI GEO: sending {"wifiAccessPoints":[{"macAddress":"??-??-??-??-??-??","signalStrength":-52},{"macAddress":"??-??-??-??-??-??","signalStrength":-57},{"macAddress":"??-??-??-??-??-??","signalStrength":-58},{"macAddress":"??-??-??-??-??-??","signalStrength":-66},{"macAddress":"??-??-??-??-??-??","signalStrength":-70},{"macAddress":"??-??-??-??-??-??","signalStrength":-72},{"macAddress":"??-??-??-??-??-??","signalStrength":-73},{"macAddress":"??-??-??-??-??-??","signalStrength":-73},{"macAddress":"??-??-??-??-??-??","signalStrength":-75},{"macAddress":"??-??-??-??-??-??","signalStrength":-78},{"macAddress":"??-??-??-??-??-??","signalStrength":-84},{"macAddress":"??-??-??-??-??-??","signalStrength":-87},{"macAddress":"??-??-??-??-??-??","signalStrength":-88}]}


Too many 802.11 radios in the hood...
Hello,
Report result of the of Test.(https://oneanddone.mozilla.org/es/tasks/104/)
Operative System: Windows 7 Home Premium / Service Pack 1 / 64 Bits
Conections type: Wi-Fi 
Nigthly Version: 64 Bit Windows(Standar) , donwnload (19/04/2015)
Steps: completed
Result: *** WIFI GEO: send MAC addresses
lpmanuallogins.length is 0
Using //@ to indicate sourceMappingURL pragmas is deprecated. Use //# instead base-min.js:1:0
lpmanuallogins.length is 0
(In reply to matzah1 from comment #17)
> lpmanuallogins.length is 0
> Using //@ to indicate sourceMappingURL pragmas is deprecated. Use //#
> instead base-min.js:1:0
> lpmanuallogins.length is 0

Can you look instead at the lines that start with
*** WIFI GEO:

Look for an entry like in comment 15, with many macAddresses listed. For privacy we don't need the macAddresses pasted in here, so you could report the count of them ("I see 10 macAddresses listed"), or like in comment 15, they were replaced by ???? for posting here.
Blocks: 1157400
Windows 7 SP1 32 bits

After several attempts, results were always:
*** WIFI GEO: sending {}
Can folks on this bug try again in the current windows nightly? It should be fixed now, as bug 1157400 has landed.
Windows 8.1

*** WIFI GEO: sending {"wifiAccessPoints":[{"macAddress":"xx-xx-xx-xx-xx-xx","signalStrength":-31},{"macAddress":"xx-xx-xx-xx-xx-xx","signalStrength":-58},{"macAddress":"xx-xx-xx-xx-xx-xx","signalStrength":-72}]}
(In reply to rrodriguez86 from comment #21)
> Windows 8.1
> 
> *** WIFI GEO: sending
> {"wifiAccessPoints":[{"macAddress":"xx-xx-xx-xx-xx-xx","signalStrength":-31},
> {"macAddress":"xx-xx-xx-xx-xx-xx","signalStrength":-58},{"macAddress":"xx-xx-
> xx-xx-xx-xx","signalStrength":-72}]}

Will try tomorrow on my Windows 7 box.
Windows 7 SP1 32 bits
Firefox Nightly 41.0a1 (2015-06-10)

*** WIFI GEO: sending {"wifiAccessPoints":[{"macAddress":"...}]}
:garvank maybe you should have mentioned that you mainly need people that are still using Windows XP ;)

anyways, I'm using Windows 7 SP1 64bit and it is working fine for me :) (correct location)

>*** WIFI GEO: startup called.
>
>*** WIFI GEO: Use request cache:false reason:No cached data
>
>*** WIFI GEO: Sending request
>
>*** WIFI GEO: sending {"wifiAccessPoints":[{"macAddress":"xx-xx-xx-xx-xx-xx","signalStrength":-22},...]}
>
>*** WIFI GEO: server returned status: 200 --> {"location":{"lat":**.******,"lng":**.******},"accuracy":100}
>
>*** WIFI GEO: Use request cache:true reason:New req. is GeoIP.
>
>*** WIFI GEO: Use request cache:true reason:EqualCells:false EqualWifis:true, Wifi only.
>
>*** WIFI GEO: Use request cache:true reason:New req. is GeoIP.
>
>*** WIFI GEO: Use request cache:true reason:EqualCells:false EqualWifis:true, Wifi only.
:djfe you are right I primarily need XP results, although it has been helpful to know that the changes didn't not break 7+
https://bugzilla.mozilla.org/show_bug.cgi?id=1129633

https://dxr.mozilla.org/mozilla-central/source/dom/geolocation/nsGeolocation.cpp
 
if (Preferences::GetBool("geo.provider.ms-windows-location", false) &&

      IsWin8OrLater()){

    mProvider = new WindowsLocationProvider();

  }

IsWin8OrLater() - why this was added???

https://bugzilla.mozilla.org/show_bug.cgi?id=512407 commit work fine in 38 version under Windows 7 (SP1 x64), but was broken in 39 by https://bugzilla.mozilla.org/show_bug.cgi?id=1129633 commit

Windows 7 have full support of geolocation sensors, so IsWin8OrLater() check logic is missing.
(In reply to SweetLow from comment #26)
> Windows 7 have full support of geolocation sensors, so IsWin8OrLater() check
> logic is missing.

Please see the follow-up in https://bugzilla.mozilla.org/show_bug.cgi?id=1129633 and the comments on the original bug (https://bugzilla.mozilla.org/show_bug.cgi?id=512407).
shouldn't it be || (or) because no it won't work under Win7, right?
and why is't it IsWin7OrLater() ?
Garvan, I think we got enough testing on this bug and it's confirmed working. We are now just getting unrelated comments on this bug, so I'd close it.
Flags: needinfo?(gkeeley)
Closing, as Hanno said we are satisfied at this point the code is working. 

djfe, it won't work on win7 (well not reliably, there is no default provider -the API interface is there, and in rare cases there can be 3rd party providers that are feeding this interface with locations). So the logic is IsWin8OrLater().
Status: NEW → RESOLVED
Closed: 4 years ago
Flags: needinfo?(gkeeley)
Resolution: --- → FIXED
(In reply to Garvan Keeley [:garvank] from comment #30)
> Closing, as Hanno said we are satisfied at this point the code is working. 
> 
> it won't work on win7 
It's a lie. And I do not understand why these words are spoken at all, after working 38 version.
I don't want to take this too far, but sweetlow is right, in the regard, that it worked just fine for everybody on here (and there were quite a few people that were using win7)

My notebook is from 2009 (Toshiba) with a broadcom chip and it works
and I don't think that there is any wifi chip on the market right now that would force the system to disallow applications from knowing the available wifi aps around (that was probably different for xp, where wifi often was implemented with custom software)

this is might be different for mobile internet though
a friend of mine used a o2 mobile stick for his notebook which needed specific software/drivers to be able to connect to the cell towers

I didn't test though whether firefox was able to get the cell towers on that device

but wifi would already be enough for positioning, I would say (the service just has to know two of the aps around)
(In reply to Djfe from comment #32)
> but wifi would already be enough for positioning, I would say (the service
> just has to know two of the aps around)

This is confusing two separate issues. Garvan recently added code to do Wifi scanning in Firefox on Windows XP. Before that only Firefox on Windows Vista and later did any Wifi scans. These Wifi scans are then used by Firefox own network geolocation provider, which in turn uses an external service from within Firefox. This all works fine and we now get Firefox to do Wifi scans in all versions in combination with Firefox's own location provider.

Completely separate from this has been work to use a location provider offered by the operating system. If the operating system offers a location provider, it internally does Wifi scanning and calls to an external service and just gives back the lat/lon/accuracy information to Firefox.

Windows has API's for such a provider starting in Windows 7 and an actually hooked up external service starting in Windows 8. Without the external service, this provider only works in the rare case where someone has additional hardware like a GPS device installed into their PC and appropriate drivers for it. The combination of Windows 7-only and custom hardware is such a rare case, that we didn't want to support it and complicate the code for it.

In addition we did some experiments and found the Windows location provider to give inferior results to those offered by Google's service. As such we have no plans to enable the Windows location provider by default on any platform, though for Windows 8+ users it's available via the "geo.provider.ms-windows-location" about:config option.

From the end-user perspective there's not going to be any real change here, except that on Windows XP the quality of the geolocation positions get better as they now use Wifi data in addition to GeoIP data. For all other versions of Windows there won't be a change.
(In reply to Hanno Schlichting [:hannosch] from comment #33)
> (In reply to Djfe from comment #32)
> 
> The combination of Windows 7-only and custom
> hardware is such a rare case, that we didn't want to support it and
> complicate the code for it.
You take simple working code from v38, _add_("complicate") code, which is not universal and lead to regress of functionality in some cases, and then post this. Where is the logic?
Windows 8.1 pro / Nightly 44.0a1

*** WIFI GEO: startup called.

14:23:28.418 *** WIFI GEO: wifi error: 2147746065

14:23:28.418 *** WIFI GEO: Use request cache:false reason:No cached data

14:23:28.418 *** WIFI GEO: Sending request

14:23:28.418 *** WIFI GEO: sending {}

14:23:29.880 *** WIFI GEO: server returned status: 200 --> {"fallback":"ipf","location":{"lat":-33.8213,"lng":18.4454},"accuracy":50000}
You need to log in before you can comment on or make changes to this bug.