1024483 - Transition to home-screen on boot/after restarting home-screen flickers

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)

Description

[Chris Lord [:cwiiis]]

STR (which will also function as the description):

- Boot your phone (restart the b2g process or reboot)
- Unlock phone
- See home-screen appear normally, but then suddenly run a zoom animation

I see this 100% of the time on boot, but I also seem to see it every now and again when unlocking my phone after its been locked for a while - I assume it happens every time the home-screen gets relaunched and this second situation happens when it gets killed from memory pressure (or some such).

I suggest it as a blocker as it's a pretty poor-looking experience to happen the first time you use the phone (when it's guaranteed to happen).

I don't know if this is window management or the home-screen that's responsible for this animation right now.

Comment 1

[Jason Smith [:jsmith]]

QA Wanted for a video.

Comment 2

[Kevin Grandon :kgrandon]

The homescreen can't cause this, moving to system general for now.

Comment 3

[Kevin Grandon :kgrandon]

Though depending on the video this could potentially be graphics code? Maybe something with the low-res tiling?

Comment 4

[Chris Lord [:cwiiis]]

(In reply to Kevin Grandon :kgrandon from comment #3)
> Though depending on the video this could potentially be graphics code? Maybe
> something with the low-res tiling?

I have low-precision and progressive-paint turned off in this video, so that rules those out. It could be a problem with async CSS animations/transitions (OMTA), but I'd look at Gaia first before assuming that - I'd have expected a problem like this at the platform level to be more obvious.

Comment 5

[Cody Roesch [:croesch]]

Here is a video of Homescreen zooming when unlocking the phone on the 2.0 Flame. I'm not sure exactly if this is what he is referring to but this does look pretty bad.

http://youtu.be/kqk0UNqjRQg

Environmental Variables:
Device: Flame Master
Build ID: 20140417000006
Gaia: 7591e9dc782ac2e97d63a96f9deb71c7b3588328
Gecko: e71ed4135461
Version: 31.0a1 (Master) 
Firmware Version: v121-2

Comment 6

[Kevin Grandon :kgrandon]

I confirmed that I see this on 2.0. Flashing the system app on 2.1 appears to make this go away, so it's likely that something just needs to be uplifted. Alive - any ideas?

Comment 7

[Kevin Grandon :kgrandon]

I also confirmed that this impacts *any* homescreen that you use, including the classic. I'm unblocking the vertical homescreen from this for now, but we should probably block 2.0 on this and fix it.

Comment 8

[Jason Smith [:jsmith]]

QA Wanted to check 1.4.

Comment 9

[Cody Roesch [:croesch]]

This bug does NOT Repro on V1.4 Flame. Homescreen appears and no zooming is noticed.

Environmental Variables:
Device: Flame 1.4
Build ID: 20140612000202
Gaia: 7fc73d4cb1bece31f50e8ccf6fb98af3984a9ebf
Gecko: bcd308fbbf38
Version: 30.0 (1.4) 
Firmware Version: v121-2

---------------------------------------

Unable to repro this home screen zooming on the Buri V2.0.

Environmental Variables:
Device: Buri 2.0
Build ID: 20140612120529
Gaia: db510804ade17b355e73790aa120ec084b025cec
Gecko: 59f68f3bd59e
Version: 32.0a2 (2.0) 
Firmware Version: v1.2device.cfg

---------------------------------------

Verified this bug DOES repro on OpenC 2.0

Environmental Variables:
Device: Open_C 2.0
Build ID: 20140612000201
Gaia: 2bb66630315299ca947e40fcec23c9f7ea012111
Gecko: 670d69879f0e
Version: 32.0a2 (2.0) 
Firmware Version: P821A10V1.0.0B06_LOG_DL

-----------------------------------------------

The bug does NOT repro on OpenC 1.4. No homescreen zooming is seen.

Environmental Variables:
Device: Open_C 1.4
Build ID: 20140612000202
Gaia: 7fc73d4cb1bece31f50e8ccf6fb98af3984a9ebf
Gecko: bcd308fbbf38
Version: 30.0 (1.4) 
Firmware Version: P821A10V1.0.0B06_LOG_DL

--------------------------------------------------

The bug does NOT repro in Flame Base v121-2.

Environmental Variables:
Device: Flame 1.3
Build ID: 20140610200025
Gaia: e106a3f4a14eb8d4e10348efac7ae6dea2c24657
Gecko: b637b0677e15318dcce703f0358b397e09b018af
Version: 28.0 (1.3) 
Firmware Version: v121-2

Comment 10

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

B2g-inbound Regression Window

Last working 
Environmental Variables:
Device: Flame
BuildID: 20140430113000
Gaia: 8873166797fecfa65c0afa644d2ebcc7d7cb4ed3
Gecko: 3d4178a07d6a
Version: 32.0a1

First Broken 
Environmental Variables:
Device: Flame
BuildID: 20140430143002
Gaia: ddd3092cd9340a5b89d5bf715dbb0f8c8aad9634
Gecko: 3be37517e259
Version: 32.0a1

Last working gaia / First broken gecko - Issue does NOT occur
Gaia: 8873166797fecfa65c0afa644d2ebcc7d7cb4ed3
Gecko: 3be37517e259

First broken gaia / Last working gecko - Issue DOES occur
Gaia: ddd3092cd9340a5b89d5bf715dbb0f8c8aad9634
Gecko: 3d4178a07d6a

Gaia Pushlog:  https://github.com/mozilla-b2g/gaia/compare/8873166797fecfa65c0afa644d2ebcc7d7cb4ed3...ddd3092cd9340a5b89d5bf715dbb0f8c8aad9634

Comment 11

[(inactive after 6/18) Alive Kuo [:alive]]

Hi there, I could fix this but what's really expected?
No any transition when from lockscreen -> homescreen?

Comment 12

[Kevin Grandon :kgrandon]

I think the bug is that on first boot the animation is different than any other unlock animation after the first boot.

Comment 13

[Stephany Wilkes]

Flagging Peter to confirm but agree with Kevin: issue appears to be that the animations are different.

Comment 14

[Jason Smith [:jsmith]]

Broken by bug 985037.

Comment 15

[(inactive after 6/18) Alive Kuo [:alive]]

We could make it the same: no transition on first launch or always doing zoom transition.

Comment 16

[Peter La]

Hey Chris/Kevin,

I can confirm the issue that Chris has reported (I'm on today's master).  What is happening is that when you unlock, the icons are sitting there already on the homescreen - then they disappear, and the zoom happens (the icons start big and offscreen and quickly scale down to their final positions).

I have 2 suggested solutions, first one is our ideal.  The second one may be less work (I'm not sure), but will at least address this particular issue.



SOLUTION 1 'Our Ideal Solution':

I really like the transition when exiting an app.  So if you launch an app, and then exit, you'll see that the app scales down and fades into nothingness.  At the same time, the homescreen icons will scale down from a very large size (partially offscreen), until it reaches it's final size, which represents the homescreen in it's static form.  The effect of this transition is to look like the app window and the app icons are going in the same direction (into the screen along the z-axis).

Now, we currently don't have the same transition from lock to home.  When unlocking, the lockscreen actually zooms the other direction (getting larger until it fades out of view, partially clipped by the screen), and the app icons do not do the zoom.

So, it would be great if the lock -> home transition was exactly like the transition when exiting an app.  Lockscreen gets smaller, and fades, app icons start really large, and get smaller, fading into their final positions on the homescreen.

Then with the actual bug, we just do the same transition, except you get rid of the part where the icons are already sitting there, disappear, and then zoom.

SOLUTION 2:

This solution would just be to get rid of the icon zoom animation in the lock -> home transition on a restart/cold start so that it's consistent with the current lock -> home transition.

Let me know if that makes sense or not, and whether you need some visual mockups to illstrate it.

Thanks,
Peter

Comment 17

[(inactive after 6/18) Alive Kuo [:alive]]

Hi Peter,

The solution#1 makes sense but I wonder if this is a new design to lockscreen visual (zoom-out animation). If this doesn't conflict with previous lockscreen UX we could try to implement that.

Comment 18

[Peter La]

Hi Alive, I'm going to flag a few people from UX who are more involved in lockscreen just as a sanity check for solution #1.

Comment 19

[Amy Lee [:amylee] UX]

(In reply to Peter La from comment #18)
> Hi Alive, I'm going to flag a few people from UX who are more involved in
> lockscreen just as a sanity check for solution #1.

I think it makes sense for the lockscreen to shrink and disappear when unlocked if we base this on our current animation for opening and closing apps. When you open an app from homescreen, it enlarges and shrinks when you close the app. By that logic, if we treat the unlock screen as exiting when you unlock or when you go to camera from the lockscreen then it should shrink.

We can see what UX has to say.

Comment 20

[Rob MacDonald [:robmac]]

I'm not able to replicate this using today's master on flame. Is this still a valid bug?

Comment 21

[Kevin Grandon :kgrandon]

(In reply to Rob MacDonald [:robmac] from comment #20)
> I'm not able to replicate this using today's master on flame. Is this still
> a valid bug?

I am still seeing it. Did you restart the device when testing? A video might help here, but I think we were asking for Rob's input on the ideal approach in comment 16.

Comment 22

[Fang Shih [:fang]]

(In reply to Peter La from comment #18)
> Hi Alive, I'm going to flag a few people from UX who are more involved in
> lockscreen just as a sanity check for solution #1.

I agreed with you. I think solution #1 makes more sense. It would be nice to have the unlock screen using the same transition logic. Based on our current transition for exiting and launch an app.

Comment 23

[Peter La]

Hey guys,

I just realized that my solution #1 suggestion breaks the Haida spacial model, because the lockscreen physically sits on a layer above homescreen.  So we can't do solution #1.

My proposal is that we do solution #2, and if there is time, we can make it nicer by making the homescreen start small and scale up to it's final size (kind of the opposite of what happens when you exit an app) during the lock -> home transition.  It would have to start at some level of transparency as well, and fade in to 100%.

Alive, Rob, Gordon - does this sound ok?

Comment 24

[Rob MacDonald [:robmac]]

That sounds ok to me.

Comment 25

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Peter, Alive, since this bug is qualified as a regression, let's do comment 15 without doing any fancy in this bug. If we somehow have some conclusion on what can be done differently, please file another bug and fix it there.

Comment 26

[Gordon Brander :gordonb]

(In reply to Alive Kuo [:alive][NEEDINFO!][OOO until 6/30] from comment #11)
> Hi there, I could fix this but what's really expected?
> No any transition when from lockscreen -> homescreen?

Let's get rid of the animation ONLY for the lockscreen -> homescreen transition. I don't think its important to maintain continuity between lockscreen -> homescreen and app -> homescreen, since these are 2 separate views.

Later, If lockscreen becomes a part of the spacial model we can revisit. For now, let's do the simple thing and remove the lockscreen -> homescreen transition.

Comment 27

[Peter La]

Sounds good to me. :)

Comment 28

[(inactive after 6/18) Alive Kuo [:alive]]

I am going to implement immediate homescreen animation for lockscreen->homescreen transition.

Comment 29

[(inactive after 6/18) Alive Kuo [:alive]]

Attachment: https://github.com/mozilla-b2g/gaia/pull/21157

v1: Use immediate transition if there's no active app and the next is homescreen.

Comment 30

[(inactive after 6/18) Alive Kuo [:alive]]

There's one tbpl failure about creating new alarm but I am thinking it's irrelative.
https://tbpl.mozilla.org/?tree=Gaia-Try&rev=e54c9ab940f0990463ceb9360954057e66d75a90
Re-run to see if it's intermittent.

Comment 32

[(inactive after 6/18) Alive Kuo [:alive]]

I am sure the failure is unrelated. Reopen if disagree.
https://github.com/mozilla-b2g/gaia/commit/227d5f8515de16307cb55e86e991af5dc0e05363

Comment 33

[Ryan VanderMeulen [:RyanVM]]

v2.0: https://github.com/mozilla-b2g/gaia/commit/c27e9fdc65248ce02802b502596b9c592f8b776e

Comment 34

[Elie]

Attachment: VIDEO0074_Compress.MP4

This issue has been successfully verified on Flame 2.0:
Gaia-Rev        8d1e868864c8a8f1e037685f0656d1da70d08c06
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/c756bd8bf3c3
Build-ID        20141127000203
Version         32.0
Device-Name     flame
FW-Release      4.4.2


This issue has been successfully verified on Flame 2.1:
Gaia-Rev        5372b675e018b6aac97d95ff5db8d4bd16addb9b
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/f34377ae402b
Build-ID        20141127001201
Version         34.0
Device-Name     flame
FW-Release      4.4.2