[whatwg] Low Memory Event

[Tran, Dzung D]

You should try to work this type of requests through the W3C DAP WG. They are working on similar APIs. For example the System Info API at: http://dev.w3.org/2009/dap/system-info/

Regards,
Dzung Tran

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Charles Pritchard
Sent: Tuesday, September 28, 2010 3:53 PM
To: timeless
Cc: Rob Evans; whatwg at lists.whatwg.org
Subject: Re: [whatwg] Low Memory Event

On 9/28/10 1:35 AM, timeless wrote:
> On 9/28/10, Rob Evans<rob at mtn-i.com>  wrote:
>    
>> All good points. I think as we have moved away from simple web pages and
>> really start to think about applications that are coded in js, many things
>> previously the exclusive domain of desktop apps are more and more desirable
>> for web apps.
>>      
> Unfortunately, moving away from simple pages introduces pain points
> previously only experienced in desktop applications. Browser design
> should aim to avoid exposing such pain points.
>    
Complex apps necessarily introduce additional work.

What we're seeing, is that desktop application developers are now able 
to use "web" APIs.
>> I also think that a web page should be able to request exclusive access to
>> the graphics card just like many native games do,
>>      
Many vendors are working hard to support WebGL. I don't think "exclusive 
access" makes any sense,
but I'm not an expert. I recommend you review Google's work in the area, 
as they're supporting
GL through various entry points (Native Client, WebGL, and their 
OpenGL+DirectX layer).

I don't think that this issue has much to do with my proposal.
> Only an application knows what should be done when backgrounded. But
> some forms of backgrounding shouldn't really be exposed to apps. I
> don't want an interstitial page to recognize that I'm ignoring it --
> sadly, the future is in this direction, interactive ads which block
> content views until they're dismissed.
>    
window.onblur and window.onfocus already expose some of this.
Yes, the interactive ads now on YouTube and other services are quite 
annoying,
and I'm sure the market will respond accordingly. But that's not a 
standards nor security issue.
> It'd be nice to know if Safari on iOS3 sends events to pages when the
> user switches "away" and "back", I've assumed it just saves a picture
> and reloads the page.
>    
Safari task switching on iOS manages tabs by task switching, or reloading.
I don't know if it fires onfocus/onblur, but I'm sure it has some events.

WebApp developers targeting iOS may be running as an application using a 
web frame.
The same is true for Android devs. They are always free to inject events 
into their web frame;
was commonly done for events like "onorientationchange".
> Imagine a user loads 2 html-canvas3d games. Imagine that the system
> doesn't have much memory and that the user is paying for bandwidth
> (I'm in .ie w/ .uk and .fi sims -- I'm roaming, it's expensive). Is
> the user going to be happy with you trying to store your inactive game
> in DOM/JS (which causes swapping) and then with you trying to use the
> network as a storage? The right thing to do is to recognize your FPS
>    
This sounds like something the game designer would put in their 
settings. Just as
they currently do when allowing users to change resolution, depth, 
lighting, and so forth.
> unreliable/unusable for non browser applications (Maemo 5). At least
> on Maemo 5 the low memory events (which were at least sort of used in
> Maemo 4) are effectively never delivered. The system has 256mb of ram
> (128mb is vaguely available to apps) and 764mb of swap (which prevents
> low memory signals from being fired until after the system swaps to
>
>    
I realize that low memory events may not be reliably received. We have 
functioning
examples, however, of current browsers responding to low memory events. 
So it can happen.

A programmer should not expect that they will reliably receive low 
memory events.
The purpose is simply to expose them in cases they may happen in. Right 
now, I hit low
memory issues in Chrome and Firefox, frequently. I'd like to throw in a 
little extra code
to deal with that process.

Aza Raskin has put forward a great proof of concept of a web browser 
running dozens
of tabs in a manageable UI.  Whether a resource constrained system, or a 
system that's
just running a hundred different processes, allowing hooks for 
"onsuspend" "onlowmemory",
may mean that WebApp developers will support those conditions.

In the meantime, devs do code for those events, in non-standard ways, 
through tool kits like Phonegap
> guy determine where the risk point is. Typically what has happened for
> perhaps 20 or more years in desktop/web applications is that low
> memory conditions lead to "code execution vulnerabilities".
>    
Chrome does a graceful crash of some running processes and not others. 
It would
not introduce an attack vector to notify those still-running processes 
with a dispatched event.

> Anyway, for now, instead of pleading, please try working with what you
> have. Once webworkers, taskmanagers, resource monitoring is exposed to
> users, we can look into what should be exposed to apps. Please
> remember that "the editor" will address threads eventually, but that
> only new input (use cases, experience) is valuable.
>    

Didn't realize it was pleading. I intended to have a conversation about 
a proposal,
and whether the scope of that proposal should be extended.

As usual, in this mailing list, I'm sharing some of the demands and 
experiences of my job,
hoping that others will discuss theirs with me, and that browser vendors 
consider how those
use cases might be addressed in future versions.

Most of the browsers nowadays are open source; there's no need for pleading,
they have open processes to submit code patches for review.

-Charles