Processes/Apps that are running in the background should not get killed; Allow for user priority for certain apps.

RESOLVED WONTFIX

Status

defect
RESOLVED WONTFIX
6 years ago
a year ago

People

(Reporter: nhirata, Unassigned)

Tracking

unspecified
x86
macOS

Firefox Tracking Flags

(blocking-b2g:-, blocking-basecamp:-, b2g18+)

Details

Attachments

(1 attachment)

## Environment :
Unagi phone, build 2012-12-21

## Repro :
1. go to contacts, import all facebook contacts
2. place contacts in the background
3. launch camera, gallery, email
4. launch gallery and do photo editing

## Expected :
1. facebook contacts will continue to import

## Actual :
1. contacts app is killed over camera app

## Note :
1. I don't think anyone will want to sit and wait until all their facebook imports.  They will either set the phone aside or go to a different app.

Comment 1

6 years ago
I've also encountered this running the Music app in the background. Launch a couple more apps, and suddenly the music stops playing because Music has been closed. :(

There should possibly be some way for apps to distinguish between "I just happen to be in the background doing nothing, go ahead and close me out if memory gets low" and "I'm actually doing something the user wants, don't close me if you can avoid it".
Triage: BB-, tracking-b2g18+. 
optimization. Nice to have
blocking-basecamp: ? → -
tracking-b2g18: --- → +
We probably need to tweak the bug description, otherwise the only fix would be
http://www.downloadmoreram.com/download.html

 :)

Comment 4

6 years ago
Posted video video_attachment
Naoki, is it a similar issue or needs to open a new bug?

When opening an another app, while one app is already running, the second application kills a running process of the first app.

Steps to reproduce:
1) Open an app and click on any menu, page, option etc
2) Push on the "Home" button 
3) Open another app with a loading process
4) While the second app is running return to the first app

Actual Result:
The first application stops the running process and doing an initial start

Expected Result:
The application resumes

Environmental  Variables:
Build ID: 20130605070207
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/09dc1ae3b1b5
Gaia: 92a6e36957145cdb2ac8867e5cdba8ecf12308fc
Platform Version: 18.0

Notes:
check the video attachment

Updated

6 years ago
Flags: needinfo?(nhirata.bugzilla)
sarsenyev, it's the same issue I believe.  Thanks for asking the question.

Etienne, maybe an UI for user preference to set certain activities from certain apps higher in priority queue so it doesn't get killed unexpectedly?  Would that be a better item?  Asking for koi? or later.  I don't expect this to be in leo, though it would be a pleasant surprise if does go in by then.
blocking-b2g: --- → koi?
Flags: needinfo?(nhirata.bugzilla) → needinfo?(etienne)
Summary: Processes/Apps that are running in the background should not get killed → Processes/Apps that are running in the background should not get killed; Allow for user priority for certain apps.
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #5)
> sarsenyev, it's the same issue I believe.  Thanks for asking the question.
> 
> Etienne, maybe an UI for user preference to set certain activities from
> certain apps higher in priority queue so it doesn't get killed unexpectedly?
> Would that be a better item?  Asking for koi? or later.  I don't expect this
> to be in leo, though it would be a pleasant surprise if does go in by then.

Justin will know better what we can/can't do.

(FWIW, as a user, having to manage this kind of preference sounds cumbersome...)
Flags: needinfo?(etienne) → needinfo?(justin.lebar+bug)
(In reply to Brion Vibber from comment #1)
> There should possibly be some way for apps to distinguish between "I just
> happen to be in the background doing nothing, go ahead and close me out if
> memory gets low" and "I'm actually doing something the user wants, don't
> close me if you can avoid it".

We already have a set of priorities which we use for deciding which applications to kill. These priorities are set automatically depending on what the application is doing; background apps playing sounds get automatically a better treatment than regular background apps for example, foreground apps doing something important (e.g. dialer receiving a call) are preferred over regular foreground apps.

Currently when we're running out of memory background apps will be killed first, followed by the homescreen and then what we call perceivable background apps which include any application playing sounds (music, radio, etc...). Next we'll kill foreground apps and finally critical foreground apps (i.e. an applications holding the CPU wakelock). This includes the dialer receiving a call, the communications app receiving an SMS and so on.

Somewhere in the middle (before killing the homescreen) we send a memory-pressure message to all apps in the hope of reclaiming memory before killing further ones. This kinda works but not always (I tried a minimal improvement in bug 877222).

(In reply to Etienne Segonzac (:etienne) from comment #6)
> Justin will know better what we can/can't do.

I've took the liberty of responding in Justin's place because we worked on this together (though he did most of the heavy lifting, I only added very small bits here and there).

> (FWIW, as a user, having to manage this kind of preference sounds
> cumbersome...)

Definitely and it could also cause serious problems. If the user prioritize the wrong app too much he can render the phone unusable. Besides a poorly behaved app can already do this if it really wants to (e.g. by continuously playing a silent sound to raise its priority over other background apps).
Flags: needinfo?(justin.lebar+bug)
+1 to everything gsvelto said.  Adding a UI to manage app priorities sounds like a very bad idea.

Playing audio in the bg should work just fine now.  FB import will probably get killed in the bg, however.

I've been thinking that maybe apps which hold the CPU wake lock should get the same priority as apps which are playing music.  I've been holding off doing this because we have no controls around the CPU wake lock -- that is, any app can hold the CPU wake lock for as long as it likes.  So I'm afraid that apps which don't want to be killed might hold the CPU wake lock even though they don't actually need it, and that would be quite bad.

No good answers here, unfortunately.  Sorry.
Depends on: 887192
Seems to be a feature. Hence a minus for koi
blocking-b2g: koi? → -

Comment 10

a year ago
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.