Intentional? Just happened to notice today on gaia e2d1b046ecbf3f79a18e8bae44b51fe61f111421 .

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

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

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

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

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.

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.

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

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

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

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

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

(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.

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.

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

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.

(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!

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

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?

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.

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

(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(-)

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 on attachment 721731 [details] [diff] [review] patch v1 Thanks for the investigation and fix!

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

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

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

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

does not make sense to create a regression issue.

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

(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.

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...)

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

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

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.)

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.

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.