[Geolocation]Random location jumping when using Marketplace App HERE Maps while device is stationary

RESOLVED FIXED in Firefox 32, Firefox OS v1.4

Status

()

RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: garvan, Assigned: dougt)

Tracking

unspecified
mozilla33
All
Gonk (Firefox OS)
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:1.4+, firefox31 wontfix, firefox32 fixed, firefox33 fixed, b2g-v1.4 fixed, b2g-v2.0 fixed, b2g-v2.1 fixed)

Details

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
This is the mozilla-central version of this bug: Bug #1007953, which was Tarako-only. This bug is to request a patch for central. 

Although having been seen originally on Tarako, this would affect other platforms.

Summary ----------------
Description: User downloads, installs, and launches Marketplace App HERE Maps. User elects to allow HERE Maps to know one's location. Zoom in several times and user witnesses the green dot jumping several miles from East to West and vice versa ever so often. 
------------------------

See original for more information.
(Reporter)

Updated

4 years ago
Depends on: 1007953
(Reporter)

Updated

4 years ago
Blocks: 1007953
No longer depends on: 1007953
(Reporter)

Updated

4 years ago
Assignee: nobody → gkeeley
(Assignee)

Updated

4 years ago
Assignee: gkeeley → dougt
(Assignee)

Comment 1

4 years ago
Created attachment 8435552 [details] [diff] [review]
attachment.cgi?id=8430238

Carrying forward the r+ from jdm from bug 1007953.  This patch applies to m-c.
Attachment #8435552 - Flags: review+
(Reporter)

Comment 3

4 years ago
>   notify: function (timeoutTimer) {
>+    // If Wifi scanning is disabled, then we can not depend on that for the
>+    // heartbeat that drives location updates.  Instead, just use a timer which
>+    // will drive the update.
>+    if (gWifiScanningEnabled == false) {
>+        this.sendLocationRequest(null);
>+    }
>+  },
>+

The case where wifi is running, then gets shut off is not handled that I can see.
Would change this to do this first in the function.

try {
 gWifiScanningEnabled = Services.prefs.getBoolPref("geo.wifi.scan");
} catch (e) {}

Alternatively, we could listen for this setting change.
(Assignee)

Comment 4

4 years ago
Garvan -- you're going to love this.

Summary:

This isn't the only patch needed for FirefoxOS.  I need to also fix the wifi scanning code so that onerror is returned if wifi is disabled.

Background:

There are two permission like things in gecko/b2g.  There is preference (Services.prefs.get*Pref()).  This is used basically everywhere.  Go look in about:config for all of the visible preferences in Firefox desktop.  In FirefoxOS, there is something call Settings.  These are kind of like preferences, but they are completely different.  The history has something to do with the 'preference' api is kind of shitty for things -- it is synchronous for one.

On FirefoxOS, if you open the Settings app, those things are Settings -- not gecko preferences

Result:

So, the things we are dealing with in this patch are gecko style preferences and not settings.  When in FirefoxOS the user turns off WiFi Scanning, this preference is not toggled.  This preference we are using here is specific only to the provider.  It answers "should we even try to use wifi ever".  It is typically always true, and it is toggled for mochitests
(Reporter)

Comment 5

4 years ago
Hopefully just this (although I suspect nothing comes easily):
boolean gWifiScanningEnabled_B2GSetting; // init to true on startup

onerror() { gWifiScanningEnabled_B2GSetting = false; }
// assuming the scanning keeps running after onerror()
onchange() { gWifiScanningEnabled_B2GSetting = true; }

and notify() gets
if (!gWifiScanningEnabled_StandardPref || !gWifiScanningEnabled_B2GSetting) { sendLocationRequest() }
(Assignee)

Updated

4 years ago
Blocks: 1022279
https://hg.mozilla.org/mozilla-central/rev/ba5f01898068
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
(Assignee)

Updated

4 years ago
blocking-b2g: --- → 1.4?
blocking-b2g: 1.4? → 1.4+
Hardware: x86 → All

Updated

4 years ago
Blocks: 1024099
https://hg.mozilla.org/releases/mozilla-aurora/rev/4674e62192c4

Needs a branch patch for b2g30 (v1.4) uplift.
status-b2g-v1.4: --- → affected
status-b2g-v2.0: --- → fixed
status-b2g-v2.1: --- → fixed
status-firefox31: --- → wontfix
status-firefox32: --- → fixed
status-firefox33: --- → fixed
Flags: needinfo?(dougt)
Keywords: branch-patch-needed
(Assignee)

Comment 9

4 years ago
There is a set of 4 changesets that should all be applied together.  They were all nominated together.
Flags: needinfo?(dougt) → needinfo?(praghunath)
(Reporter)

Updated

4 years ago
Blocks: 1026115
Dolphin fixes will need to land on 1.4 Dolphin branch.
blocking-b2g: 1.4+ → -
Flags: needinfo?(praghunath)
(Assignee)

Comment 11

4 years ago
Preeti -- How are we going to make sure that this lands on dophin?
Flags: needinfo?(praghunath)
Doug,

I've marked the bug with the white board [dolphin land] now. Once we've created the flags 1.4D? and 1.4D+ we will tag all these bugs with the flags 1.4D+. I hope this helps.
Flags: needinfo?(praghunath)
Whiteboard: [dolphin land]
blocking-b2g: - → 1.4+
Doug, this is the first patch in that stack and it doesn't apply to b2g30. You're going to need to rebase for v1.4 uplift.
Flags: needinfo?(dougt)
Whiteboard: [dolphin land]
Doug: Ryan says you need to rebase this patch.
(Assignee)

Comment 15

4 years ago
https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/d0a9600aa3b0
status-b2g-v1.4: affected → fixed
Flags: needinfo?(dougt)
Keywords: branch-patch-needed

Updated

4 years ago
Attachment #8435552 - Attachment is patch: true
You need to log in before you can comment on or make changes to this bug.