W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2014

Re: [whatwg] Proposal: requestBackgroundProcessing()

From: David Young <dyoung@pobox.com>
Date: Thu, 20 Feb 2014 15:43:38 -0600
To: whatwg@lists.whatwg.org, "whatwg@whatwg.org" <whatwg@whatwg.org>
Message-ID: <20140220214338.GW770@pobox.com>
On Thu, Feb 20, 2014 at 03:25:56PM +0000, Ashley Gullen wrote:
> Users regularly switch tabs and probably don't expect that this hangs the
> game for everyone. To prevent multiplayer games commonly hanging, perhaps
> there could be a new API to request that a page can keep running at full
> capacity even in the background, such as
> window.requestBackgroundProcessing(). This could show a permission prompt
> like 'Do you want to allow this page to run in the background? Allow /
> Deny' to help protect against abuse.

Hi Ashley,

I have some concerns about this as a user of browsers.

I strongly prefer that when a tab is not displayed, it's
not running down my battery, causing a cooling fan to spin, making my
computer sluggish, or otherwise making a nuisance of itself.

I also dislike being forced into any dialog, such as Allow/Deny, with
the system.

I also strongly prefer not to be a part of the browser's or operating
system's CPU/RAM/power/bandwidth-arbitration loop, however, I will
accept granting or adjusting a share of some resource to some tab if the
trade-offs are fairly clear.  For example, I'm happy to let a tab draw
down the battery a little faster or to run the CPU a little hotter in
order for it to have more up-to-date information (most current weather
report, for example) when I revisit it: more energy in exchange for
lower average latency in the display.

If I grant a program a share of a resource, I would like to be able to
claw that share back at a later time.

I think that if I was going to make engineering suggestions, they would
be for the browser makers, not for you, Ashley.

Dave

-- 
David Young
dyoung@pobox.com    Urbana, IL    (217) 721-9981
Received on Thursday, 20 February 2014 21:44:06 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:16 UTC