As a follow up to Bug 813112, :alive reported that the lockscreen is still there during FTU running so the screen timeout is very soon if the user don't touches the screen after 5~7 seconds. That's bad UX. I think the lockscreen should run (because otherwise we might have a security issue where a user could kill FTU) but the screen timeout should be like when we're unlocked state. An alternative is making sure that the lockscreen run when FTU stops, either normally or abnormally.

I agree what :ttaubert said at https://bugzilla.mozilla.org/show_bug.cgi?id=813112#c9 Josh, need your feedback because it's relavant to behavior of lockscreen. Do we expect the lockscreen is "disabled" until the user finishes FTU and then first-time turn off/turn on the device?

I also encountered this issue today. But, I think the screen goes off much faster than what I imagine. It's absolutely less than 3 seconds, sometimes.

In the normal operation, the screen becomes first darker, and after that only, and after another while, it goes off. When we're in FTU, the screen goes off directly.

It seems that now FTU takes the same screen timeout setting as lockscreen (10 second and go off directly), I suggest it should at least take the homescreen setting (default is 1 minute, and the screen will turn to darker and then go off) or even disable the screen timeout

Someone mentioned that this is happening because Lock screen runs in background while user goes through FTE. Is there a reason for that? IMO the user should not see the Lock screen once they complete the FTE. They should be taken straight into the Home screen. So there should be no reason for the Lock screen to be running during FTE, right? Which might also solve this problem.

I think Josh is right, because if you launch the FTU app from the setting app, this bug won't happen (the FTU will have the same behavior as apps in homescreen)

(In reply to Josh Carpenter [:jcarpenter] from comment #5) > Someone mentioned that this is happening because Lock screen runs in > background while user goes through FTE. Is there a reason for that? IMO the > user should not see the Lock screen once they complete the FTE. They should > be taken straight into the Home screen. So there should be no reason for the > Lock screen to be running during FTE, right? Which might also solve this > problem. It's the root cause why we suffer from this bug, not the reason for why itself exists. It should be fixed anyway. As Tim has already mentioned at https://bugzilla.mozilla.org/show_bug.cgi?id=810229#c4

https://github.com/mozilla-b2g/gaia/pull/6599 This patch does: 1. Make lockscreen away from FTU running. 2. Fix an implicit issue when FTU is terminated. Address in Bug 814583 3. Remove the FTU workaround from past patch.

The patch breaks the 'hold home' button. Controlling this 'timing' during the FTU, even removing the 'timeout', should be done in 'Screen_manager'.

This patch breaks current functionality. Steps to reproduce: - While FTU is running, hold home few seconds Expected: - Nothing happens Applying this patch: - Card view appears, and we could kill the FTU :/

I am going to deassign myself. Note to Anyone continues to work on this bug: * Please keep in mind the z-index mess in the build now introduces bug 814204 * Please keep in mind current FTU termination is not behaved well. You may suffered from another FTU after reboot, if you click next two fast. The asyncstorage setting is not called. I believe I have contribued my most to find out what happened in this issue and I believe things will go ahead well afterward no matter who takes over this bug. Thanks.

I think Josh accidentally change this from blocking+ to blocking? ... Base on the IRC discussion and our shared understanding of System app engineering, Borja, would you redo the System app part of the FTU launching logic, and -- try not to rely on lock screen to block the holdhome & home event for you -- try not to ask window manager to launch ftu; create a new module to do that Can you make that happen and make everyone happy? Thanks.

Comment on attachment 684634 [details] PR6599 Clean the review flags since this is not the ideal solution we are asking for. Good work, but sorry about that.

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #12) > -- try not to rely on lock screen to block the holdhome & home event for you > -- try not to ask window manager to launch ftu; create a new module to do Bug 812252 can be fixed altogether with this approach, as a side effect.

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #14) > (In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #12) > > -- try not to rely on lock screen to block the holdhome & home event for you > > -- try not to ask window manager to launch ftu; create a new module to do > > Bug 812252 can be fixed altogether with this approach, as a side effect. I am sorry, not this one, but the one about 'holdhome' ... Borja, reviewer is not responsible to deliver the fix just because he has alternative idea about the fix. I am still counting on you for this because you are the original author of ftu launching logic.

Brief summary: - https://bugzilla.mozilla.org/show_bug.cgi?id=813541#c12 is out of the scope of this bug. The workaround is merged and working in Gaia, the goal of this patch is only for fixing the timeout issue. I will talk with [:jcarpenter] in order to adjust the code to the behaviour required by UX. - [:alive] I've made a small change which fixes the 'weird' behaviour of lockscreen while using 'asyncstorage'. Thanks for the tip! - As we agree we would need a followup in order to restore the structure of System App and find the best way of handling 'hold home' button and keep JS modularized, that's why I've created the following bug https://bugzilla.mozilla.org/show_bug.cgi?id=814840. One thing more. AFAIK the way of working it seems to be Agile, so anybody could fix any bug, having the support of the peers and owners of each app for reviewing and solving all doubts. Currently Im working on SMS App, so it's impossible for me (at least by now) take the bug #814840, but I would be so happy if you or somebody with your background in 'System App' could fix it. Thanks.

I'll try to get into this during the work week, Borja is quite busy and I'm trying to take care of the FTU

Comment on attachment 684841 [details] PR Hi folks, works for me as solution for *just* the timeout, if we add (as :timdream comments) the followup to structure the code for the system app in the correct way, that is already scheduled in Bug 814840. Thanks all you guys for checking and reviewing!