1034376 - [B2G][Homescreen] Vertical Homescreen can lock up when user moves icons

Status: RESOLVED FIXED

(Core :: Panning and Zooming, defect)

Description

[Eric Kramer [:Kramer]]

Attachment: Logcat_Vertical-Homescreen-unresponsive

Description:
Vertical Homescreen can lock up (preventing user input) when the user moves icons around. It occurs when the user is moving the icon rapidly down to the bottom of the screen. Users will have a hard time getting out of the locked environment, and repro is much easier after the first time hitting this issue. 

Repro Steps:
1) Update a Flame to 20140702040207
2) On Vertical Homescreen hold on an app (to enter edit)
3) Rapidly move it down to the bottom of the screen and back up
4) Focus the movements on the bottom of the screen (if the icon is dropped pick it up again)


Actual:
Eventually the user will lose control over the Vertical Homescreen. It will become unresponsive and often it will lock up.


Expected:
Users never loses control over the Vertical Homescreen. 


Environmental Variables:
Device: Flame Master
Build ID: 20140702040207
Gaia: 85e97290431ce6aa0a965421e84d6070cd899129
Gecko: 7075808c3306
Version: 33.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0


Notes:
Restarting the device is only a temporary fix. Resetting the device is also temporary.


Repro frequency: 4/5, 80%. It will happen eventually, sometimes it does take up to a minute to repro.
See attached: (video clip, logcat)

===============================================================================

This issue reproduces on Flame 2.1, 2.0

Flame 2.0
BuildID: 20140702000201
Gaia: 3bfe47c58c959c42f5ffe0309b5380ea514ccd69
Gecko: f40e767ea283
Version: 32.0a2 (2.0) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Buri Master (2.1)
BuildID: 20140702055200
Gaia: 85e97290431ce6aa0a965421e84d6070cd899129
Gecko: 49e7fc49dd4e
Version: 33.0a1 (Master) 
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Buri 2.0
BuildID: 20140702063010
Gaia: 085cdbf16dfd5249786016ac8ceafa1a54e88497
Gecko: a6e69640a00b
Version: 32.0a2 (2.0) 
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Actual:
Vertical Homescreen can become locked while moving the icons. 
-------------------------------------------------------------------------------

This issue does NOT repro on Flame 1.4 (issue requires vertical homescreen)

Flame 1.4
Build ID: 20140702003001
Gaia: 53a4ff9264d601ea963ead1a58e810c39580c0aa
Gecko: 9caa538df1f2
Version: 30.0 (1.4)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Buri 1.4
BuildID: 20140702160204
Gaia: 5f5a05e454960872d6d7766f322e1ce837de7458
Gecko: 137f0fa03d4a
Version: 30.0 (1.4) 
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Actual:
No Vertical Homescreen.

Comment 1

[Joshua Mitchell (Inactive)]

Kramer - you indicated there was a video, can you please post the link

QA-Wanted report - issue sounds worthy of a nom based on the lock-up and difficulty to recover

Comment 2

[bhavana bajaj [:bajaj]]

NI :kgrandon to start here.

Comment 3

[Kevin Grandon :kgrandon]

Seems like this is a platform issue. Would like to see a video though.

Comment 4

[Johan Lorenzo [:jlorenzo]]

The video can be found in the URL field: http://youtu.be/NVrKNQHXa-U

Definitely looks like a platform issue.

Comment 5

[Milan Sreckovic [:milan] (needinfo for best results)]

Some questions on the comment 0:
"Restarting the device is only a temporary fix."  - What does temporary mean?  Until next edit, or does this come back even with non-edit operations?

"3) Rapidly move it down to the bottom of the screen and back up." - is this "normal" rapid, or "I'm trying to break things" rapid?  Will the users think "this is broken" or "I managed to break it"?

Comment 6

[Kartikaya Gupta (email:[e-mail])]

From the video this very much seems like an edge case, not sure it needs to be a 2.0 blocker. It took me a few minutes to reproduce this, and locking/unlocking the homescreen fixes the bad state.

Comment 7

[Kartikaya Gupta (email:[e-mail])]

Attachment: APZ logging when this happens

Here's a log with APZC-logging enabled where I reproduced this. It happens towards the end of the log but I'm not sure of the exact timestamp it happen at. I haven't analyzed the log in detail yet either but a quick examination shows no obvious problems.

Comment 8

[Eric Kramer [:Kramer]]

