Closed Bug 1042388 Opened 10 years ago Closed 10 years ago

[B2G][FTU]Changes to Continent and City are not displayed onscreen

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.0+, b2g-v1.4 unaffected, b2g-v2.0 verified, b2g-v2.1 verified)

VERIFIED FIXED
2.1 S2 (15aug)
blocking-b2g 2.0+
Tracking Status
b2g-v1.4 --- unaffected
b2g-v2.0 --- verified
b2g-v2.1 --- verified

People

(Reporter: rkuhlman, Assigned: fcampo)

References

()

Details

(Keywords: regression, smoketest, Whiteboard: [2.0-flame-test-run-3][systemsfe])

Attachments

(4 files)

During the FTU, the user can set the location on the phone. When the user changes the Continent or the City, the changes are not always displayed onscreen. Sometimes the user must change values multiple times before anything is displayed.

Repro Steps:
1)  Flash device to BuildID: 20140722040212
2) Proceed through FTU until location and date screen
3) Change the Continent and City variables

Actual:
User choices are stored, but not displayed onscreen.

Expected:
User choices are displayed onscreen


Master M/C Environmental Variables:
Device: Flame Master M/C
BuildID: 20140722040212
Gaia: e423c3be8d19c9a8a5ae2571f499c36dc6b0df89
Gecko: 6f702709fab6
Version: 34.0a1
Firmware Version: v122


Notes:
On 273Mb Flame, this issue occurs roughly %50 of the time. It is far less frequent on 512

Repro frequency: ~%50 on 273Mb Flame
Link to video of issue: https://www.youtube.com/watch?v=fC2Di4jqafk&edit=vd
This issue also occurs on v2.0.
Device: Flame v2.0
Build ID: 20140722000200
Gaia: b9d19011123487009c80d1200937652d58c434a0
Gecko: 00f4b3a7046f
Version: 32.0
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

The issue does not occur in v1.4. Changes to Continent and City are always represented onscreen.

Environmental Variables:
Device: Flame 1.4
Build ID: 20140722000205
Gaia: 621d152f89347c79619aa909ad62cc2ac9d3ab5b
Gecko: ea3c419ca5a7
Version: 30.0 (1.4)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
[Blocking Requested - why for this release]:
blocks smoke tests from passing, https://moztrap.mozilla.org/manage/case/6119/

Requesting a window.  Please note reproducibility isn't 100%.
blocking-b2g: --- → 2.0?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
QA Contact: pcheng
Flame Central regression window:

Last Working Environmental Variables:
Device: Flame
Build ID: 20140716172339
Gaia: Unknown
Gecko: a74600665875
Version: 33.0a1 (Master)
Firmware Version: v122

First Broken Environmental Variables:
Device: Flame
Build ID: 20140717040237
Gaia: Unknown
Gecko: f6912a8e9ccc
Version: 33.0a1 (Master)
Firmware Version: v122

First broken gecko & last working gaia - issue does NOT repro
Gaia: Unknown
Gecko: f6912a8e9ccc

First broken gaia & last working gecko - issue DOES repro
Gaia: Unknown
Gecko: a74600665875

Unable to bisect further and/or generate a Gaia pushlog due to bug 1039739.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
QA-Wanted - we now have a work-around for unknown Gaia Commit, please complete regression window.
QA Whiteboard: [QAnalyst-Triage+]
b2g-inbound regression window:

Last Working Environmental Variables:
Device: Flame
Build ID: 20140716200837
Gaia: eb04b0228011a34b8c45d1fc675a6b9b7965b79d
Gecko: ef6a44c2fa8b
Version: 33.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

First Broken Environmental Variables:
Device: Flame
Build ID: 20140716223638
Gaia: ce3c8c456949d622124bd778883b29a9ba34f3cf
Gecko: 189799fd025e
Version: 33.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

First broken gecko & last working gaia - issue does NOT repro
Gaia: eb04b0228011a34b8c45d1fc675a6b9b7965b79d
Gecko: 189799fd025e

First broken gaia & last working gecko - issue DOES repro
Gaia: ce3c8c456949d622124bd778883b29a9ba34f3cf
Gecko: ef6a44c2fa8b

