- From: Ehsan Akhgari <ehsan@mozilla.com>
- Date: Tue, 1 Oct 2013 14:02:47 -0400
- To: Ian Hickson <ian@hixie.ch>
- Cc: whatwg <whatwg@lists.whatwg.org>, Boris Zbarsky <bzbarsky@mit.edu>
On Tue, Oct 1, 2013 at 1:45 PM, Ian Hickson <ian@hixie.ch> wrote: > On Tue, 1 Oct 2013, Boris Zbarsky wrote: > > On 10/1/13 12:58 PM, Ian Hickson wrote: > > > If the browser crashes, it's not going to be able to send messages > > > anyway > > > > This concept of "the browser"... > > > > The situation being considered here is that you have two web pages in > > two different OS-level processes that have a MessageChannel between > > them. One of the OS-level processes crashes (and hence obviously can't > > send any more messages, as you note). The other one would like to know > > that its counterparty is gone. How should it find out? That's the > > problem I think Ehsan is trying to solve. > > Crashing is non-conforming. Having features explicitly to handle the > non-conforming case is a bit weird. :-) > Well, I'm not talking about content intentionally crashing. Out of memory crashes are an example of the kind of crash which you can't really prevent. > How often are we really expecting one tab to be talking to another tab, > and then that tab crashes, and the author was able to prepare code to > handle that gracefully, in a production environment? > That is not the only use case. Another use case which is currently more interesting for us in Firefox OS is to know when the connection to another application such as the music player is dead because the other side suffered an OOM crash for example, so that we can update the UI letting the user know that the music is no longer playing. Cheers, -- Ehsan <http://ehsanakhgari.org/>
Received on Tuesday, 1 October 2013 18:03:54 UTC