Closed Bug 1220812 Opened 9 years ago Closed 6 years ago

After unlocking the device from the lockscreen there is a long pause until reaching the home screen

Categories

(Firefox OS Graveyard :: Gaia::System::Lockscreen, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.5?, b2g-v2.2 unaffected, b2g-v2.5 affected, b2g-master affected)

RESOLVED WONTFIX
blocking-b2g 2.5?
Tracking Status
b2g-v2.2 --- unaffected
b2g-v2.5 --- affected
b2g-master --- affected

People

(Reporter: KTucker, Unassigned, NeedInfo)

References

Details

(Keywords: regression, Whiteboard: [2.5-Daily-Testing][Spark])

Attachments

(1 file)

When the user slides to unlock the device from the lockscreen, there is a good 5 second delay before the user reaches the home screen. Also, the user is not prompted for a couple seconds after reaching the home screen for their SIM pin.

Prerequisite:
Lockscreen and a SIM PIN is enabled on the device.

Repro Steps:
1) Update a Flame to 20151102004502
2) Reboot the device.
3) After reaching the lockscreen, slide to unlock and pay close attention to the time it takes to reach the homescreen.

Actual:
There is a long delay after unlocking the device to reach the home screen and for the SIM PIN to be prompted to the user.

Expected:
The device unlocks properly and the user is immediately prompted for their SIM pin.

Environmental Variables:
Device: Flame 2.5 (Full Flash)(KK)(512mb)
Build ID: 20151102004502
Gaia: 91cac94948094cfdcd00cba5c6483e27e80cb3b0
Gecko: b6b410d4610da18f5e43750e67ed2c56a0c0f812
Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a
Version: 44.0a1 (2.5)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

Repro frequency: 5/5 100%
See attached: video clip, logcat,
This also occurs on Aries 2.6 and Flame 2.6

There is a long delay when unlocking the device. 

Device: Aries 2.6
Build ID: 20151030120435
Gaia: 91cac94948094cfdcd00cba5c6483e27e80cb3b0
Gecko: c2534acb485963331d67bbc5c07f0d862ed56bf5
Gonk: a19052e4389c3ae2d8fc3e7a74a475401baacc56
Version: 45.0a1 (2.5)
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0

Device: Flame 2.6
Build ID: 20151102030250 (Full Flash)(KK)(512mb)
Gaia: bfcf8e9bfa7ba264c5f8bc865ce8a435f9b134cb
Gecko: 451a185791433bce1a6a894c27f3da60a3119431
Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a
Version: 45.0a1 (2.5)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0


This is not occurring on Flame 2.2

There is not a delay when unlocking the screen. 

Device: Flame 2.2 (Full Flash)(KK)(512mb)
Build ID: 20151102032501
Gaia: 885647d92208fb67574ced44004ab2f29d23cb45
Gecko: b8b7f4efaa6e
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 37.0 (2.2)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
Whiteboard: [2.5-Daily-Testing][Spark]
This seems to only happen if the user immediately tries to unlock the device after a reboot. If the user waits a bit after reaching the locksceen to unlock then there is no delay.
blocking-b2g: --- → 2.5?
Assignee: nobody → mmurrell
QA Contact: mmurrell
QA Whiteboard: [QAnalyst-Triage+]
Assignee: mmurrell → nobody
This issue is caused by the changes from Bug 1094759. 

b2g-inbound Regression Window. 
Last Working
Environmental Variables:
Device: Flame 2.5
BuildID: 20150604012244
Gaia: e0fbadeb78a96137f071d9be7a47ef9fe882d17f
Gecko: 64ce149fabf1
Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd
Version: 41.0a1 (2.5) 
Firmware Version: v18D

First Broken
Environmental Variables:
Device: Flame 2.5
BuildID: 20150604020845
Gaia: c1ef854924f18357832ddcf98dc6c42391d5599e
Gecko: 7f39acd9fc64
Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd
Version: 41.0a1 (2.5) 
Firmware Version: v18D

Last Working gaia / First Broken gecko - Issue does not occur
Gaia: e0fbadeb78a96137f071d9be7a47ef9fe882d17f
Gecko: 7f39acd9fc64

First Broken gaia / Last Working gecko - Issue does occur
Gaia: c1ef854924f18357832ddcf98dc6c42391d5599e
Gecko: 7f39acd9fc64

Gaia Pushlog: https://github.com/mozilla-b2g/gaia/compare/e0fbadeb78a96137f071d9be7a47ef9fe882d17f...c1ef854924f18357832ddcf98dc6c42391d5599e
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(jmercado)
Gregor do you know who should look into this issue.  Seems to have been caused by the changes for bug 1094759, but Alive is no longer working on this product.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmercado) → needinfo?(anygregor)
(In reply to Jayme Mercado [:JMercado] from comment #4)
> Gregor do you know who should look into this issue.  Seems to have been
> caused by the changes for bug 1094759, but Alive is no longer working on
> this product.

We boot up much faster but the homescreen wont be ready when we unlock right away. Not sure what we can do here. I guess we should get UX and engineering input to discuss some options.
Chris, can we do something here?
Rob, should we show some message to the user that the homescreen is loading? Or get some animation in place?
Flags: needinfo?(rmacdonald)
Flags: needinfo?(chrislord.net)
Flags: needinfo?(anygregor)
(In reply to Gregor Wagner [:gwagner] from comment #5)
> (In reply to Jayme Mercado [:JMercado] from comment #4)
> > Gregor do you know who should look into this issue.  Seems to have been
> > caused by the changes for bug 1094759, but Alive is no longer working on
> > this product.
> 
> We boot up much faster but the homescreen wont be ready when we unlock right
> away. Not sure what we can do here. I guess we should get UX and engineering
> input to discuss some options.
> Chris, can we do something here?
> Rob, should we show some message to the user that the homescreen is loading?
> Or get some animation in place?

New homescreen already has a faster visualLoad time than verticalhome and there will likely be further improvements down the line (thinking specifically of bug 1220186), but I don't think there's much more to improve things significantly without making large sacrifices to code maintainability/flexibility.

Maybe we should be waiting for navigationLoaded or visuallyLoaded on home screen before removing the splash screen? Of course we'd still be waiting just as long, but at least it'd be obvious to the user that there is still loading happening.
Flags: needinfo?(chrislord.net)
(In reply to Gregor Wagner [:gwagner] from comment #5)
> (In reply to Jayme Mercado [:JMercado] from comment #4)
> > Gregor do you know who should look into this issue.  Seems to have been
> > caused by the changes for bug 1094759, but Alive is no longer working on
> > this product.
> 
> We boot up much faster but the homescreen wont be ready when we unlock right
> away. Not sure what we can do here. I guess we should get UX and engineering
> input to discuss some options.
> Chris, can we do something here?
> Rob, should we show some message to the user that the homescreen is loading?
> Or get some animation in place?

Just some notes :)

1. We could take homescreen loading into account before removing the splash screen.
https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/launcher.js#L115-L150
2. We could make homescreen faster to load but this seems impossible in timeframe.
(In reply to alegnadise+bug from comment #7)
> (In reply to Gregor Wagner [:gwagner] from comment #5)
> > (In reply to Jayme Mercado [:JMercado] from comment #4)
> > > Gregor do you know who should look into this issue.  Seems to have been
> > > caused by the changes for bug 1094759, but Alive is no longer working on
> > > this product.
> > 
> > We boot up much faster but the homescreen wont be ready when we unlock right
> > away. Not sure what we can do here. I guess we should get UX and engineering
> > input to discuss some options.
> > Chris, can we do something here?
> > Rob, should we show some message to the user that the homescreen is loading?
> > Or get some animation in place?
> 
> Just some notes :)
> 
> 1. We could take homescreen loading into account before removing the splash
> screen.
> https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/launcher.
> js#L115-L150

Well, it's very simple to customize. Just need someone to test if this slows system boot-up too much. I guess not because :cwiiis commented it's fast!

https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/launcher.js#L140-L145
[Before]
            return Promise.all([
              this.service.request('CoverScreen:animatePoweronLogo'),
              this.service.request('HomescreenLauncher:launch',
                homescreenManifestURL),
              this.scheduler.release()
            ]);
[After]
            return this.service.request('HomescreenLauncher:launch',
                homescreenManifestURL).then(function() {
              return Promise.all([
                this.service.request('CoverScreen:animatePoweronLogo'),
                this.scheduler.release()
              ]);
            });

Promise conquers!
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][severe]
I found this fixed in build 20160131030220 but I'm not sure it helps because I use the nightly-latest update channel.
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: