Closed Bug 967420 Opened 6 years ago Closed 5 years ago

[User Story] Launching Task Manager

Categories

(Firefox OS Graveyard :: Gaia::System, defect, P3)

ARM
Gonk (Firefox OS)
defect

Tracking

(b2g-master verified)

VERIFIED FIXED
2.2 S5 (6feb)
Tracking Status
b2g-master --- verified

People

(Reporter: pdol, Assigned: sfoster)

References

Details

(Keywords: feature, perf, Whiteboard: systemsfe)

User Story

As a user I want to be able to launch task manager without having to long press on the home button so that it is much more discoverable.

Acceptance Criteria:
1. Launching task manager works as described by UX spec.


IxD specs: 
https://mozilla.box.com/s/lbw2wzw3p4jvxs24k4sg

VisD specs:
Portrait 
https://mozilla.box.com/s/m8lnw8mbx0dy3rawdhuo 
Landscape 
https://mozilla.box.com/s/3enhx3klfnhqt24ptyrm 
Add to Home screen
https://mozilla.box.com/s/1akg9h0xxjo14vi903r6

Flows 
Accessing Task Switcher from Homescreen 
https://mozilla.box.com/s/lwkls8iitpimt1az0w3q 
Accessing Task Switcher from App 
https://mozilla.box.com/s/rrmr7py2ntlcqms9v14l 
Closing a task: 
https://mozilla.box.com/s/3haiwly3ojwpdl186srz 
Add to Home screen
https://mozilla.box.com/s/1glupk1waxrjr0fg7sjh

Motion 
Accessing Task Switcher from home 
https://mozilla.box.com/s/w9ms7i1prbwbfwf80fcm 
Accessing Task Switcher from an app 
https://mozilla.box.com/s/c4k9n2c2zvvnvke4ke4a 
Closing  a Task (+app icon movement) - Use this video to reference icon movement  (other vids move to fast that there was no point to animate) 
https://mozilla.box.com/s/090aywxx7z9x0nkkh6sv
Returning to the last app in task switcher (tapping the home button) 
https://mozilla.box.com/s/uxs4c3cf504nt4v3cz7a 

Image Assets: 
https://mozilla.box.com/s/jyfz7pz86lmva32uoe5q

Attachments

(3 obsolete files)

No description provided.
User Story: (updated)
Flags: in-moztrap?(jsmith)
No longer blocks: 1.4-systems-fe
Flags: in-moztrap?(jsmith)
Assignee: nobody → aus
Blocks: 993122
Blocks: 992926
Target Milestone: --- → 1.4 S5 (11apr)
Whiteboard: [ucid:System159, 1.4:P2, ft:systems-fe] → [ucid:System159, 1.4:P2, ft:systems-fe][systemsfe][p=5]
Working on this starting today!
Status: NEW → ASSIGNED
Prioritized task list:

* Get rid of jank when task manager is shown while rocket bar is dragged down.
==> This is most likely tied to the fact that we sometimes have to take new screenshots

* Fling should make flung application active instead of killing it.

* Opening transition should match UX spec (requires visuals to be implemented via bug 967428)
Depends on: 967428
Disabling the forceful refresh of the screen shot for the current application fixes this issue. I actually believe we can remove that entire piece of code that takes new screenshots because the App Window Manager (and App Window) manages this process for us now. I need to confirm this with Alive.

In the meantime, I can change the checks present to only take a screenshot when there is absolutely no cached layer.

See WIP Pull Request: https://github.com/mozilla-b2g/gaia/pull/18199
The current pull request has a fix for the jank when going the task manager is shown from the rocketbar while on the homescreen. 

I'm having trouble getting rid of the active application window in a way that is clean to make the same action smooth when an application is displayed (other than the homescreen!).

I basically need the entire AppWindow to go into a hidden state with zero transitions and without having it go on top of the other windows as it's being hidden.

Alive, any suggestions here? Also, when edge gestures are enabled, can we assume that we will always have a cached screenshot available?
Flags: needinfo?(alive)
OS: Mac OS X → Gonk (Firefox OS)
Hardware: x86 → ARM
Ben, you'll probably be interested in trying out that pull request...
Flags: needinfo?(alive) → needinfo?(bfrancis)
Flags: needinfo?(alive)
(In reply to Ghislain Aus Lacroix [:aus] from comment #7)
> The current pull request has a fix for the jank when going the task manager
> is shown from the rocketbar while on the homescreen. 
> 
> I'm having trouble getting rid of the active application window in a way
> that is clean to make the same action smooth when an application is
> displayed (other than the homescreen!).
> 
> I basically need the entire AppWindow to go into a hidden state with zero
> transitions and without having it go on top of the other windows as it's
> being hidden.

I think that instead of having the cards view to maintain its own DOM and screenshoots for apps, you should reuse the #windows div and translate it to the size you want.

This div will offers you a view of all the app window in the correct order, but in the horizontal space, but also in the z-space with all the things that can cover the window (like window.alert, inline activities, etc...). It will also already contains the web browser wrapper, and in the future it may even contains the keyboard.

So instead of reading the stack and duplicating it, what about scaling the #windows div ?
(In reply to Vivien Nicolas (:vingtetun) (:21) (NOT reading bugmails, needinfo? please) from comment #9)
> (In reply to Ghislain Aus Lacroix [:aus] from comment #7)
> > The current pull request has a fix for the jank when going the task manager
> > is shown from the rocketbar while on the homescreen. 
> > 
> > I'm having trouble getting rid of the active application window in a way
> > that is clean to make the same action smooth when an application is
> > displayed (other than the homescreen!).
> > 
> > I basically need the entire AppWindow to go into a hidden state with zero
> > transitions and without having it go on top of the other windows as it's
> > being hidden.
> 
> I think that instead of having the cards view to maintain its own DOM and
> screenshoots for apps, you should reuse the #windows div and translate it to
> the size you want.
> 
> This div will offers you a view of all the app window in the correct order,
> but in the horizontal space, but also in the z-space with all the things
> that can cover the window (like window.alert, inline activities, etc...). It
> will also already contains the web browser wrapper, and in the future it may
> even contains the keyboard.
> 
> So instead of reading the stack and duplicating it, what about scaling the
> #windows div ?

Thinking loud here, we could also use a -moz-element to render the app_window div and get all the z-space stacking correct, put the app screenshot below, and read the stack manager for the horizontal space.

That will let you implement a more custom UI/UX for the cards view instead of scaling the #windows div.

Fwiw, the #windows or -moz-element approach does not changed anything to your current jank issue, but we definitively the z-space of the app to be respected at the end.
Aus, note that bug 970935 has just landed which adds the expanded state of the Rocketbar for the homescreen. This makes launching the task manager tricky from the homescreen because you have to swipe down on the Rocketbar element. Swiping from the top will currently be picked up by the statusbar-icons element which will trigger the utility tray. The reason for this is backwards compatibility when Rocketbar is turned off, but we now need to fix this for when the Rocketbar is turned on.

Feel free to ping me in IRC if you want to discuss how we could do this.
We tried to use -moz-element for our tab strip in Metro and had to ditch it because of terrible performance. It may have improved (or it may be better than the current approach), but its something to keep an eye on.
The other problem with reusing the app windows is that they may be zombified, so actually a screenshot (or app icon when app.cards_view.screenshot.enabled is false) might end up being more useful to the user (if I understand right. Perhaps the app is no longer in the stack at all in this case?). 

Also, the app or site might have changed state in the interim, so the screenshot better represents what the user last saw. The metro bug for reference was bug 831440
(In reply to Sam Foster [:sfoster] from comment #13)
> The other problem with reusing the app windows is that they may be
> zombified, so actually a screenshot (or app icon when
> app.cards_view.screenshot.enabled is false) might end up being more useful
> to the user (if I understand right. Perhaps the app is no longer in the
> stack at all in this case?). 
> 
> Also, the app or site might have changed state in the interim, so the
> screenshot better represents what the user last saw. The metro bug for
> reference was bug 831440

If an app is zombified, AppWindow.prototype.suspended would be set to true.
Please refer bug 935750's patch. https://github.com/mozilla-b2g/gaia/pull/16061/files#diff-cfa1d9813ade22ddb10164655efc52b9R299

(In reply to Ghislain Aus Lacroix [:aus] from comment #7)
> The current pull request has a fix for the jank when going the task manager
> is shown from the rocketbar while on the homescreen. 
> 
> I'm having trouble getting rid of the active application window in a way
> that is clean to make the same action smooth when an application is
> displayed (other than the homescreen!).
> 
> I basically need the entire AppWindow to go into a hidden state with zero
> transitions and without having it go on top of the other windows as it's
> being hidden.

Let's have AppWindowManager call this.activeApp.close('immediate') when your new task manager is shown.

> 
> Alive, any suggestions here? Also, when edge gestures are enabled, can we
> assume that we will always have a cached screenshot available?
Flags: needinfo?(alive)
(In reply to Vivien Nicolas (:vingtetun) (:21) (NOT reading bugmails, needinfo? please) from comment #10)
> (In reply to Vivien Nicolas (:vingtetun) (:21) (NOT reading bugmails,
> needinfo? please) from comment #9)
> > (In reply to Ghislain Aus Lacroix [:aus] from comment #7)
> > > The current pull request has a fix for the jank when going the task manager
> > > is shown from the rocketbar while on the homescreen. 
> > > 
> > > I'm having trouble getting rid of the active application window in a way
> > > that is clean to make the same action smooth when an application is
> > > displayed (other than the homescreen!).
> > > 
> > > I basically need the entire AppWindow to go into a hidden state with zero
> > > transitions and without having it go on top of the other windows as it's
> > > being hidden.
> > 
> > I think that instead of having the cards view to maintain its own DOM and
> > screenshoots for apps, you should reuse the #windows div and translate it to
> > the size you want.
> > 
> > This div will offers you a view of all the app window in the correct order,
> > but in the horizontal space, but also in the z-space with all the things
> > that can cover the window (like window.alert, inline activities, etc...). It
> > will also already contains the web browser wrapper, and in the future it may
> > even contains the keyboard.
> > 
> > So instead of reading the stack and duplicating it, what about scaling the
> > #windows div ?
> 
> Thinking loud here, we could also use a -moz-element to render the
> app_window div and get all the z-space stacking correct, put the app
> screenshot below, and read the stack manager for the horizontal space.
> 
> That will let you implement a more custom UI/UX for the cards view instead
> of scaling the #windows div.
> 
> Fwiw, the #windows or -moz-element approach does not changed anything to
> your current jank issue, but we definitively the z-space of the app to be
> respected at the end.

I am not sure if -moz-element works for mozbrowser iframe too...if that works without performance issue then \O/

But if not, after bug 916709 lands, we will have AppWindow.prototype.getTopMostWindow if you just want the top window to fetch screenshot. I am thinking about changing AppWindow.prototype.getScreenshot as well to delegate to top most window.
(In reply to Ghislain Aus Lacroix [:aus] from comment #7)
> when edge gestures are enabled, can we
> assume that we will always have a cached screenshot available?

Not all.. we will only have screenshot only when 'the app had been closed once'.
Please check what AppWindow.prototype.setVisible(false, true); does.
So for current displayed app we will have no screenshot if it has not been closed.
Flags: needinfo?(bfrancis)
I'll try to move this forward while Aus is on PTO.
Assignee: aus → sfoster
Target Milestone: 1.4 S5 (11apr) → 1.4 S6 (25apr)
I did some profiling on this and I see a consistent 300ms delay in app.getScreenshot() before showCardPicker is called. AFAICT that is the main if not sole cause of the lag we see between the swipe down gesture and the appearance of the task manager. getScreenshot unconditionally calls iframe.getScreenshot on the active app. If we set useAppScreenshotPreviews (app.cards_view.screenshots.enabled setting) that delay goes away. It
.. It looks like the app may have a cached screenshot blob - could we not use that? Or, I can chase up the suggestion to use the #windows div. I see there are other concerns up in the comments but this seems to be the main blocker to smooth transition right now.
WIP pull request https://github.com/mozilla-b2g/gaia/pull/18377 - mostly just some logging added to Aus' patch. And avoiding repeated handling of taskmanagershow event.
I did look into using -moz-element for the screenshotView background, and for a brief moment it looks great, but as we switch to the homescreen and the app goes into the background, the -moz-element's 'reflection' of the app.element fades also.
(In reply to Sam Foster [:sfoster] from comment #19)
> .. It looks like the app may have a cached screenshot blob - could we not
> use that? Or, I can chase up the suggestion to use the #windows div. I see
> there are other concerns up in the comments but this seems to be the main
> blocker to smooth transition right now.

When launching task manager for the first time with a given app running, there is no cached screenshot. I'm running out of ideas for how to mitigate this 300ms hit to acquire that screenshot. We block launching the task manager on getting that screenshot. (because we need to screenshot before we switch to homescreen as in comment 21) Maybe the transition can be tweaked to make it less jarring?
Just want to check I'm not missing the point or off in the weeds here. Ideas welcome
Flags: needinfo?(bfrancis)
You're not missing the point Sam, this is super tricky to get right.

I have a small piece of good news. With the work I'm doing in bug 993346, one part of the jank should be improved. The initial swipe down on the Rocketbar will move the AppWindow down the screen so that the Rocketbar doesn't overlap it so when the iframe is swapped out for a screenshot, it will no longer appear in front of the Rocketbar.

We still have a pretty nasty delay before the second stage of the transition starts and a low frame rate animation (I assume because screenshotting is taking place as you describe above), but I'm afraid I don't have any helpful suggestions here without spending a lot of time digging into the code :(
Flags: needinfo?(bfrancis)
Blocks: task-manager
(In reply to Sam Foster [:sfoster] from comment #21)
> I did look into using -moz-element for the screenshotView background, and
> for a brief moment it looks great, but as we switch to the homescreen and
> the app goes into the background, the -moz-element's 'reflection' of the
> app.element fades also.

But why? Switching to homescreen should hide task manager ASAP...do we have task manager closing transition as well?
Some comments in the pull request. I tried to change as little as possible at this stage to reduce regression risk. This patch gives me Card and cardSwitcher objects I can more easily extend and further refactor to build the light-weight task-manager alongside the existing card view. 

Unit tests pass and my testing has spotted no issues or regressions so far. Hopefully travis will agree. So this should be able to land as-is, or I could build on it (in which case consider this f?) and land it in one go if you prefer. 

Next steps are to rebase Aus' patch onto this and consolidate some work I've already done on using appWindows instead of card+screenshot for the task manager. 
Next steps are to rebase Aus' patch onto this.
Attachment #8408833 - Flags: review?(alive)
(In reply to Alive Kuo [:alive][NEEDINFO!][God bless Taiwan.] from comment #25)
> (In reply to Sam Foster [:sfoster] from comment #21)
> > I did look into using -moz-element for the screenshotView background, and
> > for a brief moment it looks great, but as we switch to the homescreen and
> > the app goes into the background, the -moz-element's 'reflection' of the
> > app.element fades also.
> 
> But why? Switching to homescreen should hide task manager ASAP...do we have
> task manager closing transition as well?

Currently as you launch the task manager from your active app, you get switched to the homescreen via AppWindowManager.display(null, null, 'to-cardview'). That doesnt need to happen for the rocketbar/task-manager case so I'll need to go back and check again how it looks it we remove that call.
(In reply to Sam Foster [:sfoster] from comment #27)
> (In reply to Alive Kuo [:alive][NEEDINFO!][God bless Taiwan.] from comment
> #25)
> > (In reply to Sam Foster [:sfoster] from comment #21)
> > > I did look into using -moz-element for the screenshotView background, and
> > > for a brief moment it looks great, but as we switch to the homescreen and
> > > the app goes into the background, the -moz-element's 'reflection' of the
> > > app.element fades also.
> > 
> > But why? Switching to homescreen should hide task manager ASAP...do we have
> > task manager closing transition as well?
> 
> Currently as you launch the task manager from your active app, you get
> switched to the homescreen via AppWindowManager.display(null, null,
> 'to-cardview'). That doesnt need to happen for the rocketbar/task-manager
> case so I'll need to go back and check again how it looks it we remove that
> call.

Yes that was a hacky way but I'd like to know what will happen for rocketbar/task-manager case when we closes the task manager, could you kindly point me out where's this spec?
Comment on attachment 8408833 [details] [review]
Refactor CardView a bit in preparation for next steps

Sam, thank you for stepping out the first step to clear the old fashion cardsview. This isn't a easy step.

Although all tests are passed, I still have some requirement here:
1. Split down each module to be a file. (card & cardswitcher)
2. Have unit test for all of your new module.
3. Use class for cardswitcher to align with system app 2 pattern.

I know this will take more time to go through.
Attachment #8408833 - Flags: review?(alive) → feedback+
And you are welcome to find me on IRC to discuss about architecture design problem.
I'm most of the way through the refactoring. Unit tests still todo, see other notes on the pull request (though these mostly pertain to bug 967428). 

Not sure if CardManager should continue to be one class with the if (isRocketbar) branches or if it should be broken into 2? 

Also not sure how to handle the CardView itself - should it go away? Or leave the external face as-is and just change out the internal implementation?
Attachment #8408833 - Attachment is obsolete: true
Attachment #8412028 - Flags: feedback?(alive)
I did some more digging into the original issue here - the janky transition when showing the task manager from the rocketbar. Some thoughts, probably not very well connected together: 

In the code it says 

    // Ensure homescreen is already faded when we switch to it.
    fireCardViewBeforeShow();

The comment is misleading. The homescreen launcher does listen for cardviewbeforeshow and calls this.getHomescreen().fadeOut(), but fadeOut will do nothing unless the app is active. So the homescreen must be active before we can fade it out. That's presumably the idea of calling AppWindowManager.display(null, null, 'to-cardview'). But actually, if you turn off the background on #card-view when the switcher is shown, you'll see the homescreen behind, not faded out. 

(Also, not an issue but I was surprised to discover that fadeOut is sync, it adds a .fadeout class which basically toggles visibility of a fadeout overlay - there's no animation here that I can find.)

For the rocketbar/taskmanager, we want that faded state behind the switcher. Is the task manager supposed to be a kind of state of the homescreen? I'm not sure why we need to switch to it here. Maybe it makes sense as a kind of neutral state to be in? Its going to be hard to smoothly animate the scaling of the current app if we are switching away from it at the same time; it seems to me that we need a different way to fadeOut the homescreen that doesn't require it to be active.
(In reply to Sam Foster [:sfoster] from comment #31)
> Created attachment 8412028 [details] [review]
> (WIP) Rework cards view to implement new task-manager look/feel and behavior
> 
> I'm most of the way through the refactoring. Unit tests still todo, see
> other notes on the pull request (though these mostly pertain to bug 967428). 
> 
> Not sure if CardManager should continue to be one class with the if
> (isRocketbar) branches or if it should be broken into 2? 
> 
> Also not sure how to handle the CardView itself - should it go away? Or
> leave the external face as-is and just change out the internal
> implementation?

Quick answer: I'd like to remove cards_view.js and have task_manager.js and remove all reference to use the term 'CardView'. But it's up to you to do this in followup.
Comment on attachment 8412028 [details] [review]
(WIP) Rework cards view to implement new task-manager look/feel and behavior

Nice nontrivial work!
Attachment #8412028 - Flags: feedback?(alive) → feedback+
(In reply to Sam Foster [:sfoster] from comment #21)
> I did look into using -moz-element for the screenshotView background, and
> for a brief moment it looks great, but as we switch to the homescreen and
> the app goes into the background, the -moz-element's 'reflection' of the
> app.element fades also.

I feel like bug 1002430 may help here.
Target Milestone: 1.4 S6 (25apr) → 2.0 S1 (9may)
(In reply to Vivien Nicolas (:vingtetun) (:21) (NOT reading bugmails, needinfo? please) from comment #35)
> (In reply to Sam Foster [:sfoster] from comment #21)
> > I did look into using -moz-element for the screenshotView background, and
> > for a brief moment it looks great, but as we switch to the homescreen and
> > the app goes into the background, the -moz-element's 'reflection' of the
> > app.element fades also.
> 
> I feel like bug 1002430 may help here.

FTR the performance of -moz-element is usually not great as the whole area if always repainted even when there is a 1px changes. But for the purpose of the task manager it's probably OK as the user won't interact with the app itself.

Also since the presShell of the app won't be active for background apps, it should limit the number of graphic things going on and forcing a repaint. Some media element may repaints though but that's likely a bug as they need to be frozen when the presShell goes inactive.
Actually the current plan is to style the appWindow instances directly to present the task manager. It may switch from a live iframe to a screenshot depending on state, but the seperate cards to represent each app - which was where we were considering -moz-element - are (will be) gone.
No longer blocks: task-manager
Depends on: task-manager
Target Milestone: 2.0 S1 (9may) → 2.0 S2 (23may)
feature-b2g: --- → 2.1
Target Milestone: 2.0 S2 (23may) → ---
blocking-b2g: --- → backlog
Updated user story with visual specs
User Story: (updated)
Perf : performance concerns based on graphics transitions.
Keywords: perf
Depends on: 1045777
Depends on: 1045784
Depends on: 1045787
Depends on: 1045790
Whiteboard: [ucid:System159, 1.4:P2, ft:systems-fe][systemsfe][p=5] → [c=progre
tagging this to be added to perf team backlog.
Whiteboard: [c=progre → [c=progress p= s= u=][ucid:System159, 1.4:P2, ft:systems-fe][systemsfe][p=5]
Priority: -- → P2
Depends on: 1051095
No longer depends on: 1051095
Based on the target milestones in the dependencies, this bug should have sprint 3 as the target milestone.
Target Milestone: --- → 2.1 S3 (29aug)
Blocks: rocketbar-mvp
No longer blocks: rocketbar-search-mvp
Depends on: 967421
Depends on: 1055158
User Story: (updated)
Depends on: 1056220
Depends on: 941238
Depends on: 1057396
Depends on: 1040787
feature-b2g: 2.1 → 2.2?
Unblocking rocketbar-mvp as it's not directly tied into rocketbar with the new design anymore.
No longer blocks: rocketbar-mvp
Depends on: 1065431
Target Milestone: 2.1 S3 (29aug) → 2.1 S4 (12sep)
Priority: P2 → P3
Target Milestone: 2.1 S4 (12sep) → ---
Attachment #8405108 - Attachment is obsolete: true
Attachment #8412028 - Attachment is obsolete: true
Is this story still in 2.2 scope?
Flags: needinfo?(wmathanaraj)
(In reply to Hermes Cheng[:hermescheng] from comment #43)
> Is this story still in 2.2 scope?

I think not, but master already has some of the planned Haida-style horizontal task strip changes, so we should figure out what if anything is required for the feature (Francis?). Rolling back to 2.1's task manager is not really an option so we need to lock down what we have. As far as I know, the only potentialy blocking issues are around orientation, see bug 1111795
Flags: needinfo?(fdjabri)
Candice, can you follow up this topic? Thanks.
feature-b2g: 2.2? → ---
Flags: needinfo?(cserran)
Flags: needinfo?(cserran)
Whiteboard: [c=progress p= s= u=][ucid:System159, 1.4:P2, ft:systems-fe][systemsfe][p=5] → systemsfe
No longer depends on: 1040787
Depends on: 1040787
This is in scope for 2.2 and was not updated correctly. It was fall out from 2.1. Will need full QA support and review. Kevin, can you please add this to your list. Updated target milestone
feature-b2g: --- → 2.2+
Target Milestone: --- → 2.2 S5 (6feb)
Flags: needinfo?(khu)
Can QA start testing done items in parallel with UX review please? Adjusted 2.2 scope fyi
Keywords: qawanted
UX priorities are documented in this etherpad:

https://etherpad.mozilla.org/task-manager-ux-review
Flags: needinfo?(fdjabri)
Hermes Cheng is identified as the testing lead for Task Manager feature. So, the question should go to Hermes. Ni Hermes here.
Flags: needinfo?(khu) → needinfo?(hcheng)
(In reply to Candice Serran (:cserran) from comment #46)
> This is in scope for 2.2 and was not updated correctly. It was fall out from
> 2.1. Will need full QA support and review. Kevin, can you please add this to
> your list. Updated target milestone

Looks like we will finish this after 2.2 branch is created. We need to evaluate this and the release management team will need to give approvals based on the evaluation.
Flags: needinfo?(hcheng)
QA Contact: hcheng
Is it possible to disable orientation and landscape mode of Task manager in v2.2?
Flags: needinfo?(sfoster)
Yeah, bug 1118390 is in-progress and will land in v2.2. If we can get the various orientation issues worked out in time we may be able to re-enable the landscape mode but its assumed portrait-only (like 2.1 and previous versions) will be what we ship with.
Flags: needinfo?(sfoster)
***Test Summary***
17 tests ran, 16 passed, 1 failed (Bug 1123196).

***Test Run record***
https://moztrap.mozilla.org/runtests/run/6240/env/27835/?sortfield=order&sortdirection=asc

***Build Info***
Build ID               20150118162501
Gaia Revision          f5b3d1b6cfa3e702033f613915ae637cb735cbfb
Gaia Date              2015-01-17 00:16:28
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/8067c111ddff
Gecko Version          37.0a2
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150118.195525
Firmware Date          Sun Jan 18 19:55:36 EST 2015
Bootloader             L1TC000118D0
Depends on: 1128630
No longer depends on: 1065431
No longer depends on: 1045790
:djabber, We've closed out the last dependancy on this "feature" for 2.2. With the changing scope for 2.2 I *think* we've got all the must-haves; can you look it over for feature-completeness?
Flags: needinfo?(fdjabri)
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Verifying fix on 3.0 for flame devices
https://etherpad.mozilla.org/task-manager-ux-review
Results: TaskManager implements fluid movement between separate tasks, handles crashed/zombie apps uniformly, contains home button flow (for returning home), display accurate titles (and browser URLs) overhead each task and with controlled jank in between capturing new screenshots.

--------------------------------------------------
Environmental Variables:
Device: Flame 3.0
BuildID: 20150210010523
Gaia: 0cf517083f7eb5fc269e1236edba50534f65e3cd
Gecko: 2cb22c058add
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 38.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0
--------------------------------------------------
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Keywords: qawanted
Test run to sign off the v2.2 FL phase

***Test Summary***
18 tests ran, 18 passed

***Test Run record***
https://moztrap.mozilla.org/runtests/run/6421/env/27835/

***Build Info***
Build ID               20150212162852
Gaia Revision          ab9029f2b203e2a36e8f81edd17fa5ff81c874b5
Gaia Date              2015-02-12 21:09:11
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/b1d3839680fb
Gecko Version          37.0a2
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150212.200144
Firmware Date          Thu Feb 12 20:01:55 EST 2015
Bootloader             L1TC000118D0
blocking-b2g: backlog → ---
feature-b2g: 2.2+ → ---
Flags: needinfo?(wmathanaraj)
Keywords: feature
Flags: needinfo?(fdjabri)
You need to log in before you can comment on or make changes to this bug.