Gaia pushlog:
https://github.com/mozilla-b2g/gaia/compare/eb04b0228011a34b8c45d1fc675a6b9b7965b79d...ce3c8c456949d622124bd778883b29a9ba34f3cf

There is only one bug in the pushlog - Bug 1036577, though I'm not sure how that would have caused the bug?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Tim - a little uncertain here that this keyboard bug has anything to do with this issue but the pushlog indicated bug 1036577, even after a thorough double-checking. Can you take a look?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell) → needinfo?(timdream)
Blocks: 1036577
Component: Gaia::First Time Experience → Gaia::System::Input Mgmt
It's possible that inproc keyboard somehow interrupts value selectors.

Let me investigate.
Assignee: nobody → timdream
Status: NEW → ASSIGNED
Flags: needinfo?(timdream)
I am unable to reproduce this bug on a Unagi, which is a real 256MB device.
I am now able to reproduce this bug on a 273MB Flame.
It's likely this is a FTU bug. I tried to replaced the FTU zip and annotate ui.js and tz_select.js with console.log to see what's going on, but the bug stop being reproducible once I restart b2g. William is going to help me to reconstruct a debug-able and reproducible setup.
Attached patch ftu.diffSplinter Review
I am now convinced this is not a value selector bug.

What I did with William is this:
1. Set the mem to 273
2. Flash the full v122 base image
3. Turn on remote debugging
4. Download the latest build
5. Do the gaia+gecko flash, but comment out the |start b2g| part of the flash script
6. Apply the patch to my Gaia tree, and do |APP=ftu make install-gaia| to replace the ftu image
7. adb reboot
8. adb logcat | grep ftu

With the annotated patch applied, I can see clearly every time I touch the value selector, the value of the <select> is correctly updated:

Content JS LOG at app://ftu.gaiamobile.org/shared/js/tz_select.js:133 in fillCities: 133 Asia

However, for some unknown reason, onchangeTZ() on line 156 did not invoke setTimeZone() on line 510 of ui.js. Sometimes it gets update and sometimes it doesn't.

For the times that doesn't work the log shows this:

E/GeckoConsole( 1115): Content JS LOG at app://ftu.gaiamobile.org/shared/js/tz_select.js:173 in tzSelect/newTZSelector/regionSelector.onchange: 173
E/GeckoConsole( 1115): Content JS LOG at app://ftu.gaiamobile.org/shared/js/tz_select.js:133 in fillCities: 133 Asia
E/GeckoConsole( 1115): Content JS LOG at app://ftu.gaiamobile.org/shared/js/tz_select.js:144 in fillCities: 144
E/GeckoConsole( 1115): Content JS LOG at app://ftu.gaiamobile.org/shared/js/tz_select.js:155 in setTimezone: 155 true
E/GeckoConsole( 1115): Content JS LOG at app://ftu.gaiamobile.org/shared/js/tz_select.js:156 in setTimezone: 156
E/GeckoConsole( 1115): Content JS LOG at app://ftu.gaiamobile.org/shared/js/tz_select.js:146 in fillCities: 146
E/GeckoConsole( 1115): Content JS LOG at app://ftu.gaiamobile.org/shared/js/tz_select.js:175 in tzSelect/newTZSelector/regionSelector.onchange: 175

For the times that do work:

