Re: Support for non-persistent background pages

[Kris Maglione]

On Tue, Sep 06, 2016 at 02:19:07PM -0700, Andrew Swan wrote:
>> On Sun, Sep 4, 2016 at 11:50 AM, <st3...@gmail.com> wrote:
>>>In the webextensions API documentation, it says:
>>>
>>>"Firefox does not support the "persistent" property. Background scripts
>>>stay loaded all the time."
>>>
>>>is this going to be fixed at some point, or is this a permanent, never
>>>going to be supported type thing?
>
>I think it would be useful to do at some point, but we have no concrete
>plans to work on it any time in the near future.

I'm not sure it would. There's a good chance that it would hurt
performance more often than it would improve it, so there's not
much point in putting any effort toward supporting them until we
have good data to suggest they would be useful.

It's also fairly likely that background pages will be phased out
in favor of service workers in the not-too-distant future, which
means that any possible benefit would be short-lived at best.

[Kris Maglione]

On Tue, Sep 06, 2016 at 02:32:17PM -0700, Andrew Swan wrote:

>On Tue, Sep 6, 2016 at 2:24 PM, Kris Maglione <kmag...@mozilla.com> wrote:
>>I'm not sure it would. There's a good chance that it would hurt
>>performance more often than it would improve it, so there's not much point
>>in putting any effort toward supporting them until we have good data to
>>suggest they would be useful.
>

>This is mostly academic at this point, but can you elaborate on the
>assertion that it would hurt more often that it would help? I believe it
>is up to the browser to choose the policy for when to unload an idle page.
>I can see that a poorly designed policy could be harmful, but it is a
>tautology that "if we don't implement this well, it won't work well".

I'm not assuming that it will hurt performance, I'm just not
assuming that it will help it either. Destroying the background
page when it's idle might save a very small amount of memory,
but it would also add latency every time an event needed to be
dispatched, generate a lot of garbage, and reduce the risk of
certain kinds of leaks.

The memory savings go up if each extension runs in its own
process, and we destroy the process when we destroy the last
context that belongs to it. But the latency and resource
allocation/deallocation overhead also go up.

As for whether it's up to the browser to choose how to handle
it, well, there's no spec to follow, so that's more or less the
case. Chrome destroys its event pages every 15 seconds, and
documents it. If we choose to do something different, we're back
to where we started: we need data to give us some idea of
if/when/how it makes sense before we start seriously thinking
about implementing it.

[Andrew Swan]