Closed Bug 996476 Opened 10 years ago Closed 10 years ago

Empty « Accounts » section in Settings

Categories

(Firefox OS Graveyard :: FxA, defect)

Product:
Firefox OS Graveyard
Component:
FxA
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(blocking-b2g:2.0+, b2g-v2.0 fixed)

Status:
RESOLVED FIXED
Milestone:
2.0 S1 (9may)
Project Flags:
blocking-b2g 2.0+
Tracking Flags:
Tracking Status
b2g-v2.0 --- fixed

People

(Reporter: gerard-majax, Assigned: jhirsch)

References

Details

(Keywords: dataloss, Whiteboard: [qa+])

Attachments

(1 file)

Github PR 18438
46 bytes, text/x-github-pull-request
arthurcc
: review+
Details | Review 
Performing OTA of Gecko/Gaia master of your device, the « Accounts » section is empty in Settings. Doing a reset-gaia, we have the options for Firefox Accounts.

This smells like a migration/update not being properly handled. I'm reproducing this on several devices.
Keywords: qawanted
We're seeing that since Firefox accounts have been enabled. Can you look into it Jared?
Flags: needinfo?(6a68)
Note for QA Wanted - you'll want to test this by doing an OTA update on Leo from 1.4 to 1.5.
Hey all,

Yes, we did recently enable firefox accounts (bug 989151).