(In reply to Milan Sreckovic [:milan] from comment #5)
> Some questions on the comment 0:
> "Restarting the device is only a temporary fix."  - What does temporary
> mean?  Until next edit, or does this come back even with non-edit operations?
> 
> "3) Rapidly move it down to the bottom of the screen and back up." - is this
> "normal" rapid, or "I'm trying to break things" rapid?  Will the users think
> "this is broken" or "I managed to break it"?

Restarting the device does remove the issue. But the issue did seem much easier to reproduce after hitting it the first time, even after restarting. And the user needs to enter edit and move icons around to reproduce the issue again. 

When I reproduced the issue it was more "I'm trying to break things." If users hit this issue they would probably believe they managed to break it.

Comment 9

[Jason Smith [:jsmith]]

Does the problem fix itself by putting the phone sleep & waking it back up?

Comment 10

[Kartikaya Gupta (email:[e-mail])]

It did when I reproduced it.

Comment 11

[Kartikaya Gupta (email:[e-mail])]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #7)
> Created attachment 8451688 [details]
> APZ logging when this happens
> 
> Here's a log with APZC-logging enabled where I reproduced this. It happens
> towards the end of the log but I'm not sure of the exact timestamp it happen
> at. I haven't analyzed the log in detail yet either but a quick examination
> shows no obvious problems.

I went through the log and while there's some weirdness, I don't see anything that would explain the observed behaviour. There appears to be a few places where the events get queued up while we wait for the content response on a long-tap or touch-start and eventually time out. It's possible that we end up in a mismatched state between the APZ and content, where content thinks it's done a prevent default but we really ignored it because it was too slow. I don't know if something like that could cause the observed behaviour. Fixing bug 1009733 may or may not help in this case, I don't really know.

Comment 12

[Kartikaya Gupta (email:[e-mail])]

No real evidence that this is related to the overscroll behaviour. Probably worth checking to see if it's reproducible with overscroll turned off in the settings.

Comment 13

[Joshua Mitchell (Inactive)]

Comment 10 seems to satisfy comment 9 and the Qa-Wanted flag:

Leaving Qa-Wanted tag to address comment 12 (test with overscroll turned off)

Comment 14

[Duane Dixon [:ddixon]]

(In reply to Joshua Mitchell (Joshua_M) from comment #13)
> Comment 10 seems to satisfy comment 9 and the Qa-Wanted flag:
> 
> Leaving Qa-Wanted tag to address comment 12 (test with overscroll turned off)

I was unable to reproduce bug with Overscrolling turned off in Settings>Developer.

Environmental Variables:
Device: Flame Master
Build ID: 20140707040201
Gaia: 93daa354671a698634a3dc661c8c9dcb7d824c31
Gecko: 1dc6b294800d
Version: 33.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Comment 15

[Kartikaya Gupta (email:[e-mail])]

I haven't been able to reproduce this again, and I don't think I can make any further progress with just the log that I got the last time. Botond, mind taking a look now that you're back? You might have better luck reproducing and tracking this down.

Comment 16

[Botond Ballo [:botond]]

I have a very hard time reproducing this on my Nexus 4, although I did repro it once. On a Flame I borrowed from Jeff, I can repro it at approximately the same repro rate as Eric.

My Nexus 4 has a debug build while the Flame I borrowed from Jeff has an optimized build, so the difference in repro rates could be Nexus vs. Flame, or Debug vs. Opt.

I'll try doing a optimized build for my Nexus and see what the repro rate there is.

Comment 17

[Botond Ballo [:botond]]

I couldn't repro on an optimized Nexus build, but I got a Flame of my own and repro'd and debugged there.

What seems to be happening is:

  1. We pan into overscroll.

  2. CancelAnimation() is called, probably due to a scroll offset update.
     The APZC state is reset to NOTHING, but there is no actual animation
     to cancel whose Cancel() method would clear the overscroll.

  3. Since the APZC state is NOTHING, the usual mechanism by which
     overscroll from panning is relieved (a snap-back animation after
     a fling after a touch-end) is not activated, and there is no
     other mechanism to relieve or clear the overscroll.

Comment 18

[Botond Ballo [:botond]]

Attachment: bug1034376.patch

This patch moves clearing of overscroll from AsyncPanZoomAnimation::Cancel() to AsyncPanZoomController::CancelAnimation(), so that it happens even if there isn't an active animation.

As a result, AsyncPanZoomAnimation::Cancel() and the OverscrollableAnimation base class became unnecessary, so I removed them. If you prefer keeping one or both for potential future use, let me know.

Try push: https://tbpl.mozilla.org/?tree=Try&rev=a7692510a06a

Comment 19

[Kartikaya Gupta (email:[e-mail])]

Comment on attachment 8454765 [details] [diff] [review]
bug1034376.patch

Review of attachment 8454765 [details] [diff] [review]:
-----------------------------------------------------------------

r=me, but this should have a test, I think.

::: gfx/layers/apz/src/AsyncPanZoomController.cpp
@@ +643,3 @@
>  public:
>    OverscrollSnapBackAnimation(AsyncPanZoomController& aApzc)
> +    : AsyncPanZoomAnimation()

Don't need this call to the superclass constructor, but you can leave it in if you like.

@@ +1759,5 @@
>    APZC_LOG("%p running CancelAnimation in state %d\n", this, mState);
>    SetState(NOTHING);
> +  mAnimation = nullptr;
> +  // Setting the state to nothing and cancelling the animation can
> +  // preempt normal mechanisms for relieving overscroll, so we near to clear

s/near/need/

Comment 20

[Botond Ballo [:botond]]

Attachment: bug1034376.patch

Addressed review comments, including adding a gtest. Re-requesting review for gtest.

Comment 21

[Kartikaya Gupta (email:[e-mail])]

Comment on attachment 8455430 [details] [diff] [review]
bug1034376.patch

Review of attachment 8455430 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks.

Comment 22

[Botond Ballo [:botond]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/40522c4512d0

Comment 23

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/40522c4512d0

Comment 24

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/244a3dc5bf49

Comment 25

[Sue]

Attachment: verify_video.MP4

According to the steps and video of comment 4, this issue has been verified successfully on Flame v2.1 & v2.0
See attachment: verify_video.MP4
Reproducing rate: 0/5
Flame 2.1 versions:
Gaia-Rev        38e17b0219cbc50a4ad6f51101898f89e513a552
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/8b92c4b8f59a
Build-ID        20141205001201
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141205.035305
FW-Date         Fri Dec  5 03:53:16 EST 2014
Bootloader      L1TC00011880

Flame 2.0 versions:
Gaia-Rev        856863962362030174bae4e03d59c3ebbc182473
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/e40fe21e37f1
Build-ID        20141207000206
Version         32.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141207.034341
FW-Date         Sun Dec  7 03:43:52 EST 2014
Bootloader      L1TC00011880