Windows 7 provides Location API. Mozilla should support it for GeoLocation support for Windows 7. How to use this API, see the following documents. http://msdn.microsoft.com/en-us/library/dd464636%28VS.85%29.aspx

Confirmed as non-working on Win7 SP1 with the release version of FF4. I have my exact location in the location settings, and the geolocation demo guesses me as being in a nearby city. (It seems to be using Google Maps, which can pinpoint my exact address if given)

We are revisiting native geo and should figure out if this works. Comment 1 does not necessarily indicate a failure of the Windows geolocation API. That is, a poor geolocation result can be a product of the service, the API may well be working as designed. A geolocation result that is a lower quality than the top-performing commercial services (such as Google) is somewhat expected.

From what I found, it seems the Windows 7 location API is just an abstraction to uniformly talk to underlying sensors. Sensor drivers could include device drivers like GPS, but they would also have to cover other data sources like WiFi or GeoIP databases. Windows 7 itself doesn't ship with any default sensors. The only thing you might get is a default position specified by the user in some part of the control panel. And it seems Windows 7 Starter Edition is indeed limited to this user-specified location [4]. Sounds to me like this isn't useful for our purposes. I doubt there are many Windows machines out there that actually have working GPS sensors attached to them, and are used outdoors where they can get a GPS signal. Some links I found: http://msdn.microsoft.com/en-us/library/windows/apps/hh464919.aspx http://www.istartedsomething.com/20100301/geosense-for-windows-location-released/ http://blogs.msdn.com/b/semantics/archive/2010/07/22/windows_2d00_7_2d00_location_2d00_awareness.aspx [4] http://msdn.microsoft.com/en-us/library/windows/desktop/dd317661%28v=vs.85%29.aspx

(In reply to Hanno Schlichting [:hannosch] from comment #3) > From what I found, it seems the Windows 7 location API is just an > abstraction to uniformly talk to underlying sensors. Sensor drivers could > include device drivers like GPS, but they would also have to cover other > data sources like WiFi or GeoIP databases. If using SENSOR_TYPE_LOCATION_GPS, it uses as device GPS (most Windows PCs don't have it) If using SENSOR_TYPE_LOCATION_LOOKUP, it uses GeoIP/WiFi by Microsoft. IE9+ uses both sensor types. > Windows 7 itself doesn't ship with any default sensors. The only thing you > might get is a default position specified by the user in some part of the > control panel. And it seems Windows 7 Starter Edition is indeed limited to > this user-specified location [4]. You says about SENSOR_TYPE_LOCATION_STATIC that sets by Control Panel. I have a prototype impl for this. So I will work at next week.

This would be great if you could hook this up. However, everything I have read supports Hanno's statement. Take this search for example: http://lmgtfy.com/?q=Windows.Devices.Geolocation+%22windows+7%22+geosense Geosense was a commercial provider for windows 7 geolocation, that seems to have folded once win8 came out with their geolocation provider. The first 6 links on that search all make various statements about there being no geolocation provider on Win 7. Is there a link to some different information that states there is a provider on Win 7?

It only test on Windows 8.1

Comment on attachment 8551126 [details] [diff] [review] Support Windows Location API Support Location API for Windows. Location API introduces from Windows 7. But GeoIP based Location service is from Windows 8+. LocationAPI.h has other GUID defines, so we cannot use UNIFIED_SOURCES. Also, locationapi.lib requires for CLSID define.

Just out of interest, does this patch have a pref so people can still turn back to using MLS if they want to?

(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #9) > Just out of interest, does this patch have a pref so people can still turn > back to using MLS if they want to? If geo.provider.use_mls=true with this patch, Gecko always use MLS.

Comment on attachment 8551126 [details] [diff] [review] Support Windows Location API Review of attachment 8551126 [details] [diff] [review]: ----------------------------------------------------------------- ::: dom/system/windows/WindowsLocationProvider.cpp @@ +143,5 @@ > + getter_AddRefs(location)))) { > + return NS_ERROR_FAILURE; > + } > + > + IID reportTypes[] = { IID_ILatLongReport }; nit: trailing whitespace @@ +147,5 @@ > + IID reportTypes[] = { IID_ILatLongReport }; > + if (FAILED(location->RequestPermissions(nullptr, reportTypes, 1, FALSE))) { > + return NS_ERROR_FAILURE; > + } > + nit: trailing whitespace @@ +155,5 @@ > + > +NS_IMETHODIMP > +WindowsLocationProvider::Watch(nsIGeolocationUpdate* aCallback) > +{ > + LocationEvent* event = new LocationEvent(aCallback); Should this be in an nsRefPtr? ::: dom/system/windows/WindowsLocationProvider.h @@ +15,5 @@ > + > +class WindowsLocationProvider MOZ_FINAL : public nsIGeolocationProvider > +{ > +public: > + NS_DECL_THREADSAFE_ISUPPORTS Does this need to be threadsafe?

(In reply to Makoto Kato (:m_kato) from comment #10) > (In reply to Robert Kaiser (:kairo@mozilla.com) from comment #9) > > Just out of interest, does this patch have a pref so people can still turn > > back to using MLS if they want to? > > If geo.provider.use_mls=true with this patch, Gecko always use MLS. Awesome, that's great to hear.

Comment on attachment 8551126 [details] [diff] [review] Support Windows Location API Review of attachment 8551126 [details] [diff] [review]: ----------------------------------------------------------------- ::: dom/geolocation/nsGeolocation.cpp @@ +814,5 @@ > } > #endif > > +#ifdef XP_WIN > + if (Preferences::GetBool("geo.provider.use_windowslocation", false)) { How about |geo.provider.ms-windows-location|. ::: dom/system/windows/WindowsLocationProvider.cpp @@ +175,5 @@ > + return NS_OK; > +} > + > +NS_IMETHODIMP > +WindowsLocationProvider::SetHighAccuracy(bool enable) You're ignoring 'enable' which seems bad since LOCATION_DESIRED_ACCURACY_HIGH implies use full power to produce the result. LOCATION_DESIRED_ACCURACY_DEFAULT The sensor should use the accuracy for which it can optimize power use and other cost considerations. LOCATION_DESIRED_ACCURACY_HIGH The sensor should deliver the most accurate report possible. This includes using services that might charge money, or consuming higher levels of battery power or connection bandwidth. We do flip this on and off - http://mxr.mozilla.org/mozilla-central/ident?i=setHighAccuracy ::: dom/system/windows/WindowsLocationProvider.h @@ +15,5 @@ > + > +class WindowsLocationProvider MOZ_FINAL : public nsIGeolocationProvider > +{ > +public: > + NS_DECL_THREADSAFE_ISUPPORTS The android class doesn't. http://mxr.mozilla.org/mozilla-central/source/dom/system/android/AndroidLocationProvider.h#10