Edge-swipe gestures are very janky while dragging (are smooth once drag is released)

VERIFIED FIXED in Firefox OS v2.1

Status

Firefox OS
Gaia::System::Window Mgmt
VERIFIED FIXED
3 years ago
3 years ago

People

(Reporter: cwiiis, Assigned: cwiiis)

Tracking

({regression})

unspecified
2.1 S8 (7Nov)
All
Gonk (Firefox OS)
regression

Firefox Tracking Flags

(blocking-b2g:2.1+, b2g-v2.0 unaffected, b2g-v2.1 verified, b2g-v2.2 verified)

Details

(Whiteboard: [systemsfe])

Attachments

(3 attachments, 1 obsolete attachment)

(Assignee)

Description

3 years ago
[Blocking Requested - why for this release]: Core functionality with terrible performance that causes a poor UX.

Edge-swipe gestures are usually *very* janky while being performed, but the transition after letting go is smooth. They're janky to the point that I avoid them because they look and feel so bad. It seems to rely somewhat on the complexity of what's being rendered inside the current app (so it's less janky swiping from Gaia apps, but very janky swiping from random web-pages, Facebook, Twitter, etc.)

Core functionality shouldn't look/feel so bad.

Tested on a Flame running 2.1 and on a ZTE Open C running master.
Can we get a branch check?
Keywords: qawanted
Tested with Shallow Flash on 319mb using Engineering builds

This bug repro's on Flame KK builds: Flame 2.2 KK, Flame 2.1 KK

Actual Results: Edge Swiping can be slow and sluggish when activly swiping between apps. Once the finger is lifted, the animation is smooth.

Repro Rate: 4/4

Environmental Variables:
Device: Flame 2.2 KK
BuildID: 20141026103710
Gaia: e91d99e4d96954f06383c00bb9d79598a697e310
Gecko: 8230834302c9
Version: 36.0a1 (2.2)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
-----------------------------------------------------------------
Environmental Variables:
Device: Flame 2.1 KK
BuildID: 20141027032141
Gaia: f8378fe1c7f128a3b679201b469a82fca2371828
Gecko: 32a102b8e807
Version: 34.0 (2.1)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

-----------------------------------------------------------------
-----------------------------------------------------------------

This bug does NOT repro on Flame kk build: Flame 2.0 KK

Actual Result: No issue seen when edge gesturing between apps.

Repro Rate: 0/2

Environmental Variables:
Device: Flame 2.0 KK
BuildID: 20141026145711
Gaia: 2183b4f3ec0eb47ab1f133c31732ec53b08ad253
Gecko: 43bee45176c4
Version: 32.0 (2.0)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-v2.0: --- → unaffected
Flags: needinfo?(jmitchell)
Keywords: qawanted → regression
QA Contact: croesch
Thanks for the quick branch check!
Can we get a regression window?
Keywords: regressionwindow-wanted
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
QA Contact: croesch

Updated

3 years ago
QA Contact: ddixon
Issue DOES occur in earliest Flame KK build we have (v188 base image, Shallow Flash, 319 MB memory). 

Actual Results: Swiping between multiple apps using edge gestures is choppy and shows low performance. 

Device: Flame Master
Build ID: 20140904171737
Gaia: de59e0c3614dd0061881fe284e9f2d74fa0d1d5d
Gecko: 8703c1895505
Version: 35.0a1 (Master)
Firmware Version: v188
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Requesting to remove "regressionwindow-wanted" tag.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
This is always one of the pit-falls of attempting a window on something that is a perf issue or "janky" - which devolves to an interpretation and many shades of grey. For a solid regression window there needs to be a definitive broken state and working state. I looked at the reported build above and while it did not seem as bad as more recent builds I would consider it a repro.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Keywords: regressionwindow-wanted
QA Contact: ddixon
poor user experience that requires further investigation and implementation
blocking-b2g: 2.1? → 2.1+
Target Milestone: --- → 2.1 S8 (7Nov)
(Assignee)

Comment 7

3 years ago
I'm going to take a look at this as I'm blocked on a few other things and my other tasks aren't as important.

By 'take a look', I mean I'm going to try to figure out why this is slow (taking our utility tray as a yard-stick for performance).
Assignee: nobody → chrislord.net
(Assignee)

Comment 8

3 years ago
Ok, so looking at the code, the implementation doesn't have any obvious defects (but I've not drilled deep yet), but there are two obvious performance woes that are happening (which may be fixable);

1- The entire page of the current app ends up redrawn a couple of times at the start of the gesture. This could contribute to jank at the start of the gesture and it may be possible to avoid it...

2- The dragged-to screenshot is painted in vertical strip by vertical strip, rather than just once and having the layer moved around. This will likely significantly contribute to jank, especially if the phone is doing absolutely anything else at the same time (this is the same reason the utility tray was janky before vingtetun's patches)

I also notice that if you swipe to an edge, but don't actually switch app, as well as the whole current app being redrawn, any images on the page disappear and reappear. There's likely something expensive happening related to this (images being flushed from memory and decoded again?), and that's also something we should try to stop.

I'm going to start poking and see how much of this we can fix at the Gaia level.

It's getting near to the end of my work day, so if anyone else wants to look at this, do go ahead - hopefully the above is a reasonable jumping off point for further investigation.
(Assignee)

Comment 9

3 years ago
(In reply to Chris Lord [:cwiiis] from comment #8)
> 2- The dragged-to screenshot is painted in vertical strip by vertical strip,
> rather than just once and having the layer moved around. This will likely
> significantly contribute to jank, especially if the phone is doing
> absolutely anything else at the same time (this is the same reason the
> utility tray was janky before vingtetun's patches)

Actually, this happens both to the screenshot and the dragged page, but oddly, isn't 100% consistent. Sometimes it happens, sometimes it doesn't...
(Assignee)

Comment 10

3 years ago
Created attachment 8512898 [details]
Add will-change: transform during edge swiping

So this seems to alleviate a lot of the jank for me, but given that the situation isn't always reliably reproduceable and it's the end of the day so I'm tired, it'd be good to get a second set of eyes on it to see if it makes a difference or if I'm imagining it.

Note; there's still an amount of jank at the very start of the swipe. And I still think we can make that significantly better.
Attachment #8512898 - Flags: feedback?(mhenretty)
Comment on attachment 8512898 [details]
Add will-change: transform during edge swiping

I found that if I initiate an edge gesture on the marketplace application while it was loading (ie. force killing it, then re-launching), I could reliably reproduce the jank. Looking at this side by side with and without your patch, I do think it improves the situation. I also asked :kgrandon and :gwagner's opinion, and they thought so too. But it is hard to tell for sure. I can probably run a profile tomorrow to verify, but for now fb+.
Attachment #8512898 - Flags: feedback?(mhenretty) → feedback+
(Assignee)

Comment 12

3 years ago
So, I think we want the will-change bit, but there's a couple of other things that we need to stop/do to get this to be at least as smooth as the utility tray

1- The utility tray draws constantly if there's anything going on during edge-swiping... I don't know how useful it is that it updates live while swiping, I wonder if we could either freeze it or fade it out? (or both)

2- If you've scrolled at all, the active app will repaint entirely when you start swiping, and will repaint again entirely when you start scrolling it again if you go back to it. I have a hunch that the app_transition_controller is doing work it doesn't need to do/doing it at inefficient times here.

3- I think, like what Vivien has done with the utility tray, we'll want to lower the priority of the active app during swiping (see bug 1061969).

I'm still investigating 2, I think 3 will be fairly straightforward once bug 1061969 is resolved.
Depends on: 1061969
(Assignee)

Comment 13

3 years ago
I've tracked it down and it's the setVisibleForScreenReader calls that are causing the page to re-render on initiating and ending a swipe gesture.

I'll play around, but I don't know enough about what this does or how it works to know exactly what needs to happen in this case (like can it be delayed until after the swipe, for example? And why does it cause everything to redraw?)

Not even sure who to needinfo wrt that, so n?mhenretty in the hope that he knows :)
Flags: needinfo?(mhenretty)
Nice investigation. If these are causing some jank in the feature I think we should consider removing them for now. I think we definitely want an accessible implementation, but we shouldn't do so at the cost of UX.

Looping in Eitan/Yura.
Flags: needinfo?(yzenevich)
Flags: needinfo?(eitan)
All setVisibleForScreenReader does is sets 'aria-hidden' attribute on an app_window element and calls setActive on its iframe. I would think neither of these should trigger a redraw. Perhaps Eitan would know something else..
Flags: needinfo?(yzenevich)
(Assignee)

Comment 16

3 years ago
I'd consider accessibility to be part of the UX, but I'm sure we can work out a fix/work-around here.

Note, it's the calls to browser.element.setActive that cause the redrawing. I wonder if setVisibleForScreenReader needs to touch setActive at all?
(In reply to Chris Lord [:cwiiis] from comment #16)
> I'd consider accessibility to be part of the UX, but I'm sure we can work
> out a fix/work-around here.
> 
> Note, it's the calls to browser.element.setActive that cause the redrawing.
> I wonder if setVisibleForScreenReader needs to touch setActive at all?

Hah, interesting, I believe we are only interested in the aria-hidden attribute, but the I was asked to add it when working on it, perhaps it is redundant.
An important note here is that bug 1061969 was deemed too risky for 2.1, and will not be uplifted. If the fix here requires bug 1061969, we probably won't uplift it as well. However, points 1 and 2 from comment 12 seem addressable for 2.1, and so we should consider fixing those in this bugs, and perhaps opening a new bug for lowering the priority of the active app during edge gestures.
Flags: needinfo?(mhenretty)
(Assignee)

Comment 19

3 years ago
Created attachment 8513615 [details] [review]
Improve janky edge gestures

This incorporates the two changes we've discussed above - adding will-change: transform during swiping (which helps with jank during the drag, after initiating it) and not calling setActive in setVisibleForScreenReader, which helps with jank at the start of the swipe (by eliminating repainting of the currently active page).

There is still more we can do, but it's worth getting these in first, as other changes are likely to be more comprehensive and yield less benefit.
Attachment #8512898 - Attachment is obsolete: true
Attachment #8513615 - Flags: review?(yzenevich)
Attachment #8513615 - Flags: review?(alive)
(Assignee)

Comment 20

3 years ago
Yura, I flagged you as reviewer for the accessibility change, but if you're uncertain as to why setActive was called in the first place, please forward it on to whoever it was that made you add it :)
(Assignee)

Comment 21

3 years ago
Removing blocking on bug 1061969, we can still make this a lot better without that.
No longer depends on: 1061969
(Assignee)

Comment 22

3 years ago
After the attached patch, I think the next things that would be worth looking at would be:

1- Reduce the amount of drawing the utility tray is doing during network activity. Seems way more than is necessary (I commented on this in bug 1054220 comment #3)... Maybe even consider hiding/freezing the utility tray during edge swiping to eliminate all redrawing whatsoever

2- Investigate that the dragged-to sheet that gets created at the start of the edge gesture is 1- only causing one redraw, and 2- created as efficiently as possible. I expect it already is, but it doesn't hurt to check.

After these, lowering the priority during edge swiping, like I suppose we intend to for the utility tray, would be the next obvious thing. I think if we don't do this, we can't really make any guarantees on interactive performance.
(Assignee)

Comment 23

3 years ago
The performance after these two patches feels acceptable to me. Not buttery smooth, but good enough not to block (and certainly consistent with similar features elsewhere in the system).
Comment on attachment 8513615 [details] [review]
Improve janky edge gestures

f+ for app window change (need an unit test).
Yes, I think grouping browser visibility and element accessibility is somewhat strange. Not sure if it's me failed to catch that in review...

I need etienne's feedback on the CSS change.
Attachment #8513615 - Flags: review?(etienne)
Attachment #8513615 - Flags: review?(alive)
Attachment #8513615 - Flags: feedback+
Comment on attachment 8513615 [details] [review]
Improve janky edge gestures

It's hard to find the right compromise since touching the will-change property will cause a reflow (bug 974125). And having will-change on all sheets all the time is not an option (it was a nice UX though ;)).

The issue with the inside/outside-edges classes is that they're really short lived. So if you swipe between multiple apps we end up causing a lot of extra reflows. Since the inside/outside classes get cleaned up on every touchend.

I think it's worth trying to do something similar to what we do with screenshots: we display them as-needed in _handle__sheetdisplayed but we only hide them in _handle__sheetsgestureend. So if you swipe over 5 apps, we will display the screenshots one-by-one but hide all 5 at once when you stop on an app.

We could set will-change only on apps entering the view port during a gesture sequence, then remove them once the user stops on an app. Cutting the number of reflows in half. (BTW we'll need to update the edge_gestures_test.js and point to bug 974125).
Attachment #8513615 - Flags: review?(etienne)
(Assignee)

Comment 26

3 years ago
(In reply to Etienne Segonzac (:etienne) from comment #25)
> Comment on attachment 8513615 [details] [review]
> Improve janky edge gestures
> 
> It's hard to find the right compromise since touching the will-change
> property will cause a reflow (bug 974125). And having will-change on all
> sheets all the time is not an option (it was a nice UX though ;)).

I'm not sure what the difference is here - creating the sheets causes a reflow, whether they have will-change on or not doesn't make a difference at that point. For the active sheet, I find it hard to believe that the number of style classes changing doesn't already cause a reflow, and even if it didn't, it's a very shallow DOM (the active sheet appears to already be layerised, so we may even be able to get rid of that rule, but I'd rather it was explicit). What does make a difference though is that if they don't, they may get flattened and cause repainting (which is happening).

> The issue with the inside/outside-edges classes is that they're really short
> lived. So if you swipe between multiple apps we end up causing a lot of
> extra reflows. Since the inside/outside classes get cleaned up on every
> touchend.

This is fine - on the touchend, the animation is set, and so the will-change becomes superfluous - the style class changes anyway, so the amount of reflows may well already be the same, but there's less painting. Again, the DOM is shallow and a reflow is much cheaper than repainting the entire screen, though I'm not convinced that this actually affects the number of reflows happening.

> I think it's worth trying to do something similar to what we do with
> screenshots: we display them as-needed in _handle__sheetdisplayed but we
> only hide them in _handle__sheetsgestureend. So if you swipe over 5 apps, we
> will display the screenshots one-by-one but hide all 5 at once when you stop
> on an app.
> 
> We could set will-change only on apps entering the view port during a
> gesture sequence, then remove them once the user stops on an app. Cutting
> the number of reflows in half. (BTW we'll need to update the
> edge_gestures_test.js and point to bug 974125).

Only apps that may enter the viewport get the *-edges classes, so this already happens.

Have I missed something here?
Flags: needinfo?(etienne)
(Assignee)

Comment 27

3 years ago
Ok, I have missed something - there are more reflows... But I'm really not sure it matters vs. the amount of painting that's happening (reflows are comparatively cheap). We could probably keep will-change on active sheets and that may eliminate the reflows during one gesture, I'll experiment.

If it came down to it, are we preferring fewer reflows over less drawing? If so, why?
(In reply to Chris Lord [:cwiiis] from comment #27)
> Ok, I have missed something - there are more reflows... But I'm really not
> sure it matters vs. the amount of painting that's happening (reflows are
> comparatively cheap). We could probably keep will-change on active sheets
> and that may eliminate the reflows during one gesture, I'll experiment.
> 
> If it came down to it, are we preferring fewer reflows over less drawing? If
> so, why?

Not sure I follow you, my suggestion brings us less reflows _and_ less repaints.
Just swipe back and forth between 2 apps, it's a Christmas tree :)
Flags: needinfo?(etienne)
Ha! Got it, I think some of the misunderstanding might come from this: the suggestion I'm making applies to sequence of multiple edge gestures (like you do when searching for an app), but it doesn't change a thing when you do just one swipe then wait for app to be woken up.
Comment on attachment 8513615 [details] [review]
Improve janky edge gestures

Going to grab this review from Yura since he is on PTO. This change looks fine in regards to accessibility. We override rendered visibility here in window management, so as long as aria-hidden reflects the visible state, we are good.
Flags: needinfo?(eitan)
Attachment #8513615 - Flags: review?(yzenevich) → review+
(Assignee)

Comment 31

3 years ago
Until we find out that actually there's still loads more work to do on it, let's block on bug 974125. I think working around that will over-complicate the code and we should really push back on obvious platform bugs (imho).

If it ends up it can't get fixed, maybe we can live with the reflows (because I don't think they're expensive in this case), but it'd be great if we could have our cake and eat it...
Depends on: 974125
Comment on attachment 8513615 [details] [review]
Improve janky edge gestures

Tested again with the patch from bug 974125: such a clear win and no need to update the reflow test now, so r+ (with a small comment on github)

Kudos on fixing this the right way!
Attachment #8513615 - Flags: review+
(Assignee)

Comment 33

3 years ago
(In reply to Etienne Segonzac (:etienne) from comment #32)
> Comment on attachment 8513615 [details] [review]
> Improve janky edge gestures
> 
> Tested again with the patch from bug 974125: such a clear win and no need to
> update the reflow test now, so r+ (with a small comment on github)
> 
> Kudos on fixing this the right way!

I was just about to test this myself and re-flag and you beat me to it :) Thanks for being so speedy!
(Assignee)

Comment 34

3 years ago
Rebased and made the suggested change, going to wait for green tests before merging.
Status: NEW → ASSIGNED
(Assignee)

Comment 35

3 years ago
Huh, doesn't look like this is ready just yet anyway, I'm seeing redrawing that the will-change should have gotten rid of :/ Will investigate further...
(Assignee)

Comment 36

3 years ago
Reverting bug 974125 fixes the cases I'm getting too much painting, so that change must not have been quite right... I'll see about follow-up on that bug.
(Assignee)

Comment 37

3 years ago
erm, ok, now I can't reproduce with that patch applied... I guess this is fine, but I'll continue trying to reproduce, and if I can, fixing.
(Assignee)

Comment 38

3 years ago
Still can't reproduce the bad redrawing... Maybe I didn't update Gaia correctly at some point.

Merged: https://github.com/mozilla-b2g/gaia/commit/319c575f0eecf80ada943cc2570d284672cac8e6
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
(Assignee)

Comment 39

3 years ago
This blocks 2.1, but if we want this to work with no reflows, we need bug 974125 uplifted, which in turn requires bug 931668. I'm not sure if the latter isn't too risky to uplift for 2.1.

Etienne, I didn't see any significant performance hit with the reflows associated with will-change on this, but I didn't test super-extensively. What's your opinion on uplifting this patch without bug 974125, if it came down to it?
Flags: needinfo?(etienne)
(In reply to Chris Lord [:cwiiis] from comment #39)
> This blocks 2.1, but if we want this to work with no reflows, we need bug
> 974125 uplifted, which in turn requires bug 931668. I'm not sure if the
> latter isn't too risky to uplift for 2.1.
> 
> Etienne, I didn't see any significant performance hit with the reflows
> associated with will-change on this, but I didn't test super-extensively.
> What's your opinion on uplifting this patch without bug 974125, if it came
> down to it?

Tested again, I agree we should uplift it anyway (the will-become-active change probably helps a little with gestures sequences too).
We'll need to update the edge_gestures_test.js' reflow count if we uplift it without the dependencies though.
Flags: needinfo?(etienne)
(Assignee)

Comment 41

3 years ago
Here's a branch for uplift to 2.1 if we can't uplift bug 974125: https://github.com/Cwiiis/gaia/tree/bug1089621-janky-edge-gestures-2.1

I'll request the right uplift after that becomes clear. n?me so I don't forget.
Flags: needinfo?(chrislord.net)
status-b2g-v2.2: affected → fixed

Comment 42

3 years ago
The issue still reproduces on 2.2 and 2.1 Flame
Performance of Edge-swipe gestures are slow and sluggish 

Device: Flame 2.2 Master
BuildID: 20141107073659
Gaia: 779f05fead3d009f6e7fe713ad0fea16b6f2fb31
Gecko: b62ccf3228ba
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 36.0a1 (2.2 Master)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Device: Flame 2.1
BuildID: 20141107001205
Gaia: 6295f6acfe91c6ae659712747dd2b9c8f51d0339
Gecko: 8c23b4f2ba29
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 34.0 (2.1)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?][failed-verification]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?][failed-verification] → [QAnalyst-Triage+][failed-verification]
Flags: needinfo?(ktucker)
(Assignee)

Comment 43

3 years ago
Created attachment 8519402 [details] [review]
Improve janky edge gestures (for 2.1 branch)

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): This bug
[User impact] if declined: Edge gestures are commonly pretty janky
[Testing completed]: Tested locally and on master for a few days
[Risk to taking this patch] (and alternatives if risky): Low risk.
[String changes made]: None
Flags: needinfo?(chrislord.net)
Attachment #8519402 - Flags: review+
Attachment #8519402 - Flags: approval-gaia-v2.1?

Updated

3 years ago
Attachment #8519402 - Flags: approval-gaia-v2.1? → approval-gaia-v2.1+
The Gaia Try run on the v2.1 uplift PR looks very broken. Are we sure it's OK for uplift?
Flags: needinfo?(chrislord.net)
(Assignee)

Comment 45

3 years ago
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #44)
> The Gaia Try run on the v2.1 uplift PR looks very broken. Are we sure it's
> OK for uplift?

It's not, one of the patches is unnecessary on 2.1... Fixed now - I've also requested bug 974125 be uplifted, so let's hold off on this until the answer on that is back.

Leaving the n?me so I don't lose track.
(Assignee)

Comment 46

3 years ago
Comment on attachment 8519402 [details] [review]
Improve janky edge gestures (for 2.1 branch)

Removing approval for now, waiting to see what happens on bug 974125.
Attachment #8519402 - Flags: approval-gaia-v2.1+
(Assignee)

Comment 47

3 years ago
Comment on attachment 8519402 [details] [review]
Improve janky edge gestures (for 2.1 branch)

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): This bug
User impact if declined: Janky(/jankier) edges gestures
Testing completed: Been on master for a while now, and locally on dog-food device
Risk to taking this patch (and alternatives if risky): Very low
String or UUID changes made by this patch: None

Re-requesting now the platform bug has landed - because the accessibility change hasn't been made in 2.1, this boils down to a small CSS change now.
Flags: needinfo?(chrislord.net)
Attachment #8519402 - Flags: approval-mozilla-b2g34?
Attachment #8519402 - Flags: approval-mozilla-b2g34? → approval-gaia-v2.1+
(Assignee)

Comment 48

3 years ago
So the PR test results still look quite broken, but I'm pretty certain that brokenness has nothing to do with the small CSS change that this introduces (if it does... I don't even)
Worth a shot.

v2.1: https://github.com/mozilla-b2g/gaia/commit/f84cacc42f8271ad171ea224a2504ef243478e1a
status-b2g-v2.1: affected → fixed
Hi Reporter,
    Could you provide the detailed reproduce steps or video for me to verify this bug?

Thank you!
Flags: needinfo?(chrislord.net)
(Assignee)

Comment 51

3 years ago
(In reply to Shally from comment #50)
> Hi Reporter,
>     Could you provide the detailed reproduce steps or video for me to verify
> this bug?
> 
> Thank you!

I'd actually say that this bug is still pretty bad - the patches improved the situation, but it's easy to observe a bad state too...

With the current code, this should at least be reasonably smooth:
- Launch Phone app
- Launch Settings app
- Wait a couple of seconds (for apps to load and settle)
- Initiate an edge swipe on the left side without lifting your finger
- Drag back and forth

The update on the screen should be around as smooth as dragging the utility tray from the top of the screen, with a small judder on initiation of the drag.
Flags: needinfo?(chrislord.net)
Hi Chris,

    Could you help to confirm whether the following steps are correct?

Thank you very much.


This bug has been successfully verified on Flame v2.1&2.2 by the following steps.
See attachment: verified_v2.1&2.2.mp4.
Reproduce rate: 0/5.

STR:
1.Launch Phone app.
2.Press Home button and launch Settings app.
3.Wait a couple of seconds (for apps to load and settle).
4.Initiate an edge swipe on the left side without lifting your finger.
5.Drag back and forth.
**Drag smoothly.

Flame 2.1 build:
Gaia-Rev        77c57eb8a985d5cbd34a597fb1b978ba6e205af6
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/4c28bb3be0c6
Build-ID        20150121001510
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150121.034530
FW-Date         Wed Jan 21 03:45:41 EST 2015
Bootloader      L1TC000118D0

Flame 2.2 build: 
Gaia-Rev        e4f9b5da3751798f9cc5d95f302c30722cc11fca
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/75a462a58d7a
Build-ID        20150121002607
Version         37.0a2
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150121.040751
FW-Date         Wed Jan 21 04:08:02 EST 2015
Bootloader      L1TC000118D0
Flags: needinfo?(chrislord.net)
Created attachment 8552869 [details]
verified_v2.1&2.2.MP4
Per Comment 52.
Status: RESOLVED → VERIFIED
status-b2g-v2.1: fixed → verified
status-b2g-v2.2: fixed → verified
(Assignee)

Updated

3 years ago
Flags: needinfo?(chrislord.net)
You need to log in before you can comment on or make changes to this bug.