Closed Bug 999563 Opened 6 years ago Closed 6 years ago

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

Categories

(Firefox OS Graveyard :: Runtime, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(b2g-v1.3T affected)

RESOLVED DUPLICATE of bug 997924
Tracking Status
b2g-v1.3T --- affected

People

(Reporter: gsvelto, Unassigned)

References

Details

+++ 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
Looks like a dupe of bug 997924.
Could be, I'll check if the patch there helps with this. Interestingly I haven't encountered this problem on v1.3t.
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.
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.
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.
(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)
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?
(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.
OK, I've just verified that the fix for bug 997924 fixed this too so closing as a duplicate.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 997924
You need to log in before you can comment on or make changes to this bug.