844990 - Launching another app while one is launching can cause you to get stuck in the second app until you reboot the phone.

Status: VERIFIED FIXED

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

Description

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

## Environment :
Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/f96b3fe5d05b
Gaia   539e4f57b25b839b7b3d25619c0dc53fd1d67579
BuildID 20130225070202
Version 18.0
Unagi
  
## Repro :
1. launch email
2. hit home while email is launching
3. launch clock app

## Expected :
clock can be interacted with, can long tap to get to task manager or tap home to get to the homescreen.

## Actual :
1. you can interact with the clock, long tap on home shows no apps, tapping on home doesn't go to homescreen.

## Note :
1. noted while testing around fix for  bug 836664; need to test in v101...
2. need to reboot in order to get phone functioning normally again.
3. see video : http://www.youtube.com/watch?v=Rv6hgOuCskU&feature=youtube_gdata_player

Comment 1

[Dietrich Ayala (:dietrich)]

Dylan repro'd in triage.

Comment 2

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

Taken to see if reproducible.

Comment 3

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

Easy repro in gaia master, OOPS :|
I guess something is wrong in Window Manager...

Comment 4

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

This is a regression caused by patch of bug 842627.
It introduces a race condition that the two functions are competing for settings displayedApp:
1. openWindow by setDisplayedApp(homescreen)
2. windowOpened by onWindowReady which depends on mozbrowserloadend is fired.

Comment 5

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

See https://bugzilla.mozilla.org/show_bug.cgi?id=842627#c7

Comment 6

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

Attachment: https://github.com/mozilla-b2g/gaia/pull/8597

Patch:
remove the delay of windowOpened function call.
It shouldn't be put late after browser frame is loaded.

Comment 7

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 723889 [details]
https://github.com/mozilla-b2g/gaia/pull/8597

I would love to retain "If this is a cold launch let's wait for the app to load first" functionality if that's possible, but given the fact bug 842627 is incorrectly implemented, let's remove it in this bug so people can give it a second try.

I thought we should block the home key (and any other app switch thing) during app cold start (that what iOS do), but we shouldn't be waiting for mozbrowserloadend at all as the app could coming from the network.

Comment 8

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Adding dependency and flags to raise the issue. Should we make this tef+ so that we could fix the regression on v1-train and v1.0.1?

Comment 9

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

v1-train: 
https://github.com/mozilla-b2g/gaia/commit/09f34cec911b98f934675cb66de8e3b1a264a12a

master: 
https://github.com/mozilla-b2g/gaia/commit/b954a366ae0cb90bc6c5b8af4d83c064374d3c0e

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (PTO Mar 22 - Apr 7) from comment #8)
> Adding dependency and flags to raise the issue. Should we make this tef+ so
> that we could fix the regression on v1-train and v1.0.1?

I recall that leo+ goes to v1-train...and yes, this should go to v1.0.1 too.
But we don't have second flag for blocking-b2g...

Comment 10

[Julien Wajsberg [:julienw]]

Alive, for v1.0.1, you have to ask tef+.

Comment 11

[John Ford [:jhford] CET/CEST Berlin Time]

In response to comment 9 and 10, I've changed the flag from leo+ to tef? to request landing on v1.0.1

Comment 12

[Julien Wajsberg [:julienw]]

So I guess we lost most of the perf improvements gained in Bug 842627, see https://datazilla.mozilla.org/b2g/.

Any thought on how to restore what we lost here ?

Comment 13

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

