1049149 - [B2G][FTU][Date & Time] Date and Time screen is not present in the FTU

Status: RESOLVED INVALID

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

Description

[Martin Shuman [:Marty]]

Attachment: logcat-FTU.txt

Description:
When progressing through the FTU, the user is never presented with a screen to set the Date, Time, or Region.

This screen is usually found immediately after the WiFi setting screen.


Repro Steps:
1) Update a Flame to 20140805040204
2) Progress through the FTU
3) Try to modify the Region, Date, and Time in the FTU


Actual:
The 'Date & Time' screen is not present.


Expected:
The 'Date & Time' screen is present.

Environmental Variables:
Device: Flame Master
Build ID: 20140805040204
Gaia: 19bf9795263e2ccc15d824a52ebf23c2670fa9b9
Gecko: 7f81be7db528
Version: 34.0a1 (Master)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Notes: This issue occurs on both 512MB and 319MB

Keywords: FTU, Date, Time, Region, Screen


Repro frequency: 100%
Link to failed test case: https://moztrap.mozilla.org/manage/case/6119/
See attached: video clip, logcat

Comment 1

[Martin Shuman [:Marty]]

This issue does NOT occur on Flame 2.0 at either 512MB or 319MB.
'Date & Time' screen appears normally.

Environmental Variables:
Device: Flame 2.0
Build ID: 20140805000238
Gaia: 597975839c04e0198eb98c2c77474f057b5531e7
Gecko: ddeead927143
Version: 32.0 (2.0)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 2

[Marcia Knous [:marcia]]

[Blocking Requested - why for this release]: This is a very noticeable regression during the first run.

The bug is visible if you "Launch First Time Use" from the Developer settings.

Comment 3

[Peter Bylenga [:PBylenga]]

Requesting a window, seems related to https://bugzilla.mozilla.org/show_bug.cgi?id=1042388

Comment 4

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

Bug 1026098 seems to have caused this issue.  I did not sign into network or enable data connection when doing this window.

B2g-inbound Regression Window

Last working 
Environmental Variables:
Device: Flame Master
BuildID: 20140804055536
Gaia: 0e0131f7032f051635b39828a42f1cc8e6792218
Gecko: 117263eb0550
Version: 34.0a1 (Master) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

First Broken 
Environmental Variables:
Device: Flame Master
BuildID: 20140804061727
Gaia: 7a5372714c8256fbe28c6be33423e8cff5839220
Gecko: 2c36cd757ef3
Version: 34.0a1 (Master) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Last working gaia / First broken gecko - Issue does NOT occur
Gaia: 0e0131f7032f051635b39828a42f1cc8e6792218
Gecko: 2c36cd757ef3

First broken gaia / Last working gecko - Issue DOES occur
Gaia: 7a5372714c8256fbe28c6be33423e8cff5839220
Gecko: 117263eb0550

Gaia Pushlog:  https://github.com/mozilla-b2g/gaia/compare/0e0131f7032f051635b39828a42f1cc8e6792218...7a5372714c8256fbe28c6be33423e8cff5839220

Comment 5

[Joshua Mitchell (Inactive)]

broken by Bug 1026098 ? 

Jason - I'm not able to find the contact info for the dev in question: Moz-TedC

any ideas?

Comment 6

[Joshua Mitchell (Inactive)]

qa-wanted to test this WITH and WITHOUT a sim and post the results

Comment 7

[Joshua Mitchell (Inactive)]

This is being handled via X-chat

Comment 8

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

This issue does not reproduce when the device does not have a SIM inserted.  It does reproduce when there is a SIM but no mobile network is available and the Timezone that is automatically set was incorrect (Set EST instead of PST).  This was verified on a fresh full flash to the build with the below variables.

Environmental Variables:
Device: Flame Master
BuildID: 20140805124418
Gaia: d85bbae28dd9ab9679b42d8d37c84810059e097c
Gecko: 191e834ff32b
Version: 34.0a1 (Master) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Comment 9

[Michael Henretty [:mikehenrty][:mhenretty]]

(In reply to Joshua Mitchell [:Joshua_M] from comment #5)
> broken by Bug 1026098 ? 
> 
> Jason - I'm not able to find the contact info for the dev in question:
> Moz-TedC
> 
> any ideas?

You are looking for tedders1. I am cc'ing him on the bug. After speaking with Jason on IRC, we need some clarification from UX on what should happen here in the roaming case.

Comment 10

[Jason Smith [:jsmith]]

(In reply to Michael Henretty [:mhenretty] from comment #9)
> (In reply to Joshua Mitchell [:Joshua_M] from comment #5)
> > broken by Bug 1026098 ? 
> > 
> > Jason - I'm not able to find the contact info for the dev in question:
> > Moz-TedC
> > 
> > any ideas?
> 
> You are looking for tedders1. I am cc'ing him on the bug. After speaking
> with Jason on IRC, we need some clarification from UX on what should happen
> here in the roaming case.

FWIW - When jsavory & I discussed this, we realized that the roaming SIM use case should still have the timezone screen appear. The reason for this is that the SIM's MCC/MNC may not necessarily represent where the user is located, so we can't trust it as a source to use to set the timezone. Only the mobile network's MCC/MNC can instead be trusted to set the MCC/MNC.

Comment 11

[Jason Smith [:jsmith]]

To summarize - the bug here is the fact that we're using the SIM's MCC/MNC to set the timezone here if the mobile network is not known. As a result, we'll end up skipping the timezone screen at this point. What we should be doing here instead is showing the timezone screen to allow the user to set the timezone directly, since the timezone detected from the SIM's MCC/MNC may not accurately represent the user's current timezone.

Comment 12

[Ted Clancy [:tedders1]]

Hi. I am tedders1/Moz-TedC. Sorry that I was hard to find. I ought to change my Github username but I'm afraid bad things will happen in that case.

Don't worry about roaming. As described in Bug 1026098, the Date & Time screen is only skipped when we get the timezone from the *network*.

If we get the timezone from the *SIM*, we still show the Date & Time screen. (The timezone from the SIM is presented as the default for the user, but the screen is not skipped.)

Comment 13

[Ted Clancy [:tedders1]]

I mean, that's how the requirement was described to me. Feel free to get confirmation from UX, though.

Comment 14

[Ted Clancy [:tedders1]]

Jayme, 

Are you sure that you weren't connected to the mobile network? How did you ensure that you weren't connected to the mobile network?

Comment 15

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

Reading whats been posted, I think I may have been confused.  I was declining to turn on network data when prompted, but it seems as if that might be unrelated.  
(In reply to Ted Clancy [:tedders1] from comment #14)
> Jayme, 
> 
> Are you sure that you weren't connected to the mobile network? How did you
> ensure that you weren't connected to the mobile network?

Comment 16

[Jason Smith [:jsmith]]

(In reply to Jayme Mercado [:JMercado] from comment #15)
> Reading whats been posted, I think I may have been confused.  I was
> declining to turn on network data when prompted, but it seems as if that
> might be unrelated.  
> (In reply to Ted Clancy [:tedders1] from comment #14)
> > Jayme, 
> > 
> > Are you sure that you weren't connected to the mobile network? How did you
> > ensure that you weren't connected to the mobile network?

Hmm - so maybe the network was detected here?

Jayme - What SIM are you using?

Comment 17

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

I'm using an At&t SIM
(In reply to Jason Smith [:jsmith] from comment #16)
> (In reply to Jayme Mercado [:JMercado] from comment #15)
> > Reading whats been posted, I think I may have been confused.  I was
> > declining to turn on network data when prompted, but it seems as if that
> > might be unrelated.  
> > (In reply to Ted Clancy [:tedders1] from comment #14)
> > > Jayme, 
> > > 
> > > Are you sure that you weren't connected to the mobile network? How did you
> > > ensure that you weren't connected to the mobile network?
> 
> Hmm - so maybe the network was detected here?
> 
> Jayme - What SIM are you using?

Comment 18

[Jason Smith [:jsmith]]

So this is strange. My current understanding right now of this bug is that we're skipping the timezone screen since we've probably detected the mobile network from the AT&T SIM, so we set the time & timezone from the mobile network. However, the timezone getting set here is incorrect - we're getting EST, not PST.

Ted - Any ideas why that would happen?

Comment 19

[Jason Smith [:jsmith]]

The related bug (bug 1050091) actually provides a better description problem here - timezone auto-selection is broken now. I'm going to dupe this to bug 1050091, since that bug better describes the problem here.

Comment 20

[Ted Clancy [:tedders1]]

Jason,

You said in Comment 18:

> However, the timezone getting set here is incorrect - we're getting EST, not PST.

Where did that happen? I haven't heard anything about that happening? Is there a bug for that?

In Comment 19, you said:

> I'm going to dupe this to bug 1050091

That looks like a completely different issue to me. This bug here is about the FTE (and the reporter of the bug has already said that their report was mistaken, so this bug should be marked INVALID). Bug 1050091 is about the Date & Time screen.

Comment 21

[Jason Smith [:jsmith]]

(In reply to Ted Clancy [:tedders1] from comment #20)
> Jason,
> 
> You said in Comment 18:
> 
> > However, the timezone getting set here is incorrect - we're getting EST, not PST.
> 
> Where did that happen? I haven't heard anything about that happening? Is
> there a bug for that?

I think bug 1050091 is tracking this.

> 
> In Comment 19, you said:
> 
> > I'm going to dupe this to bug 1050091
> 
> That looks like a completely different issue to me. This bug here is about
> the FTE (and the reporter of the bug has already said that their report was
> mistaken, so this bug should be marked INVALID). Bug 1050091 is about the
> Date & Time screen.

Fair enough, I'll mark this invalid then.