1097229 - Refactor geolocation

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect)

Description

[Dave Huseby [:huseby]]

This per-origin stuff settings is a little gnarly.  I think that you need to consider a different structure here to make this easier to deal with.

Have a global fuzzer and a per-origin fuzzer rather than settings objects.

The global settings object can add the collection of per-origin fuzzers, as well as routing to them for both settings changes and fuzzing requests.  If a setting comes through for the per-origin object, it's handled in exactly the same.  If a fuzzing request comes in, then it can route based on the origin of the requester.

e.g.,

fuzzedLocation = globalSettings->GetFuzzer(origin)->Fuzz(location);
if (!location) {
  // guess we're not reporting now
}

That last bit means that you will need to attach an origin (or principal...) to a geolocation watch.  That's better than the strange registration logic you have added to support this.

The other thing I think that you should consider is to have a fuzzer instance attached to nsGeolocationSettings.  At both levels.  Rather than store a grab-bag of attributes, the settings can be used to construct a new fuzzer with the desired parameters.

That changes the structure of the settings, maybe something unified:

{ fuzzer: "none" } <- global settings have no origin
{ origin: "https://example.com", fuzzer: "fixed", latitude: 12.6, longitude: -76.263 }
{ origin: "https://google.com", fuzzer: "random", distance: 1000.0 }

All the global object needs to do is a) check if it has an origin, then either consume directly, or route to the right consumer.

Then, each will look at the fuzzer, and pass the appropriate arguments to the constructor of the fuzzer, maybe after checking for equality or something like that (don't want to make a new fuzzer with the same parameters if that means losing state...)

In addition, I will add the origin field to the PositionOptions field defined in dom/webidl/Geolocation.webidl and remove the clunky origin registration system.

Comment 1

[Dave Huseby [:huseby]]

So considering the current state of the privacy panel, this bug will be a meta bug for several refactors related to geolocation.

Comment 2

[Dave Huseby [:huseby]]

The things I am planning on doing:

1) take the geolocation parts of the privacy panel that everybody likes (e.g. precise, fixed location, no location) and move them into a geolocation subsection under the privacy section in the settings app.  disable the geolocation subsection by default and add an on/off switch in the developer menu for now.

2) remove the privacy panel from gaia.

3) investigate a geolocation daemon (see Bug 1107539) and remove the geolocation provider code out of gecko.

4) rework the geolocation singleton in gecko, get rid of the geolocation settings object, add an interface that passes the origin into the add listener functions so on the parent side we have the origin along with the listener parameters.  create an interface for geolocation "adjustment" and have implementations for "precise", "fixed location", "no location".

5) add a "named" locations tool for users to set names to given lat/lon pairs and/or "current location" for use in the fixed location settings UI.

Comment 3

[jorrete]

It's https://bugzilla.mozilla.org/show_bug.cgi?id=1097496 bug realted with this refactor?

Comment 4

[Dave Huseby [:huseby]]

(In reply to jorrete from comment #3)
> It's https://bugzilla.mozilla.org/show_bug.cgi?id=1097496 bug realted with
> this refactor?

possibly.  I'm not sure how the geolocation runtime is going to know that an app is running in the background or not.  it already works that an app can request a geolocation watch and then the user can switch to another app and the app with the geo watch keeps receiving updates.

Comment 5

[BMO Automation]

Firefox OS is not being worked on