Closed Bug 1015967 Opened 6 years ago Closed 5 years ago

first run screen thrown, wifi (and maybe other) settings lost after update

Categories

(Firefox OS Graveyard :: Gaia::First Time Experience, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: bhearsum, Unassigned)

Details

(Keywords: dataloss, regression)

I was on:
Version=32.0a1
BuildID=20140523040203
SourceRepository=https://hg.mozilla.org/mozilla-central
SourceStamp=e9b2b72f4e6c

And updated to:
BuildID=20140525160203
SourceRepository=https://hg.mozilla.org/mozilla-central
SourceStamp=e86a0d92d174

with an OTA update (this MAR, specifically: http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/2014/05/2014-05-25-16-02-03-mozilla-central-flame/b2g-flame-gecko-update.mar) and was sent through the first run process after the phone rebooted, including needing to set-up wifi again.

My original set-up was to Flash 10g, then flash one of ours builds (from May 22nd IIRC).

It's worth noting that I also pushed a prefs change because I'm working on switching us to our production-grade update server, but I don't think that has an impact here. Those prefs are:
pref("app.update.url", "https://aus4.mozilla.org/update/3/%PRODUCT%/%VERSION%/%BUILD_ID%/%PRODUCT_DEVICE%/%LOCALE%/%CHANNEL%/%OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/update.xml");
pref("app.update.channel", "nightly");
Got the same here.

I got the first-run page again, and had to re-add the wifi network. My email settings were preserved, however.
This might be a problem from the migration of the FTE from the comms app to it's own specific app outside of comms.

Adding qawanted to see if we can check to see if we can reproduce consistently.
Component: General → Gaia::First Time Experience
Keywords: qawanted
I just updated again to 20140527040202 and didn't get the first run screen this time...
Was unable to reproduce for current 2.0 Flame builds during OTA update from 20140612000201 to 20140613000203

No FTU screen was presented to user after OTA update. Information for multiple saved WiFi access points remain on phone.

Environmental Variables:
Device: Flame 2.0
Build ID: 20140613000203
Gaia: a3a5322692578e0a577fb7fa08e32144b2b05ba3
Gecko: 8897bc43f59b
Version: 32.0a2 (2.0) 
Firmware Version: v121-2
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
Flags: needinfo?(jmitchell)
comment 4 is not the right way to test this. Try testing this from doing an update from 1.4 --> 2.0.
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage?][lead-review-]
QA Whiteboard: [QAnalyst-Triage?][lead-review-]
I am unable to reproduce this issue out of three attempts when updating from v1.4 to v2.0.

Device: Flame 1.4
BuildID: 20140811000206
Gaia: 4a662f6dd831cf6194d7ad3501b1d56ea2964a20
Gecko: e1b03b2fb92e
Version: 30.0 (1.4)
Firmware: V123
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Device: Flame 2.0
BuildID: 20140811000210
Gaia: de28796a8956a48bb98ca67df6a33e0622d642d1
Gecko: 5256345f62bd
Version: 32.0 (2.0)
Firmware: V123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

A Device Tour is seen, but no FTU is presented to the user after updating and the wifi remains connected throughout the updating process.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Keywords: qawanted
Josh - If this no longer reproduces on a true migration path, then we probably should close this bug out.
Flags: needinfo?(jmitchell)
agreed
Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(jmitchell)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.