999563 - When turning the screen off the foreground application is not sent to the background by the ProcessPriorityManager

Status: RESOLVED DUPLICATE of bug 997924

(Firefox OS Graveyard :: Runtime, defect)

Description

[Gabriele Svelto [:gsvelto]]

+++ This bug was initially created as a clone of Bug #990003 +++

I've run into this while inspecting a related issue. Apparently since bug 990003 has landed the ProcessPriorityManager considers the current foreground application to be still in the foreground when we turn the screen off. The previous behavior was to demote the foreground application to the background whenever the screen was turned off.

I think that the presence of the callscreen app is confusing this loop into returning the wrong value but I still have to check:

http://hg.mozilla.org/mozilla-central/file/1d0496e30feb/dom/ipc/ProcessPriorityManager.cpp#l930

Comment 1

[Anthony Ricaud (:rik)]

Looks like a dupe of bug 997924.

Comment 2

[Gabriele Svelto [:gsvelto]]

Could be, I'll check if the patch there helps with this. Interestingly I haven't encountered this problem on v1.3t.

Comment 3

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

It's nothing to do with ProcessPriorityManager.

We had a hack to enable normal channel music to play when device is off / lockscreen is on:
If there's a sound playing we think it's a foreground app playing the sound so we did a hack in gaia not sending the current app to foreground(setVisible(false)) in this case. Preload the callscreen in system app makes a sound without stopping it when device is booted, so system thinks there's always music playing. This is something com back to bite us.

Comment 4

[Cervantes Yu [:cyu] [:cervantes]]

This sounds like a feature that we want on tarako :). Otherwise the user could lose the unsaved text message when the screen times out and turns off.

Comment 5

[Cervantes Yu [:cyu] [:cervantes]]

Or we should fix the lock screen bug and then implement the logic to prevent the app from being killed when the lock screen is on.

Comment 6

[Etienne Segonzac (:etienne)]

(In reply to Alive Kuo [:alive][NEEDINFO!][God bless Taiwan.] from comment #3)
> It's nothing to do with ProcessPriorityManager.
> 
> We had a hack to enable normal channel music to play when device is off /
> lockscreen is on:
> If there's a sound playing we think it's a foreground app playing the sound
> so we did a hack in gaia not sending the current app to
> foreground(setVisible(false)) in this case. Preload the callscreen in system
> app makes a sound without stopping it when device is booted, so system
> thinks there's always music playing. This is something com back to bite us.

Yeah I think this is a dup of bug 997924 (which will land today)

Comment 7

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

I am confused.  For Tarako, do we want the app in the foreground in the lockscreen because the LMK may end up killing the app if it goes to the background, I think?  Or does having the app run in the foreground with the lockscreen on cause issues such as battery life draining faster?

Comment 8

[Gabriele Svelto [:gsvelto]]

(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #7)
> I am confused.  For Tarako, do we want the app in the foreground in the
> lockscreen because the LMK may end up killing the app if it goes to the
> background, I think?  Or does having the app run in the foreground with the
> lockscreen on cause issues such as battery life draining faster?

We always want the foreground app to be sent to the background, at least from a visibility POV, because app code usually depends on that information to decide when to stop playing audio, pause in case of a game, etc... I have to verify if this is still the case now that bug 997924 has been fixed.

Comment 9

[Gabriele Svelto [:gsvelto]]

OK, I've just verified that the fix for bug 997924 fixed this too so closing as a duplicate.