I've never seen this error--is it possible to repro it on a hamachi? If so, I'd really like STR. If not, maybe I can have desktop support ship me another device, and maybe someone can point me at docs around simulating OTA updates (I've always used "make reset-gaia" to push code onto my device).
Flags: needinfo?(6a68)
(In reply to Jared Hirsch [:_6a68] [@6a68] from comment #3)

[...]

> (I've always used "make reset-gaia" to push code onto my device).

That's the point. Do an OTA, you will see the bug.
The bug might also show up if you do "make install-gaia".
I raised a simliar bug 996173, and i noticed this happens only after: 
1. the reset of the device
2. user has logged in to accounts before the reset.  
if this is also the case here, we can mark either one bug as a duplicate i think.
(In reply to Alexandre LISSY :gerard-majax from comment #4)
> (In reply to Jared Hirsch [:_6a68] [@6a68] from comment #3)
> 
> [...]
> 
> > (I've always used "make reset-gaia" to push code onto my device).
> 
> That's the point. Do an OTA, you will see the bug.

Right, I wasn't aware that OTA could introduce new bugs. We should really have a checklist for things to verify on a handset before landing code--if I had known, I would have verified it myself first.

So, I found a page on MDN that discusses building your own OTA updates[1], I can do this, but I don't have b2g setup on my laptop, just gaia. Is there an OTA someone has already built that I can use to try to repro/debug right away on my hamachi?

[1] https://developer.mozilla.org/en-US/Firefox_OS/Building_and_installing_Firefox_OS/Firefox_OS_update_packages
If your device is configured with app.update.url pointing to http://update.boot2gecko.org/ with app.update.channel hamachi/1.5.0/nightly you can download and apply FOTA.
And yes, the link is valid. You can apply the MAR produced using |python tools/update-tools/test-update.py objdir-gecko/dist/b2g-update/b2g-gecko-update.mar|: it will setup a busybox httpd on the device, and change the update url and channel to it so that you can apply the FOTA.
ooh, I just repro'd this off of master without having to do the OTA stuff. Investigating.
Assignee: nobody → 6a68
Blocks: 987416
Component: Gaia::Settings → FxA
Oh, just noticed that njpark pointed out that we have two bugs for the same symptoms. Marking this one as a dupe of 996173
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Let's not mark it as duplicate just yet. In comment 6, user has logged into Fx accounts. Alexandre and I never did.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Anthony, are you still able to repro this with today's build?
Flags: needinfo?(anthony)
Actually, let me ask a bit more specifically - are you able to repro on a hamachi/buri with today's build? I'm not sure what our commitment is to supporting other devices for the 2.0 release, my understanding was "no support".

Setting ni? for Alexandre as well
Flags: needinfo?(lissyx+mozillians)
Hey Christiane - Are you able to reproduce this using today's pvt build? I am not (using Hamachi), and No-Jun (fxa-fxos QA) was not able either, which is why we closed the other bug about this (bug 996173).
Flags: needinfo?(cr)
Flags: needinfo?(cr)
I can confirm that it works in today's master (updated about about two hours ago). Navigation is still quirky (Next button won't get you anywhere after logging-in through Settings, Keyboard input won't let you move the cursor), but main functionality seems to be fine.
(In reply to Alexandre LISSY :gerard-majax from comment #9)
> And yes, the link is valid. You can apply the MAR produced using |python
> tools/update-tools/test-update.py
> objdir-gecko/dist/b2g-update/b2g-gecko-update.mar|: it will setup a busybox
> httpd on the device, and change the update url and channel to it so that you
> can apply the FOTA.

Hmm, I think I need a bit more context. I figured out how to configure OTA updates using the device, but remember, I don't have a local copy of m-c/b2g, just gaia. Whatever's the least learning curve way to get there, that's what I want to try. b2g is going to take a horribly long time to download and get configured, etc., and I'd like to avoid that if possible.

Here's what I tried, but I got stuck along the way:

1. check out the v1.4 branch from gaia
2. make reset-gaia to put the handset in 1.4 state
3. create an updates.js file containing the following lines:
     pref("app.update.channel", "hamachi/1.5.0/nightly");
     pref("app.update.url", "http://update.boot2gecko.org");
4. adb remount
5. adb push updates.js /system/b2g/defaults/pref/updates.js
6. adb reboot

The device starts back up. Unfortunately, wifi doesn't seem to work after restarting, so I can't actually catch OTA updates :-(

Is it possible to grab OTA updates from a desktop machine?
(In reply to Christiane Ruetten [:cr] from comment #17)
> I can confirm that it works in today's master (updated about about two hours
> ago). Navigation is still quirky (Next button won't get you anywhere after
> logging-in through Settings, Keyboard input won't let you move the cursor),
> but main functionality seems to be fine.

Ah, great to know! What device were you using?
Flags: needinfo?(cr)
That was a Peak. Do you expect differences among devices?
Flags: needinfo?(cr)
(In reply to Jared Hirsch [:_6a68] [@6a68] from comment #18)
> (In reply to Alexandre LISSY :gerard-majax from comment #9)
> > And yes, the link is valid. You can apply the MAR produced using |python
> > tools/update-tools/test-update.py
> > objdir-gecko/dist/b2g-update/b2g-gecko-update.mar|: it will setup a busybox
> > httpd on the device, and change the update url and channel to it so that you
> > can apply the FOTA.
> 
> Hmm, I think I need a bit more context. I figured out how to configure OTA
> updates using the device, but remember, I don't have a local copy of
> m-c/b2g, just gaia. Whatever's the least learning curve way to get there,
> that's what I want to try. b2g is going to take a horribly long time to
> download and get configured, etc., and I'd like to avoid that if possible.
> 
> Here's what I tried, but I got stuck along the way:
> 
> 1. check out the v1.4 branch from gaia
> 2. make reset-gaia to put the handset in 1.4 state
> 3. create an updates.js file containing the following lines:
>      pref("app.update.channel", "hamachi/1.5.0/nightly");
>      pref("app.update.url", "http://update.boot2gecko.org");
> 4. adb remount
> 5. adb push updates.js /system/b2g/defaults/pref/updates.js
> 6. adb reboot
> 
> The device starts back up. Unfortunately, wifi doesn't seem to work after
> restarting, so I can't actually catch OTA updates :-(
> 
> Is it possible to grab OTA updates from a desktop machine?

Update URL should be "http://update.boot2gecko.org/%CHANNEL%/", and after rebooting you should get wifi.
Flags: needinfo?(lissyx+mozillians)
(In reply to Christiane Ruetten [:cr] from comment #20)
> That was a Peak. Do you expect differences among devices?

I really don't know. Chatted with nhirata, Rik, and gerard-majax in IRC about this, here's what I think I know:

1) front-end code like this should be uniformly reproducible across devices, so bug reports from unsupported phones are still useful in this case
2) the OTA update doesn't change any of the user prefs on device--so maybe "make install-gaia" would be a closer approximation than "make reset-gaia"

I'll continue trying with the correction added in c21 (thanks for that Alexandre!).

No-Jun, have you had any luck reproing this?
Flags: needinfo?(anthony) → needinfo?(npark)
OK, I now have wifi, here are my updated steps:

1. check out the v1.4 branch from gaia
2. make reset-gaia to put the handset in 1.4 state
3. create an updates.js file containing the following lines:
     pref("app.update.channel", "hamachi/1.5.0/nightly");
     pref("app.update.url", "http://update.boot2gecko.org/%CHANNEL%/");
4. adb remount
5. adb push updates.js /system/b2g/defaults/pref/updates.js
6. adb reboot

However, when I make reset-gaia to get to v1.4, then go to device information -> "check now" for updates, I get "There was an error when checking for updates."

I also get this error after I flash updates.js onto the device, with or without the "app.update.url" pref inside updates.js.

Anybody have a guess as to the cause of this?
After taking a short break, I think I am approaching this bug the wrong way--I think trying to find STR is not the best use of my time.

For now, I'm going to wait for QA to reproduce this on a hamachi/buri, with solid STR.

I'm still CC'd on the bug, but I can't continue to spin my wheels on a bug which is unconfirmed and extraordinarily challenging to reproduce, relative to typical FxA bugs.

Once QA has solid STR, please ni? me and I'll resume work on this.
Assignee: 6a68 → nobody
Sorry, it looks like the pref I gave was wrong:
$ git grep 'app.update.url'
b2g/app/b2g.js:pref("app.update.url", "http://update.boot2gecko.org/%CHANNEL%/update.xml");

I usually push them directly into /system/b2g/defaults/pref/user.js

But I don't understand, Rik already said that it was getting reproduced by reset-gaia on code prior to FxAccounts, followed by an install-gaia with FxAccounts.
(In reply to Alexandre LISSY :gerard-majax from comment #25)
> 
> But I don't understand, Rik already said that it was getting reproduced by
> reset-gaia on code prior to FxAccounts, followed by an install-gaia with
> FxAccounts.

I dunno where Rik said that, but I missed it. Now I can finally repro. Thank you.
Assignee: nobody → 6a68
Flags: needinfo?(npark)
So, this is really in a weird state!

Even though I preffed firefox accounts on, it looks like the pref is not actually toggled by the OTA update. Very interesting.

Anyway, the basic problem is that we should not display the header if the pref is disabled. Opening PR now.
Attached file Github PR 18438 — 
Waiting on travis, then we'll r?.
Comment on attachment 8408692 [details] [review]
Github PR 18438

Hey Arthur - do you have time to review this? Really simple one-liner :-)
Attachment #8408692 - Flags: review?(arthur.chen)
Does "identity.fxaccounts.ui.enabled" false imply findmydevice.ui.enabled is also false?
Comment on attachment 8408692 [details] [review]
Github PR 18438

r=me, thanks.
Attachment #8408692 - Flags: review?(arthur.chen) → review+
Awesome! Thanks for the late-night r+, Arthur!
Master: https://github.com/mozilla-b2g/gaia/commit/d94ce19fda6f4384d4dfbdf97c7b46b75b993c46
Status: REOPENED → RESOLVED
Closed: 10 years ago → 10 years ago
status-b2g-v2.0: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 2.0 S1 (9may)
No-Jun - Marked this qa+ to make sure it gets attention. Did I do it right?
Flags: needinfo?(npark)
Whiteboard: [qa+]
Removing qawanted for now per comment 33.
Keywords: qawanted
blocking-b2g: 2.0? → 2.0+
(In reply to Jared Hirsch [:_6a68] [@6a68] from comment #33)
> Master:
> https://github.com/mozilla-b2g/gaia/commit/
> d94ce19fda6f4384d4dfbdf97c7b46b75b993c46

I'm a bit curious about this. This effectively hides the « Accounts » section, but as far as I can tell, it does not fix the fact that the migration is somewhat not done properly: I cannot access the Firefox Accounts sections, and thus not enable/configure one.

Where is the followup bug to fix this ?
Flags: needinfo?(6a68)
tested this out by installing firefox account enabled 1.4 build, then make install-gaia with 1.5 build.  Firefox account page in setting does show up properly now.

Manual test case is here in MozTrap:
https://moztrap.mozilla.org/manage/case/12895/
Flags: needinfo?(npark)
npark: This is not the problem fixed in this bug. The problem was when not installing FxAccount on 1.4 and then update to 1.5.
(In reply to Anthony Ricaud (:rik) from comment #38)
> npark: This is not the problem fixed in this bug. The problem was when not
> installing FxAccount on 1.4 and then update to 1.5.

Ah, thanks!  I misunderstood.  I'll make a note of that in the test steps and redo it.
(In reply to Anthony Ricaud (:rik) from comment #38)
> npark: This is not the problem fixed in this bug. The problem was when not
> installing FxAccount on 1.4 and then update to 1.5.

If that's the case, we might have to reopen the bug as per comment 36.  Upgrade won't show firefox account menu, unless the prefs are changed (in my case of running make install-gaia, it did not)

Jared, thoughts?
(In reply to Alexandre LISSY :gerard-majax from comment #36)
> (In reply to Jared Hirsch [:_6a68] [@6a68] from comment #33)
> > Master:
> > https://github.com/mozilla-b2g/gaia/commit/
> > d94ce19fda6f4384d4dfbdf97c7b46b75b993c46
> 
> I'm a bit curious about this. This effectively hides the « Accounts »
> section, but as far as I can tell, it does not fix the fact that the
> migration is somewhat not done properly: I cannot access the Firefox
> Accounts sections, and thus not enable/configure one.
> 
> Where is the followup bug to fix this ?

Well, if the migration is not working properly, I'd say this might be a bug with the OTA updates. Would you mind filing a bug for that? I'm not sure what the component would be.

As far as firefox accounts, since we are committed for the 2.0 release, by far the simplest fix is to remove all the code that checks for prefs in the first place, and remove the pref too; this is already ticketed as non-blockers: bug 983452 and bug 993794. I'll discuss with our PM about refiling them as blockers--we will triage bugs with him next week anyhow.
Flags: needinfo?(6a68) → needinfo?(lissyx+mozillians)
Ah, never mind, npark pointed out in IRC that bug 971204 is already filed for OTA problems specifically with the buri. Clearing ni, I think we are done here :-)
Flags: needinfo?(lissyx+mozillians)
(In reply to Jared Hirsch [:_6a68] [@6a68] from comment #42)
> Ah, never mind, npark pointed out in IRC that bug 971204 is already filed
> for OTA problems specifically with the buri. Clearing ni, I think we are
> done here :-)

The bug you are pointing out has nothing to do, it is caused by an outdated librecovery that makes triggering the recovery mode in a bad way.
(In reply to Jared Hirsch [:_6a68] [@6a68] from comment #41)
> (In reply to Alexandre LISSY :gerard-majax from comment #36)
> > (In reply to Jared Hirsch [:_6a68] [@6a68] from comment #33)
> > > Master:
> > > https://github.com/mozilla-b2g/gaia/commit/
> > > d94ce19fda6f4384d4dfbdf97c7b46b75b993c46
> > 
> > I'm a bit curious about this. This effectively hides the « Accounts »
> > section, but as far as I can tell, it does not fix the fact that the
> > migration is somewhat not done properly: I cannot access the Firefox
> > Accounts sections, and thus not enable/configure one.
> > 
> > Where is the followup bug to fix this ?
> 
> Well, if the migration is not working properly, I'd say this might be a bug
> with the OTA updates. Would you mind filing a bug for that? I'm not sure
> what the component would be.

No, if there is a bug it's in the code that handles Firefox Accounts: this code should be responsible for performing its updates.

> 
> As far as firefox accounts, since we are committed for the 2.0 release, by
> far the simplest fix is to remove all the code that checks for prefs in the
> first place, and remove the pref too; this is already ticketed as
> non-blockers: bug 983452 and bug 993794. I'll discuss with our PM about
> refiling them as blockers--we will triage bugs with him next week anyhow.

Okay, so according to this, it would mean that for now, it is not expected that Firefox Accounts works?

What I'm not sure about is the current state: should we be able to access the Firefox Accounts menu from settings? The fact that I can do this on a freshly flashed device would point to a "yes".

If you confirm that I should be able to, then it's a bug in your way to handle updates, and we will need to file a bug asap :)
Flags: needinfo?(6a68)
(In reply to Alexandre LISSY :gerard-majax from comment #44)
> What I'm not sure about is the current state: should we be able to access
> the Firefox Accounts menu from settings? The fact that I can do this on a
> freshly flashed device would point to a "yes".

Yup.

> 
> If you confirm that I should be able to, then it's a bug in your way to
> handle updates, and we will need to file a bug asap :)

The bug is already filed, it's bug 983452 and 993794.
Flags: needinfo?(6a68)
Follow up: now that bug 993794, I do see the menu to create an FxAccount in Settings. No FTU when updating the device, is it expected?
Flags: needinfo?(6a68)
We chatted about this in #gaia a bit. There's no FTU displayed when the device is updated--it's a nice idea, though :-)
Flags: needinfo?(6a68)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: