838486 - [Lockscreen] Lock screen bounce animation not running

Status: VERIFIED FIXED

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

Description

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Intentional?  Just happened to notice today on gaia e2d1b046ecbf3f79a18e8bae44b51fe61f111421 .

Comment 1

[Andrew Overholt [:overholt]]

Seems to work for me using a 2013-02-05 nightly on unagi.  There seems to be a long timeout before it happens, though.

Comment 2

[Lukas Blakk [:lsblakk] use ?needinfo]

Let's see if qa can repro, if not close out, but even if it is reproducible it's not a blocker.

Comment 3

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

I haven't seen this run for days.  If there's a timeout it seems to be longer than the default screen-off timeout.

Comment 4

[Marcia Knous [:marcia]]

I see the bounce animation on an incoming call, but I don't see it when I unlock the screen. Using:

Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/3f905f0ca9ce
Gaia   ecca2ee860825547d5e1109436b50b74dfe9261e
BuildID 20130212070205
Version 18.0

Comment 5

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

The b2g process is still consuming 40% CPU so it seems like we're /trying/ to run the animation.

Since no one seems to care that the bouncing is gone, let's please disable this and not drain the battery.

Comment 6

[Lukas Blakk [:lsblakk] use ?needinfo]

This still isn't a blocker - but please file a separate bug and nom (with assignee) for the CPU consumption/turning off the animation process.

Would still be great to get a regression window here so if product decides to try returning the bounce animation we know where to look.

Comment 7

[Lukas Blakk [:lsblakk] use ?needinfo]

Needs info on Daniel in case this is something TEF wants to block on for UX concerns.

Comment 8

[Lukas Blakk [:lsblakk] use ?needinfo]

Tony - do you have a contractor who can look into finding the regression window here?

Comment 9

[mdaniloff]

For regression window of this bug,this bug does not reproduce on:1/30
recieving call: bounce
message:bounce
For regression window of this bug,this bug does reproduce on 1/31
recieving call:bounce
message:no bounce

Comment 10

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

It seems that tapping the bar makes the animation start.  Does that ring any bells?

Comment 11

[mdaniloff]

So for verification there are three instances for the bouncing ball animation to occur:
recieving call, recieving mms, and tapping the bar

Comment 12

[Tony Chung [:tchung]]

(In reply to Lukas Blakk [:lsblakk] from comment #8)
> Tony - do you have a contractor who can look into finding the regression
> window here?

comment 9.

Comment 13

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Does anyone know if this was intentional change from UX or not?

Based on the churning CPU usage, I'm guessing it was not intentional.

Comment 14

[Patryk Adamczyk [:patryk] UX]

We'd want that bounce effect to hint at unlocking.

Comment 15

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Sorry, the specific question was:

A few weeks ago, the bounce animation started as soon as the screen turned on.  (After a short timeout.)

Currently, the bounce animation only starts after the user has tapped the unlock bar.

Was that intentional, or is there a regression somewhere?  I.e., what's the UX spec.

Comment 16

[Victoria Gerchinhoren [:vicky]]

(In reply to Chris Jones [:cjones] [:warhammer] from comment #15)
> Sorry, the specific question was:
> 
> A few weeks ago, the bounce animation started as soon as the screen turned
> on.  (After a short timeout.)
> 
> Currently, the bounce animation only starts after the user has tapped the
> unlock bar.
> 
> Was that intentional, or is there a regression somewhere?  I.e., what's the
> UX spec.

This is not intentional, it is clearly a bug. The bouncing effect should start just a few seconds after the screens turns on (3 sec) to give the user a hint of the action that must be done in order to unlock. Please fix.
Thanks!

Comment 17

[steve]

 Yes this is a bug, as Victoria mentioned The bouncing effect should start just a few seconds after the screens turns on (3 sec) to give the user a hint of the action that must be done in order to unlock.

Note the animation should be made up of 3 decreasing bounces, 

However at present the animation that happens when you tap arrow has an extra (4th) little glitch bounce at the end, this should be removed.

Thanks

Comment 18

[Daniel Holbert [:dholbert]]

I think the most useful thing right now would be to develop pushlogs for the regression range that was determined in comment 9.  (I imagine there'd be a pushlog for gecko, one for gaia, and maybe others as well?)

Once we've got those pushlogs, hopefully it should be obvious which commits might've been responsible for this.

Could someone who's familiar with b2g nightlies (and finding the revisions they're built from) do that?

Comment 19

[Daniel Holbert [:dholbert]]

OK, I think I got the regression pushlogs, and I tracked down what regressed this.

tl;dr: this is a gaia bug, caused by bug 830480.

Details:
* Assuming the dates in comment 9 are for "mozilla-b2g18-unagi", then this boils down to these sources.xml files (which contain cset IDs):
https://pvtbuilds.mozilla.org/pub/mozilla.org/b2g/nightly/mozilla-b2g18-unagi/2013/01/2013-01-30-07-02-01/sources.xml
https://pvtbuilds.mozilla.org/pub/mozilla.org/b2g/nightly/mozilla-b2g18-unagi/2013/01/2013-01-31-23-02-04/sources.xml
(I picked the earliest 1/30 build, and the latest 1/31 build)

* That produces these pushlogs for gaia and gecko:
https://hg.mozilla.org/integration/gaia-v1-train/pushloghtml?fromchange=ab0015e21052&tochange=49fa2a6f8b50
https://hg.mozilla.org/releases/mozilla-b2g18/pushloghtml?fromchange=4593f3e765eb&tochange=06ddf5f299b5

* The gaia pushlog included
> 	https://hg.mozilla.org/integration/gaia-v1-train/rev/54f03268e8dd
>	Julien Wajsberg — Bug 830480 - [Lockscreen] Tapping camera and unlock buttons rapidly on passcoded phone hangs lockscreen r=timdream
...which looked relevant.

* I tried locally reverting that patch in a gaia clone being used by desktop b2g emulator, and I confirmed that that fixed this. (I was able to see this bug in that build, before I reverted the patch.)

SO: bug in the lockscreen gaia code, caused by Bug 830480.

Comment 20

[Julien Wajsberg [:julienw]]

thanks, I take this and will try to find today why this change broke this.

Comment 21

[Julien Wajsberg [:julienw]]

Attachment: patch v1

(also see PR https://github.com/mozilla-b2g/gaia/pull/8500)

Before Bug 830480, a callback was called sometimes synchronously and sometimes
asynchronously. In Bug 830480 it was made always asynchronous.

As a result, when switching panels, the "cleaning" code for the unloaded panel
is now always done after the "initializing" code for the loaded panel.

The "main" panel is enabling the bounce animation at initialization and
disabling at unload. Therefore it was disabled right after being enabled.

Note that the bounce animation is also enabled at lock, and disabled at unlock.

This patch skip the loading/unloading command when we ask to switch to the panel
that is already displayed. This should also make the performance better, because
it was actually called several times.
---
 apps/system/js/lockscreen.js |   11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

Comment 22

[Julien Wajsberg [:julienw]]

Regarding comment 5, I'm quite affirmative that the animation was not playing. The playElastic function was never called. So the CPU consumption probably comes from somewhere else. And I actually don't see this 40% consumption with master.

Comment 23

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

Comment on attachment 721731 [details] [diff] [review]
patch v1

Thanks for the investigation and fix!

Comment 24

[Julien Wajsberg [:julienw]]

master: https://github.com/mozilla-b2g/gaia/commit/c9617dfaaf0b9d2889c1bdc7b02b471f8f493c0e

Comment 25

[Daniel Holbert [:dholbert]]

This needs to be uplifted (to wherever bug 830480 was uplifted), right?

Comment 26

[Julien Wajsberg [:julienw]]

Daniel > Right. For v1-train this will be done automatically (because it's tracking+) but for v1.0.1 I nominate tef? then.

Comment 27

[John Ford [:jhford] CET/CEST Berlin Time]

Uplifted commit c9617dfaaf0b9d2889c1bdc7b02b471f8f493c0e as:
v1-train: ff667000e835792e457f58a8e5721358c94964e3
v1.0.1: 3630dfa447faaee8b0de75429baa51d15e91dc5f

Comment 28

[amiller]

does not make sense to create a regression issue.

Comment 29

[mlevin]

Verified Fixed the following:
Receiving an incoming call and receiving a text message results in the lock screen bounce animation to appear.

Verified on Unagi with the following:
Build ID: 20130325070201
Kernel Date: Dec 5
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/4931ec89ebbe
Gaia: 701b594c3e320030c538aa19f702764b29a6cc1c

Comment 30

[Daniel Holbert [:dholbert]]

(In reply to mlevin from comment #29)
> Verified Fixed the following:
> Receiving an incoming call and receiving a text message results in the lock
> screen bounce animation to appear.

Per comment 4, that's not the use-case that this was filed about -- those (at least, incoming call) already worked.  --> Removing "Verified" status.

To verify this: Turn the screen off and then on again.  Is there a bounce animation for the unlock icons? If so, then this bug is fixed.

Comment 31

[Daniel Holbert [:dholbert]]

mlevin says that he *can* still reproduce the bug (no lockscreen animation when he turns screen off & on), presumably with the build noted in Comment 29.

Presumably that build should've included jhford's v1.0.1 backport from comment 27... If so, then the backport-fix apparently didn't work.

jhford / julienw, perhaps one of you could confirm whether or not this is fixed on 1.01 and (if not) look into why not?  (Probably worth double-checking that it's actually fixed on trunk, too...)

Comment 32

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #31)
> mlevin says that he *can* still reproduce the bug
(in private email exchange w/ me)

Comment 33

[mlevin]

Issue as mentioned in comments #4 and#30 reproduces. Upon turning the screen back on there is no bounce animation for the unlock icons.

Tested on Unagi with the following:
Build ID: 20130325070201
Kernel Date: Dec 5
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/4931ec89ebbe
Gaia: 701b594c3e320030c538aa19f702764b29a6cc1c

Comment 34

[Daniel Holbert [:dholbert]]

Actually -- mlevin, just to be sure -- did you give it a little while (let's say 5+ seconds, for good measure) to start bouncing?  If you're not sure, could you give that a try?

On my unagi (which as a B2G 1.1.0.0-prerelease "beta channel" build), the animation plays after exactly 5 seconds.  (This appears to be the correct/expected results.)

Comment 35

[Julien Wajsberg [:julienw]]

I just saw it working in a 1.0.1 build on my device.

Also, I see my change on the v1.0.1 branch.

Comment 36

[mlevin]

Agreed. Test passes on my Unagi with the following:

Build ID: 20130325070201
Kernel Date: Dec 5
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/4931ec89ebbe
Gaia: 701b594c3e320030c538aa19f702764b29a6cc1c

Had to wait for 5 seconds then was able to observe the bounce animation.