*Environment: Phone - Unagi Build: https://pvtbuilds.mozilla.org/pub/mozilla.org/b2g/nightly/mozilla-b2g18-unagi-eng/2013/02/2013-02-03-07-02-02/ Please use your LDAP account for login. *How to reproduce: 0. Put the sim card that would trigger a welcome message (For Mozilla Taiwan, please take the card "WOo 128kUSIM" ending 9718W 1. Flash the phone and it will autorestart *Expected Result: FTU comes out. *Actual Result: FTU got skipped. The SIM Toolkit came out and you can't use home button to go back to FTU or any other apps. (But, if you restart it, it would skip FTU and you can then skip SIM Toolkit welcome message)
Yoshi, Evelyn, If you have free time, please help with this issue =)
(For Mozilla Taiwan, please take the card "WOo 128kUSIM" ending 9718W what kind of SIM is this? is this a commercial SIM? thanks
It's the name on the SIM card, and it's from China. It's a normal SIM card. Just when the phone is on roaming mode, it would popup the message to interfere with FTU. Per our discussion, Joe, can you help to check if targeted market has this kind of features that when the phone start domestically or international roaming
:dcoloma, kev: i don't believe this will be a severe problem given that phones will be SIM ME Locked. And it's probably not common that an user turn on a new phone with non-target market SIMs that happen to pop up STK messages. i think we should just track it. Thanks
Some SIM Cards in Brazil launch a remote activation process based on STK. This might be an issue we should test in Brazil as it might be related.
Daniel, Thanks for clarification. Joe or any other tw people, If you need a SIM card to test it, please ping me.
Daniel, Thanks for clarification. Joe or any other tw people, If you need a China SIM card to test it, please ping me. (I don't currently have Brazil SIM card though.)
qawanted for target market SIM testing and tef?
(In reply to Daniel Coloma:dcoloma from comment #5) > Some SIM Cards in Brazil launch a remote activation process based on STK. > This might be an issue we should test in Brazil as it might be related. How can we get this testing? I don't think Mozilla QA is in position to determine the market necessity, and we don't want to block on something that is only speculatively a blocker.
Moz QA is not able to test this, we would have to ask TEF QA for assistance. Isabel, could we get help please and have someone test with the target market SIM?
Hi Naoki, and all, Just checked this with a SIM which launch the SIM initialization message. That is a SIM that we use for the SIMtoolkit tests. As the bug is described, the FTU is skipped once the message sent by the SIM appears and is closed. Need to clarify whether this is a similar stk message that could be presented on the target market SIMs.
(In reply to Isabel Rios [:isabel_rios] from comment #11) > Need to clarify whether this is a similar stk message that could be > presented on the target market SIMs. TEF is still trying to determine whether this blocks any of our v1.0.1 markets.
Let's get this re-nominated if/when this is deemed critical.
Daniel Coloma:dcoloma 2013-02-05 07:43:54 PST Some SIM Cards in Brazil launch a remote activation process based on STK. This might be an issue we should test in Brazil as it might be related. Isabel Rios [:isabel_rios] 2013-02-11 00:40:37 PST As the bug is described, the FTU is skipped once the message sent by the SIM appears and is closed. Need to clarify whether this is a similar stk message that could be presented on the target market SIMs. I think according to 2 people above talked, this should be deemed critically. And, Daniel, maybe you can help with testing using Brazil SIM?
I think that this issue is not FTU related, as it skips it completely without even launching it. Probably a WindowManager / system thing, as the incoming message is treated in https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/icc_cache.js#L52 After talking with :frsela (cc'ed), a possible fix would be to retain the message in there until FTU is finished, and showing it after that (with a flag for example). As this would imply changes on the FTU (to notify the system when finished) I'll keep myself assigned, but the mayor changes would have to be done in system. I'd also like some comments on the idea before starting to implement it :)
Borja told me that this bug (https://bugzilla.mozilla.org/show_bug.cgi?id=814840) could be related since somethings will be changed.
Okay, please set tef? on bug 814840 if it turns out to be the root cause here.
I see the FTU is skipped but home button does work, though closing FTU and then switching to settings app seems a bad UX.
Using pvt 2013/03/06 pub unagi engineer build. It used to be that FTU got skipped and u can't skipped settings and Sim Card Toolkits by home button or other ways. (2013/02/03 build) However, the reaction changed: It will skipped all FTU and go to lock screen. After unlock it, it would slowly go into settings > Sim Card Toolkit > Sim Card Message. The behavior has become really strange but not as serious as previous described
Please refer to http://youtu.be/KV9Z6vuOLU4 for another result coming out. The whole screen would go blank. And, you can try to select languages because the FTU is actually there. You can try to do next all the way down and try to dismiss the FTU (Really hard to do so).
(In reply to Walter Chen from comment #21) > Please refer to http://youtu.be/KV9Z6vuOLU4 for another result coming out. > The whole screen would go blank. > > And, you can try to select languages because the FTU is actually there. You > can try to do next all the way down and try to dismiss the FTU (Really hard > to do so). I worked together with Walter today to trace this issue and find it becomes more terrible ever. Technical detail: If the sim card has welcome message which triggers settings app to open STK menu, FTU's mozbrowser iframe is by someone setVisible(false) so it turns out to be all white. You could still interact with the whitescreen. I still don't know what's the code path to cause this. I guess opening settings app by icc module in system app is somewhat failed and FTU is incorrectly set invisible by window manager. Will try to investiage more tomorrow.
Just confirmed the white screen in #21 is FTU. The flow to cause this should be: 1. FTU is launched. 2. icc launches settings app. 3. settings app is for certain cause failed to be brought to fg. 4. but window manager thinks settings app is fg(openWindow succeeds) so it turns FTU into bg, which means turn it to white(default color of appWindow's iframe). I would investigate why settings app is failed to be brought to fg.
Fernando, I have a patch and I would take this. Hope you don't mind.
Created attachment 722657 [details] https://github.com/mozilla-b2g/gaia/pull/8531 Patch proposal: Make STK command delay to launch settings app until FTU is done. I didn't go deeply to see why FTU is by someone setVisible(false) because I think the implementation of FTU launch was incorrect and launching an app behind the FTU running upon lockscreen should result in unstable behavior, never doubt. Note: this patch depends on bug 814840.
master https://github.com/mozilla-b2g/gaia/commit/4d617a6ef88a48988707f34cd92dd7e700182a99 Please note: This patch depends on bug 814840. If you think the patch of bug 814840 is too dangerous to be uplifted, make this change: https://github.com/mozilla-b2g/gaia/pull/8531/files#L0R84 With if (WindowManager.isFtuRunning())
Don't mind at all, as I was on PTO till today and unable to work on this :) (In reply to Alive Kuo [:alive] (PTO during 3/27~4/7) from comment #24) > Fernando, I have a patch and I would take this. Hope you don't mind.
I'm seeing needinfo from me, and I'm not quite sure what's required. From the sounds of the thread we a) agree this isn't great UX and b) have a patch in hand to handle this use case. If I am incorrect, please let me know, but it sounds like a scenario we should have exception handling for given the use of 3rd-party SIMs in 1.0.1 markets and the desire to avoid putting a user into a scenario they can't easily get out of.
I am marking this as resolved fixed, but please see comment 26.
I was not able to uplift this bug to v1-train and v1.0.1. If this bug has dependencies which are not marked in this bug, please comment on this bug. If this bug depends on patches that aren't approved for v1-train and v1.0.1, we need to re-evaluate the approval. Otherwise, if this is just a merge conflict, you might be able to resolve it with: git checkout v1-train git cherry-pick -x -m1 4d617a6ef88a48988707f34cd92dd7e700182a99 <RESOLVE MERGE CONFLICTS> git commit git checkout v1.0.1 git cherry-pick -x $(git log -n1 v1-train)
Lemme do it. (In reply to John Ford [:jhford] from comment #30) > I was not able to uplift this bug to v1-train and v1.0.1. If this bug has > dependencies which are not marked in this bug, please comment on this bug. > If this bug depends on patches that aren't approved for v1-train and v1.0.1, > we need to re-evaluate the approval. Otherwise, if this is just a merge > conflict, you might be able to resolve it with: > > git checkout v1-train > git cherry-pick -x -m1 4d617a6ef88a48988707f34cd92dd7e700182a99 > <RESOLVE MERGE CONFLICTS> > git commit > git checkout v1.0.1 > git cherry-pick -x $(git log -n1 v1-train)
v1-train https://github.com/mozilla-b2g/gaia/commit/ec0beb9cdb77692a96971a3733d46452b371e66a v1.0.1 https://github.com/mozilla-b2g/gaia/commit/26400b9e09b3f3f88e358d2444d10db082f62af0
No Test case creation is needed in moztrap for this issue.
Cannot verify, do not have access to use the SIM toolkit.
verified in 2013/4/7 v1train pvt build. verified in 2013/4/7 v101 pvt build. Alive, thanks for the fix!