967420 - [User Story] Launching Task Manager

Status: VERIFIED FIXED

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

Comment 1

[Peter Dolanjski [:pdol]]

UX Specs

Portrait 
https://mozilla.box.com/s/nwr2w7g32sbkfjx0efau

Landscape
https://mozilla.box.com/s/7wsuppddj8mewzkch5yr

Comment 2

[Peter Dolanjski [:pdol]]

Flow specs:
https://mozilla.box.com/s/tzxu9z9j5c1vs5y9y5z4

Comment 3

[Aus Lacroix [:aus]]

Working on this starting today!

Comment 4

[Aus Lacroix [:aus]]

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)

Comment 5

[Aus Lacroix [:aus]]

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

Comment 6

[Aus Lacroix [:aus]]

Attachment: Pull Request - Fix visual jank and poor performance when showing Task Manager from Rocketbar

Work in progress.

Comment 7

[Aus Lacroix [:aus]]

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?

Comment 8

[Aus Lacroix [:aus]]

Ben, you'll probably be interested in trying out that pull request...

Comment 9

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(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 ?

Comment 10

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(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.

Comment 11

[Ben Francis [:benfrancis]]

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.

Comment 12

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

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.

Comment 13

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

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

Comment 14

[(inactive after 6/18) Alive Kuo [:alive]]

(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?

Comment 15

[(inactive after 6/18) Alive Kuo [: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.

Comment 16

[(inactive after 6/18) Alive Kuo [:alive]]

(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.

Comment 17

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

I'll try to move this forward while Aus is on PTO.

Comment 18

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

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

Comment 19

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

.. 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.

Comment 20

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

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.

Comment 21

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

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.

Comment 22

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

(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?

Comment 23

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

Just want to check I'm not missing the point or off in the weeds here. Ideas welcome

Comment 24

[Ben Francis [:benfrancis]]

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 :(

Comment 25

[(inactive after 6/18) Alive Kuo [:alive]]

(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?

Comment 26

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

Attachment: Refactor CardView a bit in preparation for next steps

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.

Comment 27

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

(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.

Comment 28

[(inactive after 6/18) Alive Kuo [:alive]]

(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 29

[(inactive after 6/18) Alive Kuo [:alive]]

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.

Comment 30

[(inactive after 6/18) Alive Kuo [:alive]]

And you are welcome to find me on IRC to discuss about architecture design problem.

Comment 31

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

Attachment: (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?

Comment 32

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

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.

Comment 33

[(inactive after 6/18) Alive Kuo [:alive]]

(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 34

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 8412028 [details] [review]
(WIP) Rework cards view to implement new task-manager look/feel and behavior

Nice nontrivial work!

Comment 35

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(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.

Comment 36

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(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.

Comment 37

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

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.

Comment 38

[Eric Pang [:epang] UX]

Updated user story with visual specs

Comment 39

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

Perf : performance concerns based on graphics transitions.

Comment 40

[Dave Huseby [:huseby]]

tagging this to be added to perf team backlog.

Comment 41

[Kai-Chih Hu [:khu]]

Based on the target milestones in the dependencies, this bug should have sprint 3 as the target milestone.

Comment 42

[Kevin Grandon :kgrandon]

Unblocking rocketbar-mvp as it's not directly tied into rocketbar with the new design anymore.

Comment 43

[Hermes Cheng (inactive after July 27, 2015)]

Is this story still in 2.2 scope?

Comment 44

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

(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

Comment 45

[Kai-Chih Hu [:khu]]

Candice, can you follow up this topic? Thanks.

Comment 46

[Candice Serran (:cserran)]

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

Comment 47

[Candice Serran (:cserran)]

Can QA start testing done items in parallel with UX review please? Adjusted 2.2 scope fyi

Comment 48

[Francis Djabri [:djabber]]

UX priorities are documented in this etherpad:

https://etherpad.mozilla.org/task-manager-ux-review

Comment 49

[Kai-Chih Hu [:khu]]

Hermes Cheng is identified as the testing lead for Task Manager feature. So, the question should go to Hermes. Ni Hermes here.

Comment 50

[Kai-Chih Hu [:khu]]

(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.

Comment 51

[Hermes Cheng (inactive after July 27, 2015)]

Is it possible to disable orientation and landscape mode of Task manager in v2.2?

Comment 52

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

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.

Comment 53

[Hermes Cheng (inactive after July 27, 2015)]

Update Test Suite "[General]Card View/Task Switcher/Task Manager" from v2.2 for this story

https://moztrap.mozilla.org/manage/cases/?&pagenumber=1&pagesize=20&sortfield=created_on&sortdirection=desc&filter-productversion=217&filter-suite=145

Comment 54

[Hermes Cheng (inactive after July 27, 2015)]

***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

Comment 55

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

: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?

Comment 56

[Oliver Nelson [:oliverthor]]

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
--------------------------------------------------

Comment 57

[Hermes Cheng (inactive after July 27, 2015)]

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