Justin Lebar (not reading bugmail) Assignee
	Description • 11 years ago

Right now frames that are expecting system messages get vanilla BACKGROUND priority.  This means that those processes can be killed by the app you're currently using (FOREGROUND priority).  But it also means those processes can be killed by any other BACKGROUND process.  That's probably not what we want.

It would make sense to me to introduce a new priority between BACKGROUND and BACKGROUND_PERCEIVABLE, and give frames expecting system messages that new priority.  Maybe instead we give these frames BG_PERRCEIVABLE priority, but then I'm afraid that receiving an SMS will kill your music player; that may or may not be what we want.

	Justin Lebar (not reading bugmail) Assignee
	Comment 1 • 11 years ago

See also the discussion in bug 859743 comment 11 and onwards.

	Beatriz Rodríguez [:brg]
	Comment 3 • 11 years ago

Adding dependency to certification

	Justin Lebar (not reading bugmail) Assignee
	Comment 4 • 11 years ago

Daniel, could you help me understand what is the requirement here?

With our current architecture, we have to place the SMS app somewhere in an explicit hierarchy of processes.  If we place it too low in the hierarchy, the SMS app will get killed due to OOM.  If on the other hand we place it too high in the hierarchy, the SMS app will OOM other apps.

Do you guys consider receiving an SMS app to be a high-priority event, such that we should kill the foreground-most process if necessary?  Or, if we should never kill the foreground app, should we kill the music player to deliver your SMS?

	Daniel Coloma:dcoloma
	Comment 5 • 11 years ago

(In reply to Justin Lebar [:jlebar] from comment #4)
> Daniel, could you help me understand what is the requirement here?
> 
> With our current architecture, we have to place the SMS app somewhere in an
> explicit hierarchy of processes.  If we place it too low in the hierarchy,
> the SMS app will get killed due to OOM.  If on the other hand we place it
> too high in the hierarchy, the SMS app will OOM other apps.
> 
> Do you guys consider receiving an SMS app to be a high-priority event, such
> that we should kill the foreground-most process if necessary? 

No, I don't think we should do this.

> Or, if we should never kill the foreground app, should we kill the music player to
> deliver your SMS?

Yes, I think letting user know the SMS has arrived has higher priority than a music player in background

	Johnny Stenback (:jst)
	Comment 6 • 11 years ago

Justin, over to you. If you don't have time to finish this work this week, please let me know.

	Kai-Chih Hu [:khu]
	Comment 7 • 11 years ago

Justin, do you think it's possible to solve it and close it before April 24th? It looks like we need some discussions and it does not look like a bug that we can fix before that date. Please tell us if you see something different. Thanks.

	Justin Lebar (not reading bugmail) Assignee
	Comment 8 • 11 years ago

This is unlikely to be fixed by April 24.

	Kai-Chih Hu [:khu]
	Comment 9 • 11 years ago

Reviewed on April 23th: 
    Need to be fixed for certification. 
    Need QA to be involved in the testing. 
    Agreed to have this fixed before the 3rd certification.

	David Palomino [:dpalomino]
	Comment 10 • 11 years ago

marking qawanted for verification.

	Jason Smith [:jsmith]
	Comment 11 • 11 years ago

Based on what I'm reading on this bug, there's nothing to be tested here yet. When testing comes available and requires QA involvement, feel free to flag down again.

	Justin Lebar (not reading bugmail) Assignee
	Comment 14 • 11 years ago

Now with less enable logging.

	Justin Lebar (not reading bugmail) Assignee
	Comment 15 • 11 years ago

This isn't totally right, in the following way:

What we want is that if frame X is not visible, frame X has expecting-system-message, and frame X has acquired the CPU or high-priority wake lock, then the process containing frame X gets priority BACKGROUND_PERCEIVABLE.

But what we actually do is, if process Y has no frames that are visible, Y has at least one frame with expecting-system-message, and Y has acquired either of the wake locks, then Y gets priority BACKGROUND_PERCEIVABLE.

The problem is that we don't tie a wake lock to a frame.  This is actually a hard thing to fix, because we have this notion of acquiring a wake lock on behalf of a process /before any frames have been created/, and that's what we use when a frame is expecting a system message.

Anyway I don't think this is a big deal.  The worst thing that happens is that a frame gets bumped up to BG_PERCEIVABLE, and a frame can already do that by playing a silent ogg.

	Justin Lebar (not reading bugmail) Assignee
	Comment 16 • 11 years ago

This needs a Gaia patch too.  I've had bad experiences trying to patch Gecko and Gaia in the same bug, so I'll do that separately.

	Kai-Chih Hu [:khu]
	Comment 17 • 11 years ago

The OEM will need around 5 days to prepare the build and do the verification. It means, we need to fix it by May 21th. Justin, do you think it's possible? Thanks.

	Kai-Chih Hu [:khu]
	Comment 18 • 11 years ago

(In reply to Justin Lebar [:jlebar] from comment #16)
> This needs a Gaia patch too.  I've had bad experiences trying to patch Gecko
> and Gaia in the same bug, so I'll do that separately.

Thanks! In this case, would you mind creating another bug for Gaia patch?

	Justin Lebar (not reading bugmail) Assignee
	Comment 19 • 11 years ago

(In reply to khu from comment #18)
> Thanks! In this case, would you mind creating another bug for Gaia patch?

 Justin Lebar [:jlebar] 9 hours ago
Blocks: 865429

	Justin Lebar (not reading bugmail) Assignee
	Comment 20 • 11 years ago

https://hg.mozilla.org/projects/birch/rev/e2ab897e0241
https://hg.mozilla.org/projects/birch/rev/7b93ed92f8fe

	Ryan VanderMeulen [:RyanVM]
	Comment 21 • 11 years ago

https://hg.mozilla.org/mozilla-central/rev/911d21581db4
https://hg.mozilla.org/mozilla-central/rev/1f675d6e1783

	Justin Lebar (not reading bugmail) Assignee
	Comment 22 • 11 years ago

https://hg.mozilla.org/releases/mozilla-b2g18/rev/9013e26f8e16
https://hg.mozilla.org/releases/mozilla-b2g18/rev/ddaa604aecb0

	Justin Lebar (not reading bugmail) Assignee
	Comment 23 • 11 years ago

https://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/3455133aa36f
https://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/41a0854fe988