Closed Bug 1052486 Opened 10 years ago Closed 10 years ago

Date&Time screen still visible after connecting to a network

Categories

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

x86
macOS
defect
Not set
normal

Tracking

(blocking-b2g:2.1+, b2g-v2.1 verified, b2g-v2.2 verified)

VERIFIED FIXED
2.1 S4 (12sep)
blocking-b2g 2.1+
Tracking Status
b2g-v2.1 --- verified
b2g-v2.2 --- verified

People

(Reporter: fcampo, Assigned: sfoster)

References

Details

(Whiteboard: [systemsfe])

Attachments

(1 file)

Just tried with an up to date build and I can see the Date&Time screen after getting connected to the network. 

Device: Flame
Gecko:  329b2e4
Gaia:   254ecd8
SIM:    O2 UK

https://www.youtube.com/watch?v=y8Dz9jeZjEo

repro: 
1. flash the new build
2. wait till the SIM card connects to the network (in my case, enter the PIN code and wait till we have the name of the network on the SimManager screen)
3. advance through wifi

expected:
- date & time screen should be skipped, as we get the timezone from the network (bug 1026098)

actual:
- date & time screen is visible, with the correct timezone set.
Assignee: nobody → tclancy
Blocks: 1026098
Whiteboard: [systemsfe]
Note - this is a new feature, so this would be a bug as a followup to bug 1026098, not a regression. So I'm going to remove the regression keyword here.
Keywords: regression
Ted, was this fixed by bug 1050091? Or is this a different problem?
Flags: needinfo?(tclancy)
This is a different problem. Bug 1050091 was about the Settings app. This bug is about FTU.
Flags: needinfo?(tclancy)
Fernando, do you recall if you were using SIM slot 1 or SIM slot 2 when you performed this test?
Flags: needinfo?(fernando.campo)
I did try with 2 different SIMs inserted in both slots, but if it helps I can try with different combinations.
Flags: needinfo?(fernando.campo)
I have a couple more questions.

1) How reproducible is this for you? Does it happen every time for you? Or only occasionally?

2) Does this only happen when the SIM card has a PIN? Have you tried it with a SIM card without a PIN?
Flags: needinfo?(fernando.campo)
So, I'm pretty sure the deal with this is that it happens when the SIM card has a PIN.

It's unrelated to Bug 1052486.
[Blocking Requested - why for this release]:
This bug blocks bug 1026098
blocking-b2g: --- → 2.0?
Sorry, I just tried with a single SIM card inserted on slot1, no PIN required, and I see the Date&Time screen, with the timezone from sIM mnc/mcc, not the network one. I'm in UK and used a spanish SIM card, and the timezone showing is Europe / Madrid.

If I try with a PIN blocked card, it never asks for the PIN (which is a different bug), and I see the Date&Time screen too (but this is expected).

Ted, do you need any log or video from me?
Flags: needinfo?(fernando.campo) → needinfo?(tclancy)
I made more tests after talking on IRC with Ted, and the results are a little weird. Both are done using two SIM cards on both slots of the Flame. None of them PIN blocked.

1. If I use a foreign SIM on slot 1, it gets connected to national network, but still shows the Date&Time screen, defaulting to original country timezone (taken from SIM mcc/mnc probably).
[https://www.youtube.com/watch?v=QnB0NhgeNMY]

2. Using the same country SIM card on slot 1, it gets connected to the network and Date&Time screen is not shown, everything working as expected.
[https://www.youtube.com/watch?v=RUqbIyleuV8]

3. If any of the SIM cards are SIM protected, the PIN screen is not shown (mentioned on comment 9, different bug), so we're unable to unlock the card and access the mcc/mnc, hence the Date&Time screen is shown with the default timezone (America / New York).

My best guess is that when using foreign SIM card, due to roaming, and even if we get connected to the network, the process takes longer time and something happens in the middle, but we'd need some logs to prove that.
 
P.S. Sorry for video quality, but light conditions are not the best in the office. Hopefully they're enough to see what happens.
[Blocking Requested - why for this release]:(In reply to Gerry Chang [:cfchang] from comment #8)
> [Blocking Requested - why for this release]:
> This bug blocks bug 1026098

I think you meant to nominate this for 2.1 as 1026098 is 2.1 related.
blocking-b2g: 2.0? → 2.1?
Thanks for your help, Fernando. I think I've got all the information I need.
Flags: needinfo?(tclancy)
Okay, I've been investigating this issue, and it's a little complicated. I need some input on what I should do.

It's also worth noting that there a couple different scenarios here, one involving a PIN-locked SIM, and the other involving a roaming SIM. For simplicity, I'll address the PIN-locked SIM scenario first.

THE PROBLEM

The user has a PIN-locked SIM. When they use the FTU, they unlock the SIM on the 2nd step. They then proceed to the Date & Time screen.

Expected: The Date & Time screen (normally the 5th screen) is skipped.

Actual: The Date & Time screen appears. The default timezone is the timezone of the SIM, not of the current network.

WHY IS THIS HAPPENING

When the FTU starts up, it's tries to determine the timezone using information about the mobile network connection. However, if the SIM is PIN-locked, we don't have a mobile network connection. So instead, we get the timezone information from the SIM and prompt the user for confirmation.

== OPTION 1. Do nothing. Leave it how it is. ==

This isn't a very good option, but it might be better than the other options.

== OPTION 2. Check the mobile network's timezone after the user unlocks the SIM ==

There main problem with this is that it takes time to connect to the network, and the user might reach the Date & Time page before we've successfully connected to the network. In that case, we have to show the page. My ad hoc testing showed this to happen about half the time.

So whether the Date & Time page shows up becomes dependent on timing. This might complicate testing.

== OPTION 3. After the user enters the SIM PIN, pause while we try to connect to the mobile network ==

This increases the chance that we'll successfully get the timezone from the network, but it might be a worse user experience

== OPTION 4. Move the Date & Time screen to later in the FTE == 

This also increases the chance that we'll successfully get the timezone from the network before the user reaches the Date & Time screen. Again, it might be a worse user experience

WHAT ABOUT ROAMING? 

A similar thing happens if the user is roaming. It takes longer to connect to the mobile network, although no PIN is involved. Different cause, same symptom.


* Each of these options is something I can do fairly easily. I need to know which I should do. *

I'm going to needinfo UX.
Flags: needinfo?(rmacdonald)
Flags: needinfo?(jsavory)
Hi Ted

Thanks for putting this together so clearly! 
I think that from the options presented, Option 2 is the most promising from a UX perspective. I don't feel that we should slow the user down to receive the mobile network, as you pointed out about the roaming, there is a chance that this could take quite awhile. If the user reaches the Date/Time screen before the network has been detected, it just means the user has to set it themselves but at least they are not blocked. 

Also, I will look into the ordering of FTE, it might be a bit odd to have the Date/Time later in the flow but I will see if there is another place that it makes sense.
Flags: needinfo?(jsavory)
Flags: needinfo?(rmacdonald)
The gaia-try run has a bit of orange, but that's not related to my patch. 

https://tbpl.mozilla.org/?rev=c03b74ab0c5200c133d878165e89bfca03cfb141&tree=Gaia-Try
Comment on attachment 8481547 [details] [review]
Call UIManager.initTZ later, giving the mobile network more time to connect.

LGTM but it would be good to have the owner of FTU review the patch.
Attachment #8481547 - Flags: review?(arthur.chen) → review?(francisco)
Comment on attachment 8481547 [details] [review]
Call UIManager.initTZ later, giving the mobile network more time to connect.

LGTM, please merge once gaia-try is green, I relaunched several tasks.
Attachment #8481547 - Flags: review?(francisco) → review+
blocking-b2g: 2.1? → 2.1+
Target Milestone: --- → 2.1 S4 (12sep)
Here's an almost green TBPL run: https://tbpl.mozilla.org/?rev=a7bfc370ec660f456975549a70ebad680b6ecea5&tree=Gaia-Try

There are some red Gij runs, but they seem to be intermittent issues unrelated to this patch.
Keywords: checkin-needed
master: https://github.com/mozilla-b2g/gaia/commit/12cbc9e025cfe04370e11bd5a9b043a13172a320
Status: NEW → RESOLVED
Closed: 10 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Due to recent policy changes, all patches need approval for uplift regardless of blocking status. Please request Gaia v2.1 approval on this when you get a chance. Sorry for the inconvenience :(
Flags: needinfo?(tclancy)
Comment on attachment 8481547 [details] [review]
Call UIManager.initTZ later, giving the mobile network more time to connect.

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Hi, could you please approve this?

[Bug caused by] (feature/regressing bug #):
Bug 1026098 - [User Story] Skip time and timezone setting when network time available 

[User impact] if declined:
Users with PIN-locked SIM cards will have to set their date & time manually during the FTU, even if time is available from the mobile network.

[Testing completed]:
https://tbpl.mozilla.org/?rev=a7bfc370ec660f456975549a70ebad680b6ecea5&tree=Gaia-Try

There are some red Gij runs, but they seem to be intermittent issues unrelated to this patch.

[Risk to taking this patch] (and alternatives if risky):
Shouldn't affect anything outside of the FTU.

[String changes made]:
None.
Attachment #8481547 - Flags: approval-gaia-v1.2?(fabrice)
Flags: needinfo?(tclancy)
Attachment #8481547 - Flags: approval-gaia-v1.2?(fabrice) → approval-gaia-v2.1+
Verified fixed
Actual Result: date & time screen is skipped, when connected to a network.

Flame 2.2

Environmental Variables:
Device: Flame 2.2 Master (319mb)
BuildID: 20140905040204
Gaia: 5765c62163bcb7fde5ebfd211881117de31a7c46
Gecko: dddbe46f3ceb
Version: 35.0a1 (2.2 Master)
Firmware: V123
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0
Status: RESOLVED → VERIFIED
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?]
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Issue verified as fixed on Flame 2.1

Device: Flame 2.1 KK (319mb) (Full Flash)
BuildID: 20141012001201
Gaia: d18e130216cd3960cd327179364d9f71e42debda
Gecko: 610ee0e6a776
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 34.0a2 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Once SIM connection established during FTU the date & time screen is skipped. Tested with SIM card PIN enabled as well as with PIN disabled.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
I'm working on a marionette test for this
Assignee: tclancy → sfoster
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: