Closed Bug 503942 Opened 15 years ago Closed 15 years ago

Implement Geolocation Addresses

Categories

(Core :: DOM: Geolocation, defect)

defect
Not set
major

Tracking

()

RESOLVED FIXED
Tracking Status
blocking1.9.1 --- -
status1.9.1 --- wanted

People

(Reporter: dougt, Assigned: dougt)

Details

(Keywords: dev-doc-complete)

Attachments

(2 files)

we should implement geolocation addresses based on the Gear's Address object.
Attached patch patch v.1 (deleted) — Splinter Review
Attachment #388300 - Flags: superreview?(jst)
Attachment #388300 - Flags: review?(jst)
Severity: normal → major
Flags: blocking1.9.1.1?
OS: Mac OS X → All
Hardware: x86 → All
Version: unspecified → Trunk
Marking wanted, but don't know if we'd block. What does this get us?
blocking1.9.1: --- → -
Flags: blocking1.9.1.1? → blocking1.9.1.1-
in addition to getting a lat/long, you can also get this: where |a| is the objection returned to the geolocation APIs: a.address.streetNumber a.address.street a.address.premises a.address.city a.address.county a.address.region a.address.county a.address.countryCode a.address.postalCode
Is this in a spec somewhere, or is this still being ironed out etc?
This is still being ironed out. The last reasonable format for a simplified address as basically the above plus an extra field called "additionalInformation". I am leaving this field off for now. If there this does become a recommendation, we can append the field. fwiw, google chrome and android use the above address object.
Attachment #388300 - Flags: superreview?(jst)
Attachment #388300 - Flags: superreview+
Attachment #388300 - Flags: review?(jst)
Attachment #388300 - Flags: review+
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Looks like this may be causing some mochitest failures on mozilla-central (on Mac OS X, so far).
Should be re-opened?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
the failure was caused by our test cases not providing an address response. GLS and other providers should provide this. I tweaked our code to test the response before assuming it is there. In bug 482260, we will update the testing code so that we can test with and without a provider sending an address location.
Attached patch patch v.2 (deleted) — Splinter Review
Status: REOPENED → RESOLVED
Closed: 15 years ago15 years ago
Flags: blocking1.9.2?
Resolution: --- → FIXED
Doug: I believe you want this in Firefox 3.5. If that's right, please request approval1.9.1.2 on the patch (after checking that it applies). (Note: You have some approval1.9.1.1 requests out. We'll be triaging those, no need to change them to approval1.9.1.2.)
Attachment #388300 - Flags: approval1.9.1.2?
Comment on attachment 388300 [details] [diff] [review] patch v.1 Not for 1.9.1.2.
Attachment #388300 - Flags: approval1.9.1.2? → approval1.9.1.3?
Flags: blocking1.9.2?
Comment on attachment 388300 [details] [diff] [review] patch v.1 New features/interfaces are generally not appropriate for the stable branch. 1.9.1 approval denied.
Attachment #388300 - Flags: approval1.9.1.3? → approval1.9.1.3-
Now documented for Gecko 1.9.2: https://developer.mozilla.org/en/XPCOM_Interface_Reference/NsIDOMGeoPosition https://developer.mozilla.org/en/nsIDOMGeoPositionAddress (the latter will move soon, got put in the wrong place, but there'll be a redirect).
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: