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

Dylan repro'd in triage.

Taken to see if reproducible.

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

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.

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

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

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.

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?

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

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

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

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 ?

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

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

(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 ;)

(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 ;)

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

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

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

Does not make sense to create a regression issue.

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