W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: WebStorage feedback

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 10 Jun 2009 05:06:43 +0000 (UTC)
To: João Eiras <joaoe@opera.com>
Cc: Anne van Kesteren <annevk@opera.com>, Olli Pettay <Olli.Pettay@helsinki.fi>, Jonas Sicking <jonas@sicking.cc>, Adam Barth <w3c@adambarth.com>, WebApps WG <public-webapps@w3.org>
Message-ID: <Pine.LNX.4.62.0906100504220.1648@hixie.dreamhostps.com>
On Tue, 19 May 2009, João Eiras wrote:
> > 
> > How is this different from making two mutations per mutation event, or 
> > calling postMessage() twice for each invokation of the 'message' 
> > event, or loading two new iframes every time an iframe's 'load' event 
> > fires?
> It's quite different because in those cases, the events or actions are 
> all limited to one single runtime, which means all these actions are 
> queued. A sane user agent can share a part of its cpu time between all 
> the active runtimes, and keeping the other documents usable while one 
> fork bombs itself with events, being the leftover problem the amount of 
> memory needed.
> With storage events, the user agent must send events to unrelated 
> runtimes, which can escalate immensely, therefore filling all the other 
> runtimes' event queues with the superfluous events. If the user agent 
> has no protection against this, then the user will be forced to close 
> the whole browser, and not just the webpage that is misbehaving.

Even if we posit a system where there are unrelated runtimes that 
can communicate in this way, within each runtime the user agent 
can apply the same protections. Furthermore, since runtimes can now 
communicate anyway (e.g. using shared workers), I really don't see which 
this is an unusual problem.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 10 June 2009 05:07:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:54 UTC