1158928 - [Window Mgmt] Card View appears 'jumpy', cards shake when gestured between and may linger on screen too long

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::System::Task Manager, defect)

Description

[Oliver Nelson [:oliverthor]]

Attachment: logcat_20150427_1129.txt

Description:
When the user has multiple apps ( or browser windows) open, they observe that when opening the 'Card View' (or 'Show Windows') functionality of Window Management, that gesturing between cards has become loose. Cards tend to shake when you gesture between them, sometimes graphical hitches occur where the cards will flash across another. It was also observed of an app 'lingering' in view and slowly peeling off the screen.


Repro Steps:
1) Update a Flame to 20150427010202
2) Open a handful of apps
3) Hold home button to open card view
4) Gesture between cards
--- or ---
1) Update a Flame to 20150427010202
2) Open the Browser
3) Navigate around and open multiple windows (3+)
4) Hold '...' and find 'Show Windows'
5) Gesture between cards/windows in this view


Actual:
Card View gestures make cards/windows shake, exhibit graphical faults when navigating.
** effects seem heightened when a 'stronger' gesture is given that would throw the card further than the UI will allow it

Expected:
Card View gestures elicit smooth motion from the cards/windows being maneuvered. No sudden shaking of cards.


Environmental Variables:
---------------------------------

Device: Flame 3.0
Build ID: 20150427010202
Gaia: b4c949cdc780893897c9b45c1adea46e2eb694ff
Gecko: 37d60e3b8be6
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 40.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0

Device: Flame 2.2
BuildID: 20150427002504
Gaia: 265ca0bc9408c21fc4b25a259fcee7fb642cd06b
Gecko: 1908685d798d
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 37.0 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
---------------------------------

Issue does not occur on flame for 2.1 devices:
Results: Card View has larger cards and is slower to navigate

Device: Flame 2.1
BuildID: 20150427001201
Gaia: bbe983b4e8bebfec26b3726b79568a22d667223c
Gecko: 82a14be0462c
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 34.0 (2.1) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
---------------------------------

Repro frequency: 5/5
See attached: 
video- https://youtu.be/b6rg1yn2mT8
logcat

Comment 1

[Gregor Wagner [:gwagner]]

Noticed this as well. Seems like a regression.

Comment 2

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

[Blocking Requested - why for this release]:

Visible UX regression. Nominating to block 2.2

Comment 3

[Yeojin Chung [:YeojinC]]

I have a hard time deciding whether the build is broken or not, as the difference between builds during the card view transition does not seem to be clear. Here's my initial regression window, which I'm not quite confident about. Leaving my name off for someone else to try. 

Initial Regression Window:

Last Working Environmental Variables:
Device: Flame 3.0
BuildID: 20150211221340
Gaia: d5a71cedb37dd45f439f672489db3994b349ac43
Gecko: 3094601af679
Version: 38.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0

First Broken Environmental Variables:
Device: Flame 3.0
BuildID: 20150212064620
Gaia: 2a2b008f9ae957fe19ad540d233d86b5c0b6829e
Gecko: 81f979b17fbd
Version: 38.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0

Last Working Gaia First Broken Gecko: Issue DOES reproduce 
Gaia: d5a71cedb37dd45f439f672489db3994b349ac43
Gecko: 81f979b17fbd

First Broken Gaia Last Working Gecko: Issue does NOT reproduce
Gaia: 2a2b008f9ae957fe19ad540d233d86b5c0b6829e
Gecko: 3094601af679

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3094601af679&tochange=81f979b17fbd

Comment 4

[Gregor Wagner [:gwagner]]

Botond, might this be coming from 1127066?

Comment 5

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

Sounds like a dupe of bug 1155785 to me.

Comment 6

[Gregor Wagner [:gwagner]]

Lets wait fore bug 1155785. Adding naoki to see how bad it is.

Comment 7

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

It is kinda bad visually, and I've had the browser window close on me a few times.  ( I think due to LMK )

I updated my gaia to the most recent and ran into Bug 1159539; I'm not 100 % sure if it's valid.  Will need to check on it again tomorrow.

Comment 8

[Pi Wei Cheng [:piwei] (inactive)]

All the testers that have worked on this bug have a hard time deciding whether a build is reproducing the bug or not. We also suffered with dizziness from staring at the screen with cards moving rapidly on it for long periods of time. I think it's time we give up on working on this window.

Comment 9

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

I figured out the LMK issue with the app is bug 1155854.

The shake happens when you initially go into card view and swipe.  it happens more so with 512 mb flame and you can see content on browser starts lagging ( from the video ) : https://www.youtube.com/watch?v=_5sKSS0Ajc0


Gaia-Rev        6e35b0948c42a4398b8a5916015de167121683a1
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/1ad65cbeb2f4
Build-ID        20150429010205
Version         40.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150429.044126
FW-Date         Wed Apr 29 04:41:37 EDT 2015
Bootloader      L1TC000118D0

Comment 10

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

needinfo on myself to check 2.2.

Comment 11

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

I can still reproduce in 2.2; it occurs more when you first launch task manager.

Gaia-Rev        aa1da5036f9425c25d515d14243d3473bfefb4fd
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/38b2838d43e1
Build-ID        20150430002504
Version         37.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150430.042218
FW-Date         Thu Apr 30 04:22:29 EDT 2015
Bootloader      L1TC000118D0

Comment 12

[Botond Ballo [:botond]]

Given the difficulties described in comment 3 and comment 8, the regression window in comment 3 may not be accurate. It's also not straightforward for me to test whether this has something to do with bug 1127066 by backing that bug out locally, because many things that depend on it have landed since it landed.

That said, I can do some investigation on this bug.

Comment 13

[Botond Ballo [:botond]]

My first thought was to get a profile with '-layersdump' to capture layer trees for each frame of the stutter (and be able to associate the trees with the frames visually), but I can't reproduce the problem with the profile running in '-layersdump' mode (while I *can* repro the problem, intermittently, while running normally).

Since capturing layer textures slows the phone down considerably, this might indicate that the problem is caused by some sort of race which doesn't get a chance to occur at the slower composition rate that we get when capturing textures.

Comment 14

[Botond Ballo [:botond]]

The following is a trace of how the transform and shadow-transform of a single card change over a sequence of composites in response to a swipe that stutters:

transform=[ 1 0; 0 1; -139 222; ]]       shadow-transform=[ 1 0; 0 1; -139 222; ]]     
transform=[ 1 0; 0 1; -139 222; ]]       shadow-transform=[ 1 0; 0 1; -139 222; ]]     
transform=[ 1 0; 0 1; -49 222; ]]        shadow-transform=[ 1 0; 0 1; -46.9033 222; ]] 
transform=[ 1 0; 0 1; -49 222; ]]        shadow-transform=[ 1 0; 0 1; -37.2688 222; ]] 
transform=[ 1 0; 0 1; -49 222; ]]        shadow-transform=[ 1 0; 0 1; -27.6344 222; ]] 
transform=[ 1 0; 0 1; -49 222; ]]        shadow-transform=[ 1 0; 0 1; -18.0074 222; ]] 
transform=[ 1 0; 0 1; -49 222; ]]        shadow-transform=[ 1 0; 0 1; -8.36946 222; ]] 
transform=[ 1 0; 0 1; -49 222; ]]        shadow-transform=[ 1 0; 0 1; 1.25783 222; ]]  
transform=[ 1 0; 0 1; -49 222; ]]        shadow-transform=[ 1 0; 0 1; 10.8921 222; ]]  
transform=[ 1 0; 0 1; -49 222; ]]        shadow-transform=[ 1 0; 0 1; 20.5264 222; ]]  
transform=[ 1 0; 0 1; -49 222; ]]        shadow-transform=[ 1 0; 0 1; 27.5 222; ]]     
transform=[ 1 0; 0 1; -49 222; ]]        shadow-transform=[ 1 0; 0 1; 27.5 222; ]]     
transform=[ 1 0; 0 1; -49 222; ]]        shadow-transform=[ 1 0; 0 1; 27.5 222; ]]     
transform=[ 1 0; 0 1; -49 222; ]]        shadow-transform=[ 1 0; 0 1; 27.5 222; ]]     
transform=[ 1 0; 0 1; -37.2688 222; ]]   shadow-transform=[ 1 0; 0 1; -32.9927 222; ]] 
transform=[ 1 0; 0 1; -37.2688 222; ]]   shadow-transform=[ 1 0; 0 1; -12.5709 222; ]] 
transform=[ 1 0; 0 1; -37.2688 222; ]]   shadow-transform=[ 1 0; 0 1; 7.86378 222; ]]  
transform=[ 1 0; 0 1; -37.2688 222; ]]   shadow-transform=[ 1 0; 0 1; 28.2921 222; ]]  
transform=[ 1 0; 0 1; -37.2688 222; ]]   shadow-transform=[ 1 0; 0 1; 48.73 222; ]]    
transform=[ 1 0; 0 1; -37.2688 222; ]]   shadow-transform=[ 1 0; 0 1; 69.1755 222; ]]  
transform=[ 1 0; 0 1; -37.2688 222; ]]   shadow-transform=[ 1 0; 0 1; 89.5945 222; ]]  
transform=[ 1 0; 0 1; -37.2688 222; ]]   shadow-transform=[ 1 0; 0 1; 110.024 222; ]]  
transform=[ 1 0; 0 1; -37.2688 222; ]]   shadow-transform=[ 1 0; 0 1; 125 222; ]]      
transform=[ 1 0; 0 1; -37.2688 222; ]]   shadow-transform=[ 1 0; 0 1; 125 222; ]]      
transform=[ 1 0; 0 1; -37.2688 222; ]]   shadow-transform=[ 1 0; 0 1; 125 222; ]]      
transform=[ 1 0; 0 1; -37.2688 222; ]]   shadow-transform=[ 1 0; 0 1; 125 222; ]]      
transform=[ 1 0; 0 1; -37.2688 222; ]]   shadow-transform=[ 1 0; 0 1; 125 222; ]]      
transform=[ 1 0; 0 1; -37.2688 222; ]]   shadow-transform=[ 1 0; 0 1; 125 222; ]]      
transform=[ 1 0; 0 1; -37.2688 222; ]]   shadow-transform=[ 1 0; 0 1; 125 222; ]]      
transform=[ 1 0; 0 1; -37.2688 222; ]]   shadow-transform=[ 1 0; 0 1; 125 222; ]]      
transform=[ 1 0; 0 1; -37.2688 222; ]]   shadow-transform=[ 1 0; 0 1; 125 222; ]]      
transform=[ 1 0; 0 1; -37.2688 222; ]]   shadow-transform=[ 1 0; 0 1; 125 222; ]]      
transform=[ 1 0; 0 1; -37.2688 222; ]]   shadow-transform=[ 1 0; 0 1; 125 222; ]]      
transform=[ 1 0; 0 1; 125 222; ]]        shadow-transform=[ 1 0; 0 1; 125 222; ]]      
transform=[ 1 0; 0 1; 125 222; ]]        shadow-transform=[ 1 0; 0 1; 125 222; ]]      

The transform reflects what Layout is doing, and the shadow-transform reflects what the compositor is doing.

The interesting bit is the x-coordinate of the translation, which starts at -139 before the swipe and ends up at 125 when the swipe is complete. Both the transform and the shadow-transform start and end there.

The transform goes through the intermediate values of -49 and -37, indicating that Gecko got a chance to repaint twice during the swipe. These values form an increasing sequence, as they should.

The shadow-transform undergoes additional intermediate values, indicating that the swipe is being animated in the compositor. However, unlike the values on the layout side, the compositor values do not form an increasing sequence - they increase from -139 to 27.5, then jump back down to -32.9 and continue increasing from there to the final 125. This jump from 27.5 to -32.9 is the stutter.

The stutter occurs on the first composite that happens after the layer-transaction with the -37 value from Layout comes in.

This suggests that the problem has to do with how Layout and the compositor coordinate the async animation.

Comment 15

[Botond Ballo [:botond]]

I also verified that there is no APZ scrolling going on, so the only contributor to the shadow-transform should be OMTA, suggesting that this is an OMTA issue.

I'm going to be away next week; needinfoing Brian and Matt, in case one of them is able to help with this. If not, I will continue investigating when I come back.

Comment 16

[Matt Woodrow (:mattwoodrow)]

We don't actually take the transform into account when computing OMTA shadow-transform values, we just use the startTime of the animation and the current compositor sample time.

As far as I can tell, the compositor sample time should be monotonically increasing (it's using TimeStamp::Now()), so this should only happen if the start time for the animation changes.

It's not obvious how that would happen, but I don't know much about the animation code.

Comment 17

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

Let's see what Brian thinks when he comes back.

Comment 18

[Brian Birtles (:birtles, Feb 26~ parental leave)]

Comment 14 is very helpful. It seems likely that we're re-sending a different animation start time in the second layer transaction. This would only happen after bug 927349. Bug 1123196 should have fixed it so that we always send the same start time but I guess that's not happening in this case.

Looking at bug 1123196 comment 16, there may be some other combination of nested iframes/-moz-element/layer managers that causes us to resolve this start time twice.

Comment 19

[Brian Birtles (:birtles, Feb 26~ parental leave)]

It turns out what's happenning is that while the transition is still running (at least as far as the content process is concerned) new transitions are being created. However, those new transitions are being created with their start point as the value of transform as seen by the content process. When the compositor process gets ahead of the content process you'll see stutter.

Taking the example from comment 14 the process is something like this:

Content frame t=0ms:
* Process touch event
* Script updates the transform property to 'translateX(27.5px)'
  (Or something similar depending on what the units being reported in
   comment 14 are.)
* Create new CSS transition of dur 200ms with, as yet, unresolved start time
  (For my reference, typical transition durations are 27ms, 38ms, 50ms, 72ms,
   100ms, 200ms, 500ms. Sometimes there is a positive delay too.)
  Animation keyframes: { transform: translateX(-139px) }
                       { transform: translateX(27.5px) }
* Do painting
* End layer transaction
  * Resolve start time of animations on layers at 20ms
    (This is just for argument, it doesn't really matter how long this takes
     since we don't time animations until painting has finished.)
  [ Upload animations etc. to compositor ]
* Mark animations with a pending start time ("ready time") of 20ms

  Compositor:
  * Receive layer update
  * Add new animations with start time t=40ms

  Compositor frame t=158ms:
  (I'm basing this on the values in comment 14. I'm not sure why we're taking
   so long to composite the first frame in this case but I wonder if we're
   doing some expensive upload since the content process and compositor process
   are equally lagged here. Alternatively, and probably more likely, we might be
   updating the specified transform style and triggering a style flush without
   painting such that the keyframes for the animation are actually between say,
   -60px and 27.5px.)
  * Composite frame at 138ms progress, transform: translateX(-47px)

  Compositor frame t=174ms:
  * Composite frame at 154ms progress, transform: translateX(-37px)

  ...

  Compositor t=270ms:
  * Composite frame at 250ms progress, transform: translateX(27.5px)

  (From this point on the compositor will keep applying the same value since
  compositor animations fill forwards until they are taken off the layer by the
  content process.)

(During this time the content process seems to be quite busy. It's true that we suppress style updates on the main thread when they're running on the compositor but we *don't* do that when the animation reaches the end. As a result, we *can't* have composited a frame at t>270ms or else we would triggered a layer transaction that pulled the animation off the compositor.)

Content frame t=178ms:
* Process next touch event
* Script updates the 'transform' property to 'translateX(125px)'
* Process style updates which causes the content process to calculate the
  current animated transform value of 'translateX(-37px)'
* Create new CSS transition of dur 80ms with, as yet, unresolved start time
  Animation keyframes: { transform: translateX(-37px) }
                       { transform: translateX(125px) }
  (In nsTransitionManager.cpp we detect we have an existing transition on
   the transform property but we only do special handling when the new
   transition ends at the start point of the previous animation.)
* Do painting
* End layer transaction
  * Resolve start time of animations on layers at sometime after 178ms
  [ Upload animations etc. to compositor ]
* Mark animations with a pending start time ("ready time") of sometime after
  178ms

  Compositor:
  * Receive layer update
  * Here we clobber the existing (finished) animations with the new ones
    (In my observations the difference in start time between the old and new
     animations is about 50ms so either the data in comment 14 is a particularly
     lagged case or the initial transition is, indeed, not starting from -139px
     as I suspect.)

  Compositor frame t=~180ms
  * Composite frame at 5ms progress, transform: translateX(-33px) !!

Hence, the stutter.

Comment 20

[Brian Birtles (:birtles, Feb 26~ parental leave)]

Long-term there are a few things we plan to do about this:

* Implement scroll and touch driven animations.
* Implement additive animations (some people have been experimenting with the Web Animations implementation of additive animations and using them to creating animations that automatically adapt to changes and are calling this pattern "relative animations" or "negative delta animations").

Short-term things we could do:

* Gecko-side: If we detect that we're replacing a transition that is running on the compositor, re-evaluate the "from" value using the current timestamp. I don't like adding these special cases but we already do this for pausing in some circumstances (e.g. see the big comment in the middle of Animation::ComposeStyle where we use the current timestamp while pausing to prevent flicker). This one could get pretty tricky though since we'd probably have to handle the case when, according to the current timestamp, the animation has finished.
* Gaia-side: Can we rework this interaction somehow to only trigger one transition at a time? Alternatively, if we can work out what is keeping the content process so busy and reduce that we'd minimise the chance of stutter.

I suspect this isn't strictly a regression but that prior to bug 927349 we didn't get enough frames to notice this.

Adding dbaron in case he has any suggestions, particularly regarding the possibility of adding special handling to Gecko for this.

Comment 21

[Brian Birtles (:birtles, Feb 26~ parental leave)]

One further thought, we could just pass an empty "from" value to the compositor in this case and let the compositor fill it in with whatever it believes to the current value at the time it receives it.

Comment 22

[Brian Birtles (:birtles, Feb 26~ parental leave)]

(In reply to Brian Birtles (:birtles) from comment #21)
> One further thought, we could just pass an empty "from" value to the
> compositor in this case and let the compositor fill it in with whatever it
> believes to the current value at the time it receives it.

I think this is probably the right approach although we might not always have all the information needed to reconstruct the keyframe on the compositor. It might be better to simply annotate keyframes that were constructed from the underlying/current value as such and pass that flag onto the compositor. If the compositor has a running animation it can use that to replace the keyframe in question.

That said, this is not a small change and might not be suitable for 2.2. For that a Gaia fix would probably be better. Can we just rework this interaction so it doesn't produce any overshoot animation (i.e. no flinging, just tracking the finger) until we get a touchend event?

Comment 23

[Botond Ballo [:botond]]

(In reply to Brian Birtles (:birtles) from comment #22)
> That said, this is not a small change and might not be suitable for 2.2. For
> that a Gaia fix would probably be better. Can we just rework this
> interaction so it doesn't produce any overshoot animation (i.e. no flinging,
> just tracking the finger) until we get a touchend event?

ni?sfoster

Comment 24

[Sam Foster [:sfoster] (he/him)]

Forwarding ni? to Etienne

Comment 25

[Etienne Segonzac (:etienne)]

(In reply to Botond Ballo [:botond] from comment #23)
> (In reply to Brian Birtles (:birtles) from comment #22)
> > That said, this is not a small change and might not be suitable for 2.2. For
> > that a Gaia fix would probably be better. Can we just rework this
> > interaction so it doesn't produce any overshoot animation (i.e. no flinging,
> > just tracking the finger) until we get a touchend event?
> 
> ni?sfoster

We don't really have flinging (ie. you can't move more than one step with one gesture), but we center cards on touchend.

That said, just made a patch removing a bunch of old tricks and making sure we always have a `transition: transform` set on the cards and looks like it's helping a lot.

Coming soon :)

Comment 26

[GitHub Autolander Bot]

Attachment: [gaia] etiennesegonzac:bug-1158928 > mozilla-b2g:master

Comment 27

[Etienne Segonzac (:etienne)]

Comment on attachment 8605253 [details] [review]
[gaia] etiennesegonzac:bug-1158928 > mozilla-b2g:master

What do you think?
It's a pretty safe patch and it might make things bearable until Jet finishes [1] ;)

[1] https://github.com/jetvillegas/gaia/tree/APZC-card-view

Comment 28

[Sam Foster [:sfoster] (he/him)]

(In reply to Etienne Segonzac (:etienne) from comment #27)

> It's a pretty safe patch and it might make things bearable until Jet
> finishes [1] ;)
> 
> [1] https://github.com/jetvillegas/gaia/tree/APZC-card-view

Cool, I was going to start work on that next week (bug 1161229)

Comment 29

[Sam Foster [:sfoster] (he/him)]

Comment on attachment 8605253 [details] [review]
[gaia] etiennesegonzac:bug-1158928 > mozilla-b2g:master

Works for me, certainly its an improvement and fixes the reported problem. Now that the panning is fixed, I'm noticing the "overscroll" at the edges seems to lack a little friction. But I think these are nits we can work out on master. Thanks!

Comment 30

[GitHub Autolander Bot]

Autolander could not locate a review from a user within the suggested reviewer list. Either the patch author or the reviewer should be in the suggested reviewer list.

Comment 31

[GitHub Autolander Bot]

Pull request has landed in master: https://github.com/mozilla-b2g/gaia/commit/52edb910451301d2e7ac29a28c486c888e65eb3a

Comment 32

[Etienne Segonzac (:etienne)]

Comment on attachment 8605253 [details] [review]
[gaia] etiennesegonzac:bug-1158928 > mozilla-b2g:master

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): unsure but probably revealed by platform changes
[User impact] if declined: worse than usual card view experience
[Testing completed]: manual tests of cards view scenarios, we don't have the tools to to automated transition performance testing.
[Risk to taking this patch] (and alternatives if risky): low, removing hacks :)
[String changes made]: none

Comment 33

[Josh Cheng [:josh]]

Hi Norry,
Please verify on master. Thanks

Comment 34

[zouyi(Leave from Mozilla)]

This bug has been verified as pass on latest build of Flame v3.0.
See attachments: verify_v3.0.mp4
Reproduce rate: 5/5
Device: Flame 3.0 (Pass)
Build ID               20150517010201
Gaia Revision          4c0f36e9dfe017bf2a698d416a57c8156b43383d
Gaia Date              2015-05-15 22:18:51
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/2f6ea66057fe
Gecko Version          41.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150517.044012
Firmware Date          Sun May 17 04:40:23 EDT 2015
Bootloader             L1TC000118D0

Comment 35

[zouyi(Leave from Mozilla)]

Attachment: verify_v3.0.mp4

Comment 36

[Josh Cheng [:josh]]

Comment on attachment 8605253 [details] [review]
[gaia] etiennesegonzac:bug-1158928 > mozilla-b2g:master

Approving and QA please verify after patch land on 2.2.

Comment 37

[Ryan VanderMeulen [:RyanVM]]

v2.2: https://github.com/mozilla-b2g/gaia/commit/21625a3cd40bdfaf724ff0c38fe5fae54882b516

Comment 38

[zouyi(Leave from Mozilla)]

