1113386 - [Homescreen] In edit mode when moving an icon from area to area icon will freeze

Status: RESOLVED FIXED

(Core :: Panning and Zooming, defect)

Description

[[:RJ]]

Attachment: logcat_20141218_1438.txt

Description:
In edit mode when moving an icon from area to area icon will freeze and remain highlighted till user taps on another area of the screen


Repro Steps:
1) Update a Flame to 20141218040201
2) Long press an app to go into edit mode 
3) Press and hold an app till it is selected  
4) Slide finger up on selected app (bug was reproduced holing icon over divider) 


Actual:
(Describe the behavior you actually observed)


Expected:
(Describe the behavior you expected to have observed)

Environmental Variables:
Device: Flame 2.2 (319mb)(Kitkat Base)(Full Flash)
Build ID: 20141218040201
Gaia: 58734e8a48157f99d5b733412b600c2e04c954fe
Gecko: 5c7a6294b82a
Gonk: e5c6b275d77ca95fb0f2051c3d2242e6e0d0e442
Version: 37.0a1 (2.2)
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0



Repro frequency: 4/10
See attached:logcat, video clip: http://youtu.be/CRU2_00vTpc

Comment 1

[[:RJ]]

Actual:
Icon sticks on screen 


Expected:
Icon does not stick 

issue was  affected in  2.1 flame or 2.0
Icons do not stick 

Flame 2.1

Environmental Variables:
Device: Flame 2.1 (319mb)(Kitkat Base)(Full Flash)
Build ID: 20141218001205
Gaia: 14315733e2d265a42f9ab02d1aba191789870f70
Gecko: ddecea83ce6e
Gonk: e5c6b275d77ca95fb0f2051c3d2242e6e0d0e442
Version: 34.0 (2.1)
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0


Flame 2.0
Environmental Variables:
Device: Flame 2.0 (319mb)(Kitkat Base)(Full Flash)
Build ID: 20141218000204
Gaia: d04710d5d643eeff5a6493aef92a1af672a2769c
Gecko: decf1ee4464e
Gonk: e5c6b275d77ca95fb0f2051c3d2242e6e0d0e442
Version: 32.0 (2.0)
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 2

[Michael Henretty [:mikehenrty][:mhenretty]]

Can we have a regression window?

Comment 3

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

B2g-inbound Regression Window

Last Working 
Environmental Variables:
Device: Flame 2.2
BuildID: 20141126091427
Gaia: 7878734c7baf7d0c665c2f838168fce21cdc95b6
Gecko: e308fc2fc85e
Version: 36.0a1 (2.2) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

First Broken 
Environmental Variables:
Device: Flame 2.2
BuildID: 20141126094226
Gaia: 7878734c7baf7d0c665c2f838168fce21cdc95b6
Gecko: 6780420c1572
Version: 36.0a1 (2.2) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Last Working gaia / First Broken gecko - Issue DOES occur
Gaia: 7878734c7baf7d0c665c2f838168fce21cdc95b6
Gecko: 6780420c1572

First Broken gaia / Last Working gecko - Issue does NOT occur
Gaia: 7878734c7baf7d0c665c2f838168fce21cdc95b6
Gecko: e308fc2fc85e

Gaia Pushlog: http://hg.mozilla.org/integration/b2g-inbound/pushloghtml?fromchange=e308fc2fc85e&tochange=6780420c1572

Comment 4

[Joshua Mitchell (Inactive)]

Both patches in the push-log are from you, Kats - can you take a look?

Comment 5

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

From the video I'm assuming that "icon sticks on screen" means that the icon remains in the enlarged state that it takes on while you're dragging it around. I tried to reproduce this locally and could not. I'll try a bit more but it would be good to have better STR.

Comment 6

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

Ok, I can sort of repro just by long-pressing an icon and letting go while in edit mode. It doesn't work every time but often enough to debug.

Comment 7

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

Ok, specific STR are:
- enter edit mode on the home screen
- do a fling
- while the screen is flinging, put your finger down into a long-press
if you hit an icon (quite likely) then the icon will grow in size to indicate it is draggable, but further touchmoves/touchend events do not get delivered to gaia.

The reason this is happening is that the while in the fling, the APZC is "in fast motion". The touchstart that begins the long-press therefore does not get sent to content, but is eaten in the APZC. However the GEL still detects a long-press and dispatches that to content. This results in the creation of a new input block (via InjectNewTouchBlock) which is intended to deal with the prevent-defaulted-ness of the longpress. Moving or lifting your finger at this point will put the touch events into this new input block and will also attempt to deliver them to content. However since the gecko nsPresShell touch-tracking code never got the touch-start that began this touch session, it drops all of these events. Therefore the content effectively only gets a long-press and nothing else.

I think the bug here is that the long-press is generated at all. If you put your finger down during a fast-motion it should just stop the fling and not actually trigger a long press.

There also appears to be a separate bug where sometimes the code thinks the APZC is "in fast motion" when visually it's not moving. This is much more intermittent.

Comment 8

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

Attachment: Patch

Comment 9

[Botond Ballo [:botond]]

Comment on attachment 8540313 [details] [diff] [review]
Patch

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

::: gfx/layers/apz/src/AsyncPanZoomController.cpp
@@ +1662,5 @@
>      int32_t modifiers = WidgetModifiersToDOMModifiers(aEvent.modifiers);
>      CSSPoint geckoScreenPoint;
>      if (ConvertToGecko(aEvent.mLocalPoint, &geckoScreenPoint)) {
> +      if (CurrentTouchBlock()->IsDuringFastMotion()) {
> +        return nsEventStatus_eIgnore;

Perhaps add a logging statement here?

Comment 10

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

Added logging statement and landed:

https://hg.mozilla.org/integration/b2g-inbound/rev/2f392da0634f

Comment 11

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/2f392da0634f