Closed Bug 844990 Opened 10 years ago Closed 9 years ago

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

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:tef+, b2g18 fixed, b2g18-v1.0.0 wontfix, b2g18-v1.0.1 fixed)

VERIFIED FIXED
blocking-b2g tef+
Tracking Status
b2g18 --- fixed
b2g18-v1.0.0 --- wontfix
b2g18-v1.0.1 --- fixed

People

(Reporter: nhirata, Assigned: alive)

References

Details

(Keywords: regression)

Attachments

(1 file)

## 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.
blocking-b2g: leo? → leo+
Keywords: regression
Taken to see if reproducible.
Assignee: nobody → alive
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.
Patch:
remove the delay of windowOpened function call.
It shouldn't be put late after browser frame is loaded.
Attachment #723889 - Flags: review?(timdream)
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.
Attachment #723889 - Flags: review?(timdream) → review+
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...
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
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
blocking-b2g: leo+ → tef?
blocking-b2g: tef? → tef+
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 :)
Duplicate of this bug: 850557
(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.
Flags: in-moztrap-
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
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.