This bug has been verified as pass on latest build of Flame v2.2 & Nexus5 v2.2.
See attachments: verify_v2.2.mp4

Device: Flame v2.2 (Pass)
Build ID               20150519162501
Gaia Revision          63e9eeec3032318f8a240f80b6a184fa4b50b6e1
Gaia Date              2015-05-19 17:52:15
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/4e078e1364d3
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150519.200807
Firmware Date          Tue May 19 20:08:18 EDT 2015
Bootloader             L1TC000118D0

Device: NEXUS5 v2.2 (Pass)
Build ID               20150519162501
Gaia Revision          63e9eeec3032318f8a240f80b6a184fa4b50b6e1
Gaia Date              2015-05-19 17:52:15
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/4e078e1364d3
Gecko Version          37.0
Device Name            hammerhead
Firmware(Release)      5.1
Firmware(Incremental)  eng.cltbld.20150519.195445
Firmware Date          Tue May 19 19:55:01 EDT 2015
Bootloader             HHZ12f

Comment 39

[zouyi(Leave from Mozilla)]

Attachment: verify_v2.2.mp4

Comment 40

[Brian Birtles (:birtles, Feb 26~ parental leave)]

Regarding the Gecko fix suggested in comment 21 and comment 22, I filed bug 1167519 for this.