1147964 - [Windows Management] A bad looking transition occurs when selecting 'install X app' from the rocketbar results while on a list selection page (example: Settings > Display > Timeout > Select time page)

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)

Description

[Joshua Mitchell (Inactive)]

Attachment: logcat_20150326_0920.txt

Description:
When on a list page (where you pick from a list of choices) there is an ugly transition if you access the rocketbar search and select 'install X app'. You will see it return to the list page, and then it will slide off, a brief glimpse of the marketplace loading screen, then the list page again and then transition to the marketplace continues. This looks particularly bad on a time wheel / reel selection page such as when creating an alarm and setting the time. The time reel page will slide off, a brief glimpse of marketplace loading, then when it returns to the time selection reel, the reels will reset and spin to the current time, and then the final transition to the marketplace. (Both scenarios shown in video)

Repro Steps:
1) Update a Flame to 20150326010205
2) Launch Settings > Display > Timeout selection page
3) Tap the rocket bar and type in a few letters (example: Zom)
4) Tap an 'install X app' result


Actual:
rough / choppy transition

Expected:
smoother transition 

Environmental Variables:
Device: Flame Master
Build ID: 20150326010205
Gaia: 8dc256a2de273be3abfa2cb2103d872d677834f7
Gecko: 37d3dcbf23a9
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 39.0a1 (Master)
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0


Repro frequency: 8/8
See attached: logcat, video clip: http://youtu.be/ZsczyV3NtWQ

Comment 1

[Joshua Mitchell (Inactive)]

This issue also occurs in Flame 2.2 

Device: Flame 2.2 (KK - Nightly - Full Flash - 319mem)
Build ID: 20150325002503
Gaia: aeee2a54caa8ffb875b96264b61d742b70689f22
Gecko: 556aca3e50ac
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 37.0 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

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

This issue does NOT reproduce in 2.1 

Actual Results: when tapping on the rocketbar from the list screen the list screen will close (behind the search page) and when the 'install X app' is tapped, a direct transition to marketplace occurs

Device: Flame 2.1 (KK - Nightly - Full Flash - 319mem)
Build ID: 20150325001202
Gaia: b8ae0df34362420fe4a9c90effa5247a1f5c844d
Gecko: 2a05cd42088b
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 34.0 (2.1)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Comment 2

[Gregor Wagner [:gwagner]]

Can we get a regression window?

Comment 3

[Gregor Wagner [:gwagner]]

Alive, Etienne, can you take a look here?

Comment 4

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

A regression cannot be found for this issue.  I was able to reproduce it in the earliest available Flame KK build.  Also the further back you go the lower the repro rate is.

Environmental Variables:
Device: Flame 2.2
BuildID: 20140904171737
Gaia: de59e0c3614dd0061881fe284e9f2d74fa0d1d5d
Gecko: 8703c1895505
Version: 35.0a1 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0


I could not reproduce this issue on Flame JB 2.2 builds.

Environmental Variables:
Device: Flame 2.2
BuildID: 20140906031900
Gaia: c7de02ef1e0ad97d86e5bbef2d19828a236aea27
Gecko: 2255d7d187b2
Version: 35.0a1 (2.2) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Comment 5

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

This is a really interesting case.
The root cause is: rocketbar deactivation will trigger HierarchyManager to tell AppWindowManager to refocus the active app; however this active app is going inactive just after the launch request.

Since it makes no sense to handle the launchapp event in certain order, my idea to fix this is:
If HierarchyManager asks AppWindowManager to setHierarchy(true), AppWindowManager should check if AppWindowFactory has a launching-and-not-at-background appWindow. If there is, skip the focus request this time. The launching appWindow instance will be dropped once it is opened.

Etienne, what do you think about this?

Comment 6

[GitHub Autolander Bot]

Attachment: [gaia] alivedise:bugzilla/1147964/select-in-incoming-app > mozilla-b2g:master

Comment 7

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

Comment on attachment 8585310 [details] [review]
[gaia] alivedise:bugzilla/1147964/select-in-incoming-app > mozilla-b2g:master

Let me know what you think.

Comment 8

[Etienne Segonzac (:etienne)]

Comment on attachment 8585310 [details] [review]
[gaia] alivedise:bugzilla/1147964/select-in-incoming-app > mozilla-b2g:master

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #5)
> This is a really interesting case.
> The root cause is: rocketbar deactivation will trigger HierarchyManager to
> tell AppWindowManager to refocus the active app; however this active app is
> going inactive just after the launch request.
> 
> Since it makes no sense to handle the launchapp event in certain order, my
> idea to fix this is:
> If HierarchyManager asks AppWindowManager to setHierarchy(true),
> AppWindowManager should check if AppWindowFactory has a
> launching-and-not-at-background appWindow. If there is, skip the focus
> request this time. The launching appWindow instance will be dropped once it
> is opened.
> 
> Etienne, what do you think about this?

This part makes sense to me.

Now about the code:
* why exactly do we need to listen to _terminated too?
* can we remove the listeners as soon as we get one of the events? (and looks like we're missing removeEventListeners in the wrapperFactory)
* hasLaunchingWindow -> isLaunchingWindow

Comment 9

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

(In reply to Etienne Segonzac (:etienne) from comment #8)
> Comment on attachment 8585310 [details] [review]
> [gaia] alivedise:bugzilla/1147964/select-in-incoming-app > mozilla-b2g:master
> 
> (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #5)
> > This is a really interesting case.
> > The root cause is: rocketbar deactivation will trigger HierarchyManager to
> > tell AppWindowManager to refocus the active app; however this active app is
> > going inactive just after the launch request.
> > 
> > Since it makes no sense to handle the launchapp event in certain order, my
> > idea to fix this is:
> > If HierarchyManager asks AppWindowManager to setHierarchy(true),
> > AppWindowManager should check if AppWindowFactory has a
> > launching-and-not-at-background appWindow. If there is, skip the focus
> > request this time. The launching appWindow instance will be dropped once it
> > is opened.
> > 
> > Etienne, what do you think about this?
> 
> This part makes sense to me.
> 
> Now about the code:
> * why exactly do we need to listen to _terminated too?

Because it's possible to be killed(OOM) before the opened event, and we will get stuck in the launching state if we don't get the terminated event.

Comment 10

[Etienne Segonzac (:etienne)]

Comment on attachment 8585310 [details] [review]
[gaia] alivedise:bugzilla/1147964/select-in-incoming-app > mozilla-b2g:master

Cool, r=me with nits

Comment 11

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

nit addressed, re-running tests.

Comment 12

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

https://github.com/mozilla-b2g/gaia/commit/f37be8b44cb7c3a147b9615ab76743b760f08eeb

Comment 13

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

Comment on attachment 8585310 [details] [review]
[gaia] alivedise:bugzilla/1147964/select-in-incoming-app > mozilla-b2g:master

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #):
Regression because of combined result of several features - rocketbar, hierarchyManager, appValueSelector, APZC, gecko/FocusManager change. So there's no bug #.
[User impact] if declined:
User will the the value selector triggered by window A appears in window B for a while.
[Testing completed]: Yes
[Risk to taking this patch] (and alternatives if risky): riskless. Adding an internal statement to check there is a window launching before re-focus.
[String changes made]: NaN

Comment 14

[Ryan VanderMeulen [:RyanVM]]

Needs rebasing for v2.2 uplift.

Comment 15

[Ryan VanderMeulen [:RyanVM]]

v2.2: https://github.com/mozilla-b2g/gaia/commit/0464192311e4bbc4bd048fb48878e77e4ca44722

Comment 16

[Yeojin Chung [:YeojinC]]

This issue is verified fixed on Flame Master and 2.2.

Result: No switching screens back and forth between transitioning to Marketplace.

Environmental Variables:
Device: Flame 3.0 (KK, 319mb, full flash)
Build ID: 20150409010203
Gaia: 5dfd0460eb6e616205154b0d219aa5123bf1abb3
Gecko: 8f57f60ee58a
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 40.0a1 (Master)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0


Environmental Variables:
Device: Flame 2.2 (KK, 319mb, full flash)
Build ID: 20150409002503
Gaia: ea735c21bfb0d78333213ff0376fce1eac89ead6
Gecko: 0efd5cdbe224
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

============================================================
However, the rocketbar expansion occurs underneath the dropdown menu screen. Filed a new bug 1153025.