(In reply to Julien Wajsberg [:julienw] from comment #12)
> So I guess we lost most of the perf improvements gained in Bug 842627, see
> https://datazilla.mozilla.org/b2g/.
> 
> Any thought on how to restore what we lost here ?

Maybe try Tim suggested: block home button when booting an app. But I am not sure if that works now.

Comment 14

[Julien Wajsberg [:julienw]]

Not sure we want to do that: we don't want that an app that takes long to boot blocks the home button during this long time.

Another possibility: when launching an app, if an app is already launching, don't launch the new app yet, rather wait that the first app finished booting.

We'll look into this (again) with Etienne next week :)

Comment 16

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

(In reply to Julien Wajsberg [:julienw] from comment #14)
> Not sure we want to do that: we don't want that an app that takes long to
> boot blocks the home button during this long time.
> 

I just find another regression caused by 842627.

I have to say, I am not sure if we should win ~100ms performance improvement with the high-possibility-rate regressions.
Challenging performance improvement make people exciting, I do admit.
But we should base on a reliable condition to do it.
Window Manager now, isn't really a good place to do such "experiments".

> Another possibility: when launching an app, if an app is already launching,
> don't launch the new app yet, rather wait that the first app finished
> booting.

Don't do this.

It's hard to determine to block or not the new app because app may be triggered by lots methods.
Web activities, some other modules call app.launch (bad!) in system apps, open from homescreen, injecting src to mozbrowser iframe...

> 
> We'll look into this (again) with Etienne next week :)

I'm happy if you could loop me in ;)

Comment 17

[Julien Wajsberg [:julienw]]

(In reply to Alive Kuo [:alive] (PTO during 3/27~4/7) from comment #16)
> (In reply to Julien Wajsberg [:julienw] from comment #14)
> > Not sure we want to do that: we don't want that an app that takes long to
> > boot blocks the home button during this long time.
> > 
> 
> I just find another regression caused by 842627.
> 
> I have to say, I am not sure if we should win ~100ms performance improvement
> with the high-possibility-rate regressions.
> Challenging performance improvement make people exciting, I do admit.
> But we should base on a reliable condition to do it.
> Window Manager now, isn't really a good place to do such "experiments".

Yep, agreed, we must take care of all these states ;)

> 
> > Another possibility: when launching an app, if an app is already launching,
> > don't launch the new app yet, rather wait that the first app finished
> > booting.
> 
> Don't do this.
> 
> It's hard to determine to block or not the new app because app may be
> triggered by lots methods.
> Web activities, some other modules call app.launch (bad!) in system apps,
> open from homescreen, injecting src to mozbrowser iframe...

but we always get the "webapps-launch" event from Chrome for all these events, I think that's what triggers everything and I was really meaning this. But this may still not be a good idea ;)

> 
> > 
> > We'll look into this (again) with Etienne next week :)
> 
> I'm happy if you could loop me in ;)

Yes for sure, you'd be the good person to review this. Not sure yet if we'll do it though ;)

Comment 18

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

(In reply to Julien Wajsberg [:julienw] from comment #17)
> (In reply to Alive Kuo [:alive] (PTO during 3/27~4/7) from comment #16)
> > > Another possibility: when launching an app, if an app is already launching,
> > > don't launch the new app yet, rather wait that the first app finished
> > > booting.
> > 
> > Don't do this.
> > 
> > It's hard to determine to block or not the new app because app may be
> > triggered by lots methods.
> > Web activities, some other modules call app.launch (bad!) in system apps,
> > open from homescreen, injecting src to mozbrowser iframe...
> 
> but we always get the "webapps-launch" event from Chrome for all these
> events, I think that's what triggers everything and I was really meaning
> this. But this may still not be a good idea ;)

That's just the problem: we have difficulty to distinguish who is opening and why do they want to open a new app. We just obey the event to open, no violence.

> 
> > 
> > > 
> > > We'll look into this (again) with Etienne next week :)
> > 
> > I'm happy if you could loop me in ;)
> 
> Yes for sure, you'd be the good person to review this. Not sure yet if we'll
> do it though ;)

Thanks! (I know timezone difference is a problem.)

Comment 19

[Julien Wajsberg [:julienw]]

v1.0.1: f877115c1c7ad68958698058935a67041462d602

alive: does that looks ok ? I tested on the device and it seems ok but I'd like a second look

Comment 20

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

(In reply to Julien Wajsberg [:julienw] from comment #19)
> v1.0.1: f877115c1c7ad68958698058935a67041462d602
> 
> alive: does that looks ok ? I tested on the device and it seems ok but I'd
> like a second look

feedback+, thanks.
I hope this could avoid birth of bunch of new bugs from 842627 :)

Comment 21

[amiller]

Does not make sense to create a regression issue.

Comment 22

[mlevin]

Verified fixed the following:
1. launch email
2. hit home while email is launching
3. launch clock app
Clock can be interacted with, can long tap to get to task manager or tap home to get to the homescreen.

Verified on Unagi with:
Build ID: 20130325070201
Kernel Date: Dec 5
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/4931ec89ebbe
Gaia: 701b594c3e320030c538aa19f702764b29a6cc1c