E/GeckoConsole( 1115): Content JS LOG at app://ftu.gaiamobile.org/shared/js/tz_select.js:173 in tzSelect/newTZSelector/regionSelector.onchange: 173
E/GeckoConsole( 1115): Content JS LOG at app://ftu.gaiamobile.org/shared/js/tz_select.js:133 in fillCities: 133 Antarctica
E/GeckoConsole( 1115): Content JS LOG at app://ftu.gaiamobile.org/shared/js/tz_select.js:144 in fillCities: 144
E/GeckoConsole( 1115): Content JS LOG at app://ftu.gaiamobile.org/shared/js/tz_select.js:155 in setTimezone: 155 true
E/GeckoConsole( 1115): Content JS LOG at app://ftu.gaiamobile.org/shared/js/tz_select.js:156 in setTimezone: 156
E/GeckoConsole( 1115): Content JS LOG at app://ftu.gaiamobile.org/shared/js/tz_select.js:146 in fillCities: 146
E/GeckoConsole( 1115): Content JS LOG at app://ftu.gaiamobile.org/shared/js/tz_select.js:175 in tzSelect/newTZSelector/regionSelector.onchange: 175
E/GeckoConsole( 1115): Content JS LOG at app://ftu.gaiamobile.org/js/ui.js:510 in ui_stz: 150 {"id":"Asia/Aden","region":"Asia","city":"Aden","cc":"YE","utcOffset":"+03:00","dstOffset":"+03:00"}
E/GeckoConsole( 1115): Content JS LOG at app://ftu.gaiamobile.org/js/ui.js:522 in ui_stz: 522
E/GeckoConsole( 1115): Content JS LOG at app://ftu.gaiamobile.org/js/ui.js:526 in ui_stz: 526
E/GeckoConsole( 1115): Content JS LOG at app://ftu.gaiamobile.org/js/ui.js:510 in ui_stz: 150 {"id":"Antarctica/Casey","region":"Antarctica","city":"Casey","cc":"AQ","utcOffset":"+11:00","dstOffset":"+08:00"}
E/GeckoConsole( 1115): Content JS LOG at app://ftu.gaiamobile.org/js/ui.js:522 in ui_stz: 522
E/GeckoConsole( 1115): Content JS LOG at app://ftu.gaiamobile.org/js/ui.js:526 in ui_stz: 526

Another strange thing is that supposedly everything happened in ui.js should happen between tz_select.js line 155 and line 156, but that doesn't seems to be the case, according to the log.

Any way, based on the fact, I am de-assigning myself and send this bug back to FTU comp.
Assignee: timdream → nobody
Status: ASSIGNED → NEW
Component: Gaia::System::Input Mgmt → Gaia::First Time Experience
BTW this is what happen on start-up:

E/GeckoConsole( 1115): Content JS LOG at app://ftu.gaiamobile.org/js/ui.js:313 in ui_initTZ: 133
E/GeckoConsole( 1115): Content JS LOG at app://ftu.gaiamobile.org/js/ui.js:313 in ui_initTZ: 133
E/GeckoConsole( 1115): Content JS LOG at app://ftu.gaiamobile.org/shared/js/tz_select.js:118 in fillRegions: 118
E/GeckoConsole( 1115): Content JS LOG at app://ftu.gaiamobile.org/shared/js/tz_select.js:133 in fillCities: 133 Asia
E/GeckoConsole( 1115): Content JS LOG at app://ftu.gaiamobile.org/shared/js/tz_select.js:144 in fillCities: 144
E/GeckoConsole( 1115): Content JS LOG at app://ftu.gaiamobile.org/shared/js/tz_select.js:148 in fillCities: 148
E/GeckoConsole( 1115): Content JS LOG at app://ftu.gaiamobile.org/js/ui.js:510 in ui_stz: 150 {"id":"Asia/Taipei","region":"Asia","city":"Taipei","cc":"TW","utcOffset":"+08:00","dstOffset":"+08:00"}
E/GeckoConsole( 1115): Content JS LOG at app://ftu.gaiamobile.org/js/ui.js:522 in ui_stz: 522
E/GeckoConsole( 1115): Content JS LOG at app://ftu.gaiamobile.org/js/ui.js:526 in ui_stz: 526
E/GeckoConsole( 1115): Content JS LOG at app://ftu.gaiamobile.org/shared/js/tz_select.js:149 in fillCities: 149
E/GeckoConsole( 1115): Content JS LOG at app://ftu.gaiamobile.org/shared/js/tz_select.js:118 in fillRegions: 118
E/GeckoConsole( 1115): Content JS LOG at app://ftu.gaiamobile.org/shared/js/tz_select.js:133 in fillCities: 133 Asia
E/GeckoConsole( 1115): Content JS LOG at app://ftu.gaiamobile.org/shared/js/tz_select.js:144 in fillCities: 144
E/GeckoConsole( 1115): Content JS LOG at app://ftu.gaiamobile.org/shared/js/tz_select.js:148 in fillCities: 148
E/GeckoConsole( 1115): Content JS LOG at app://ftu.gaiamobile.org/js/ui.js:510 in ui_stz: 150 {"id":"Asia/Taipei","region":"Asia","city":"Taipei","cc":"TW","utcOffset":"+08:00","dstOffset":"+08:00"}
E/GeckoConsole( 1115): Content JS LOG at app://ftu.gaiamobile.org/js/ui.js:522 in ui_stz: 522
E/GeckoConsole( 1115): Content JS LOG at app://ftu.gaiamobile.org/js/ui.js:526 in ui_stz: 526
E/GeckoConsole( 1115): Content JS LOG at app://ftu.gaiamobile.org/shared/js/tz_select.js:149 in fillCities: 149
From comment 12, you can also see that the change that do work (change to Antarctica) actually triggers the previous missing run (change to Asia) but quickly overwrites it's effect.
Ouch, I overlooked the updateTZ() function here

