579982 - Handle Pause and Resume with multiple processes

Status: RESOLVED WONTFIX

(Core Graveyard :: Widget: Android, defect)

Description

[Brad Lassey [:blassey] (use needinfo?)]

In the single process world we handled this by blocking the message loop with a cond var. (http://mxr.mozilla.org/mozilla-central/source/widget/src/android/nsAppShell.cpp#266) Even this approach needs more work to handle allowing things like downloads to happen in the background.

Comment 1

[Brad Lassey [:blassey] (use needinfo?)]

Attachment: wip

Comment 2

[Michael Wu [:mwu]]

Comment on attachment 458588 [details] [diff] [review]
wip

The parent process should *never* be paused because we have full control of it and we should be fixing things that are unnecessarily waking us.

The pausing should probably be a hint/observer topic so we can implement policy elsewhere.

Comment 3

[Alon Zakai (:azakai)]

(In reply to comment #1)
> Created attachment 458588 [details] [diff] [review]
> wip

Looks good to me.

I think it would be very useful if this were scriptable, as at some point it would be great for addons to be able to control this. For example, an addon that lets you freeze particular tabs manually (once we have one process per tab), or if we add content throttling, then an addon to control that, etc.

(In reply to comment #2)
> 
> The pausing should probably be a hint/observer topic so we can implement policy
> elsewhere.

I agree. We need to make a list of the relevant topics. For that, I would like to read the MeeGo docs for the application lifecycle, then compare to Android, and work based off of those two (working based on just one might lead to something not general enough). Currently I am waiting on the MeeGo docs.

Comment 4

[Oleg Romashin (:romaxa)]

do you really think that kill STOP is good way to suspend child process? how about web radio playing in background and some other features which probably want to be  alive in background?

Comment 5

[Alon Zakai (:azakai)]

(In reply to comment #3)
> We need to make a list of the relevant topics.

Let's summarize the various OS options here on this new wiki page:

https://wiki.mozilla.org/Mobile/PowerManagement

Comment 6

[Brad Lassey [:blassey] (use needinfo?)]

handing this off to Alon since he's thinking about the big picture here

Comment 7

[Alon Zakai (:azakai)]

In https://bugzilla.mozilla.org/show_bug.cgi?id=568054#c6 there is a patch for
a nice scriptable interface for freezing processes (also throttling).

If feedback for that is ok, then we should change the patch in this bug to use that interface.

Comment 8

[Alon Zakai (:azakai)]

The big picture approach has not been accepted (see bug 568054 for details). So this particular issue should be handled in an Android-specific way as best we can. Handing back to blassey for that.

If the above patch works well on Android, then let's just use that. Should probably move the stuff from dom/ipc into widget/src/android though.

Comment 9

[Jeremias Bosch (:jbos)]

That is a issue on meego too.

Comment 10

[Alon Zakai (:azakai)]

(In reply to comment #9)
> That is a issue on meego too.

I guess we need to determine if Meego has an application state that the OS tells us about, in which we can freeze Fennec. And whether it is safe then to freeze all of it or just content. But we should open another bug for Meego on this topic.

Comment 11

[Doug Turner (:dougt)]

we are not going with this approach.  instead we are committed to addressing everything that's noisy after the child is suppose to be idle.

unblocking.  I will leave it to brad to close this bug if he feels so inclined.

Also see:  bug 359608, and bug 564118, and bug 584660