https://github.com/mozilla-b2g/gaia/blob/master/shared/js/tz_select.js#L207-L224

This function waits for mozSettings DOM Request to return *and* moztimechange event. It does not handle mozSettings errors, which is likely the cause of this bug.

More console.log() into this function can help us understand what's going on.

Also, this bug cannot be reproduced once I do another |adb reboot| in attempt to update ftu package again, so I highly doubt this bug should remain block. But QA would probably disagree because this apparently blocks the very important smoketest from continue.
Or, is it possible moztimechange happened too soon and attach the event listener on onsuccess() is way too late? Behavior on comment 14 suggests that.
blocking-b2g: 2.0? → 2.0+
Fernando, can you help out here?
Flags: needinfo?(fernando.campo)
I'll take a look this afternoon, need to finish something first
Flags: needinfo?(fernando.campo)
(In reply to Fernando Campo (:fcampo) from comment #18)
> I'll take a look this afternoon, need to finish something first

Thanks Fernando!
Assignee: nobody → fernando.campo
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Whiteboard: [2.0-flame-test-run-3]
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
Hey guys, sorry for the delay but I was mired in other stuff (no excuse, just explanation, and thanks to Gregor for the ping yesterday, I almost forgot).

Even if I'm unable to repro in any of my devices, even on the flame, with latest from master, I managed to see it when flashing 20140722040212 (as said on the description). 

And apart from what Tim wrote, it might be caused by a double call to tz_select, and the function not being a singleton. Everytime we start FTU, we initialize tz_select both from UI [https://github.com/mozilla-b2g/gaia/blob/master/apps/ftu/js/ui.js#L164] (which is called on startup on AppManager [https://github.com/mozilla-b2g/gaia/blob/master/apps/ftu/js/app.js#L37]) and also directly from AppManager [https://github.com/mozilla-b2g/gaia/blob/master/apps/ftu/js/app.js#L103]

This double call makes the tz_select run duplicated, so we might lose some changes (or being overwritten). 

Anyway, still a theory, will test a patch later today. But any feedback on it is appreciated.
Whiteboard: [2.0-flame-test-run-3] → [2.0-flame-test-run-3][systemsfe]
As far as I'm unable to repro, I can't test this patch properly, so I'm gonna need some help from anyone who can.
This patch tries to avoid the double call to tzSelect, which might be overwriting the changes on the selectors.

I'm ni? Tim as I know for sure he was able to repro, but any other who can test this is welcome.
Flags: needinfo?(timdream)
Sadly it's already Friday night in Taipei and I am unable to help you on this bug next week (offsite meeting, management stuff etc.)

William, would you be able to help Fernando next week (on our STR in comment 12)?
Flags: needinfo?(timdream) → needinfo?(whsu)
Maybe any QA engineer can help, not just William, since it's already weekend here?
Keywords: qawanted
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #22)
> Sadly it's already Friday night in Taipei and I am unable to help you on
> this bug next week (offsite meeting, management stuff etc.)
> 
> William, would you be able to help Fernando next week (on our STR in comment
> 12)?

Hi, Tim,

Sure! Why not! :)
Flags: needinfo?(whsu)
Keywords: qawanted
Hi, Fernando and Tim,

Good Job. You solved this bug.
I cannot reproduce it after I applied this patch. (attachment 8466081 [details] [diff] [review])
But, please also review this patch then merge it to master.

Attach the log (Apply attachment 8466081 [details] [diff] [review]). FYI.
- FTU_log_20140801.log

* Build information:
 - Gaia      attachment 8466081 [details] [diff] [review]
 - Gecko     https://hg.mozilla.org/mozilla-central/rev/104254bd1fc8
 - BuildID   20140801040326
 - Version   34.0a1
(In reply to William Hsu [:whsu] from comment #25)
> Hi, Fernando and Tim,
> 
> Good Job. You solved this bug.
\o/ blind coding FTW

> I cannot reproduce it after I applied this patch. (attachment 8466081 [details] [diff] [review]
> [details] [diff] [review])
> But, please also review this patch then merge it to master.
Yes, the patch was just for testing, I'll make a formal PR without the logs on it
> 
> Attach the log (Apply attachment 8466081 [details] [diff] [review]). FYI.
> - FTU_log_20140801.log
> 
> * Build information:
>  - Gaia      attachment 8466081 [details] [diff] [review]
>  - Gecko     https://hg.mozilla.org/mozilla-central/rev/104254bd1fc8
>  - BuildID   20140801040326
>  - Version   34.0a1
One more thing, reading the bug description, comment 1 and comment 12, I see that the build you used is different. Shouldn't we try with exactly the same process that Tim described in comment 12?
Created PR based on patch from attachment 8461306 [details] [diff] [review].

I'll try to get a hold of Francisco for quick review, due to urgency of the matter, but I'm still concerned about what I said on comment 27, so ni? just in case
Attachment #8466499 - Flags: review?(francisco)
Flags: needinfo?(whsu)
(In reply to Fernando Campo (:fcampo) from comment #27)
> (In reply to William Hsu [:whsu] from comment #25)
> > Hi, Fernando and Tim,
> > 
> > Good Job. You solved this bug.
> \o/ blind coding FTW
> 
> > I cannot reproduce it after I applied this patch. (attachment 8466081 [details] [diff] [review]
> > [details] [diff] [review])
> > But, please also review this patch then merge it to master.
> Yes, the patch was just for testing, I'll make a formal PR without the logs
> on it
> > 
> > Attach the log (Apply attachment 8466081 [details] [diff] [review]). FYI.
> > - FTU_log_20140801.log
> > 
> > * Build information:
> >  - Gaia      attachment 8466081 [details] [diff] [review]
> >  - Gecko     https://hg.mozilla.org/mozilla-central/rev/104254bd1fc8
> >  - BuildID   20140801040326
> >  - Version   34.0a1
> One more thing, reading the bug description, comment 1 and comment 12, I see
> that the build you used is different. Shouldn't we try with exactly the same
> process that Tim described in comment 12?

Hi, Fernando,

Good! You are detail-oriented person. (+1 like)
No worries.
I used the PVT build I listed to reproduce it to make sure I can reproduce this bug, then I applied your patch and try to reproduce it again.
If I can reproduce it after I applies your patch, it means your patch doesn't work, right?
:)

Have a nice weekend!
Flags: needinfo?(whsu)
Anyone with experience on the marionette tests can tell me what's happening?
https://tbpl.mozilla.org/?rev=646ce077d629d41a1f14c2008a9626b403c33b5d&tree=Gaia-Try&jobname=b2g_macosx64%20gaia-try%20opt%20test%20gaia-ui-test

we are getting a timeout when calling 'ftu.run_ftu_setup_with_default_values()' on 'test_ftu_with_tour.py' file, but the changes I made shouldn't affect that.
Any ideas? ni? the test creators just in case
Flags: needinfo?(viorela.ioia)
Flags: needinfo?(dave.hunt)
Comment on attachment 8466499 [details] [review]
Link to PR - https://github.com/mozilla-b2g/gaia/pull/22438

Code LGTM, but I still see the timeout on integration tests
Attachment #8466499 - Flags: review?(francisco) → review+
I think that the timeout is gonna provoke more harm on than the patch fixes, so I'm not merging till we know what is it provoking it. Sorry for not being able to merge the patch before monday, and thanks to Francisco to review during the weekend.
Hi, Fernando,

I reproduce this fail via the same automation test.
I found it stops at the "Start tour" page.
- http://youtu.be/Xg_qZRPQOfU

Is it a side effect?

I also can manually reproduce it via following steps.

* Steps:
1. Go to settings page
2. Tap "Developer" item
3. Tap "Launch First Time Use"
4. Finish FTU

* Result:
 - FxOS stops at "Start Tour" page
(In reply to William Hsu [:whsu] from comment #33)
> Hi, Fernando,
> 
> I reproduce this fail via the same automation test.
> I found it stops at the "Start tour" page.
> - http://youtu.be/Xg_qZRPQOfU
> 
> Is it a side effect?
> 
> I also can manually reproduce it.
Jeez!! I'm so used to skip the tutorial when testing manually that I assumed the timeout was even before getting there.

Yes, it's a side effect and now I know how to fix it, thank you so much.
Comment on attachment 8466499 [details] [review]
Link to PR - https://github.com/mozilla-b2g/gaia/pull/22438

PR updated, re-requesting r? for minor changes, and waiting for TBPL results [https://tbpl.mozilla.org/?rev=d2993962f9cf597f33d66fd71edee07d787e1c49&tree=Gaia-Try]
Attachment #8466499 - Flags: review+ → review?(francisco)
FYI, you can see a HTML report of the Gaia-Try results by clicking the output.html link at the bottom right. For example: http://mozilla-releng-blobs.s3.amazonaws.com/blobs/gaia-try/sha512/d9bb681b761e4861d2c5bcc955089d038e00182d61dda73f707de84cce12490591a5e120bff3e82d6b50442c90d580a0fde961d039b300c4053eb91dc22bf224

From recent comments and results, it looks like this question is answered now? Please needinfo again if not.
Flags: needinfo?(viorela.ioia)
Flags: needinfo?(dave.hunt)
(In reply to Fernando Campo (:fcampo) from comment #35)
> Comment on attachment 8466499 [details] [review]
> Link to PR - https://github.com/mozilla-b2g/gaia/pull/22438
> 
> PR updated, re-requesting r? for minor changes, and waiting for TBPL results
> [https://tbpl.mozilla.org/
> ?rev=d2993962f9cf597f33d66fd71edee07d787e1c49&tree=Gaia-Try]

Cool! Thanks Fernando!
You got that right!
Comment on attachment 8466499 [details] [review]
Link to PR - https://github.com/mozilla-b2g/gaia/pull/22438

Great job Fer!
Attachment #8466499 - Flags: review?(francisco) → review+
green and merged. master - 380f816b62c7111d0426a25ea7fee6413e20cae0
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.1 S2 (15aug)
I accidentally removed a line that the linter properly caught.
v2.0: https://github.com/mozilla-b2g/gaia/commit/a8a2aa36f120944f7601dd726568725f92e236e3
This issue is also reproducible on desktopb2g for some time now. The changes to Continent and City are not displayed. See Bug 976570
I'm still seeing this issue in today's 2.0 build.

Environmental Variables:
Device: Flame 2.0 (319MB)
Build ID: 20140806000200
Gaia: 5ba22d458fdb63bd72c59de53c701d0efe35c1e2
Gecko: 6fbc60a80c6d
Version: 32.0 (2.0)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Using 'git show,' it looks like this build should have the patch in it.  Can you confirm?
QA Whiteboard: [QAnalyst-Triage+][lead-review+] → [QAnalyst-Triage?][lead-review+]
Flags: needinfo?(pbylenga)
per IRC conversation with Jason, Marty can you file a follow-up bug for this then?
QA Whiteboard: [QAnalyst-Triage?][lead-review+] → [QAnalyst-Triage+][lead-review+]
Flags: needinfo?(pbylenga) → needinfo?(mshuman)
I have filed bug 1049790 as a follow-up.
Flags: needinfo?(mshuman)
Verified Fixed in Flame 2.0 and 2.1.
Continent and City changes are displayed properly in FTU.

Environmental Variables:
Device: Flame 2.1
Build ID: 20140905000202
Gaia: 95e9b099aa89ded133e44014dd40b19dc0193c01
Gecko: 92a6bbdfd945
Version: 34.0a2 (2.1)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Environmental Variables:
Device: Flame 2.0
Build ID: 20140905000204
Gaia: 4627014cc5c5eeec894183866d4c57291302f8b8
Gecko: 2fae20afe1fa
Version: 32.0 (2.0)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+][lead-review+] → [QAnalyst-Triage?][lead-review+]
Flags: needinfo?(pbylenga)
QA Whiteboard: [QAnalyst-Triage?][lead-review+] → [QAnalyst-Triage+][lead-review+]
Flags: needinfo?(pbylenga)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: