On Thu, Jan 30, 2014 at 11:41 AM, Ian Hickson i...@hixie.ch wrote:
On Fri, 13 Dec 2013, Jonas Sicking wrote:
On Fri, Dec 13, 2013 at 3:29 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 11 Dec 2013, Jonas Sicking wrote:
No sync IPC needed. When a port is pinned, you send an async message
to
On Mon, 3 Feb 2014, Jonas Sicking wrote:
I agree that being able to prevent an object from getting GCed isn't
great, however any solution in this space is going to require the UA to
retain a bit more memory. The reason that we need to retain the
MessagePort object in the solutions
On Fri, 13 Dec 2013, Jonas Sicking wrote:
On Fri, Dec 13, 2013 at 3:29 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 11 Dec 2013, Jonas Sicking wrote:
No sync IPC needed. When a port is pinned, you send an async message
to the process which contains the page for the other side. When
that
On Wed, 11 Dec 2013, Jonas Sicking wrote:
On Wed, Dec 11, 2013 at 3:54 PM, Ian Hickson i...@hixie.ch wrote:
I really don't understand why we'd want that level of complexity for
something that we can solve with just a single event handler, though.
The problem, as described, is just we need
On Wed, Dec 11, 2013 at 4:54 PM, Jonas Sicking jo...@sicking.cc wrote:
The proposal at [1] does not prevent bfcaching *anytime* that
MessagePorts are alive in a page that is navigated away from. We can
always bfcache the page if we don't know of any other sides having
pinned their port. If we
On Tue, 10 Dec 2013, Ehsan Akhgari wrote:
On Fri, Dec 6, 2013 at 8:22 PM, Ian Hickson i...@hixie.ch wrote:
It doesn't fire when a port's owner document is navigated away from,
because that would prevent the page from being bfcached, which we try
hard to avoid. For pages it's reasonably
On Wed, 11 Dec 2013, Ian Hickson wrote:
So my proposal to handle this would be to send another 'error' event,
basically any time you create a MessagePort that's entangled with
someone who has crashed already.
I've put this in the spec for now.
--
Ian Hickson U+1047E
On Wed, Dec 11, 2013 at 11:18 AM, Ian Hickson i...@hixie.ch wrote:
and given the fact that currently a solution for the case where the page
is navigated away from will need to register an unload event handler
(which also disables bfcache) we will be in no worse spot than we are
today.
For
On Wed, 11 Dec 2013, Ehsan Akhgari wrote:
Right, but isn't that considered a problem?
Sure, but please remember that bfcache is a (Gecko specific, last I
checked) optimization and where that optimization doesn't work, we just
fall into the regular behavior of every web browser.
It's
On Wed, 11 Dec 2013, Jonas Sicking wrote:
The proposal at [1] would indeed cause pages that hold a MessagePort
to not be bfcached if the other side pin its port.
This seems to me to require sync IPC during navigation, which is a
non-starter.
The proposal at [1] does not prevent bfcaching
On Wed, Dec 11, 2013 at 3:54 PM, Ian Hickson i...@hixie.ch wrote:
I really don't understand why we'd want that level of complexity for
something that we can solve with just a single event handler, though. The
problem, as described, is just we need to know when a remote port is
killed due to an
On Sat, 7 Dec 2013, Andrew Wilson wrote:
Here's my point - let's say you have two UA implementations, one that
GCs aggressively when two ports are not reachable and are idle, and one
that never GCs entangled ports.
Two documents (A and B) are connected via entangled ports, but the ports
On Sat, Dec 7, 2013 at 2:22 AM, Ian Hickson i...@hixie.ch wrote:
On Fri, 11 Oct 2013, Andrew Wilson wrote:
Interesting. Section 5.3.1 of the MessagePort spec
(BTW, I really recommend using the WHATWG HTML spec rather than the
MessagePort spec, especially the version on the TR/ page. The
On Tue, 1 Oct 2013, Ehsan Akhgari wrote:
On Tue, Oct 1, 2013 at 1:45 PM, Ian Hickson i...@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
On Tue, 29 Oct 2013, Ian Hickson wrote:
Consider these three scenarios:
A. Page Alpha opens a shared worker, and they communicate using a pair of
MessagePorts. Alpha is navigated away, going to Beta in a different
origin. Later, the user hits back, and since Alpha is still in the
On Oct 21, 2013 6:06 PM, Ehsan Akhgari eh...@mozilla.com wrote:
We could further define that channeldropped is fired when the owner
of the *other side* is navigated away from. This would mean that
events can be received even after a channeldropped event has been
fired since other windows could
On Oct 21, 2013 6:08 PM, Ehsan Akhgari eh...@mozilla.com wrote:
How does this work - imagine that I have a reference to a MessagePort,
but I'm not actively waiting for any response on the port so I don't have a
channeldropped event listener.
Now, the remote side of the port crashes. I send a
On Tue, Oct 22, 2013 at 11:36 AM, Jonas Sicking jo...@sicking.cc wrote:
On Oct 21, 2013 6:08 PM, Ehsan Akhgari eh...@mozilla.com wrote:
How does this work - imagine that I have a reference to a MessagePort,
but I'm not actively waiting for any response on the port so I don't have a
On Tue, Oct 22, 2013 at 9:31 AM, Ehsan Akhgari eh...@mozilla.com wrote:
interface MessagePort {
...
Promise pin();
void unpin(optional any value);
};
Rather than firing channeldropped we reject any promise returned from
pin(). Once the caller receives an expected answer he/she calls
On Tue, Oct 22, 2013 at 1:32 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Oct 22, 2013 at 9:31 AM, Ehsan Akhgari eh...@mozilla.com wrote:
interface MessagePort {
...
Promise pin();
void unpin(optional any value);
};
Rather than firing channeldropped we reject any promise
On Sat, Oct 19, 2013 at 2:26 AM, Jonas Sicking jo...@sicking.cc wrote:
What I think might work is to say that as long as a channeldropped
event listener is registered with a port, that is equivalent to
holding a strong reference to the port. I.e. that prevents the channel
from being GCed.
On Fri, Oct 18, 2013 at 8:26 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Oct 17, 2013 at 2:08 PM, Ehsan Akhgari eh...@mozilla.com wrote:
It occurs to me that all of the proposals here does expose some amount
of GC behavior. Even a channeldropped message which is sent only
when the
On Mon, Oct 21, 2013 at 3:19 AM, Andrew Wilson atwil...@google.com wrote:
On Sat, Oct 19, 2013 at 2:26 AM, Jonas Sicking jo...@sicking.cc wrote:
What I think might work is to say that as long as a channeldropped
event listener is registered with a port, that is equivalent to
holding a
On Thu, Oct 17, 2013 at 2:08 PM, Ehsan Akhgari eh...@mozilla.com wrote:
It occurs to me that all of the proposals here does expose some amount
of GC behavior. Even a channeldropped message which is sent only
when the other side crashes exposes GC behavior. If GC happens to run
before the crash
(Sorry for my late reply, this got tangled in my vacation email backlog...)
On Thu, Oct 10, 2013 at 5:52 PM, Jonas Sicking jo...@sicking.cc wrote:
The reason I did not extend this to navigation and Worker.terminate() is
that at least in theory the authors should be able to detect those in
On Thu, Oct 17, 2013 at 5:08 PM, Ehsan Akhgari eh...@mozilla.com wrote:
It occurs to me that all of the proposals here does expose some amount
of GC behavior. Even a channeldropped message which is sent only
when the other side crashes exposes GC behavior. If GC happens to run
before the
On Tue, Oct 15, 2013 at 5:23 AM, Simon Pieters sim...@opera.com wrote:
On Thu, 10 Oct 2013 17:22:32 +0200, Ehsan Akhgari eh...@mozilla.com
wrote:
Does navigation disentangle ports? I don't think it necessarily does, at
least per spec.
The current spec doesn't mention what happens in the
On Thu, 10 Oct 2013 17:22:32 +0200, Ehsan Akhgari eh...@mozilla.com
wrote:
Does navigation disentangle ports? I don't think it necessarily does, at
least per spec.
The current spec doesn't mention what happens in the case of navigation
in
the owner for a port as far as I can tell. But
On Thu, Oct 10, 2013 at 11:52 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Oct 10, 2013 at 8:26 AM, Ehsan Akhgari eh...@mozilla.com wrote:
On Thu, Oct 10, 2013 at 2:58 AM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Oct 9, 2013 at 3:06 PM, Ehsan Akhgari eh...@mozilla.com
wrote:
On Fri, Oct 11, 2013 at 9:38 AM, Andrew Wilson atwil...@google.com wrote:
*or while there exists an event listener on either port for the
channeldropped event.*
Once you do that you basically rely on the developer to handle GC and
you'll end up with memory leaks instead.
--
On Fri, Oct 11, 2013 at 10:18 AM, Anne van Kesteren ann...@annevk.nlwrote:
On Fri, Oct 11, 2013 at 9:38 AM, Andrew Wilson atwil...@google.com
wrote:
*or while there exists an event listener on either port for the
channeldropped event.*
Once you do that you basically rely on the developer
On Wed, Oct 9, 2013 at 3:06 PM, Ehsan Akhgari eh...@mozilla.com wrote:
OK, so I gave this some thought and I and Olli managed to convince each
other that finding a solution to the problem of dispatching a generic
onclose event is impossible since there is no deterministic point in time
before
On Thu, Oct 10, 2013 at 8:58 AM, Jonas Sicking jo...@sicking.cc wrote:
I could see the GC case not being solvable.
But is there a reason that we couldn't also fire the event if the
other side is forcefully terminated through a navigation or a
Worker.terminate() call?
I still have the
On Thu, 10 Oct 2013 08:58:52 +0200, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Oct 9, 2013 at 3:06 PM, Ehsan Akhgari eh...@mozilla.com wrote:
OK, so I gave this some thought and I and Olli managed to convince each
other that finding a solution to the problem of dispatching a generic
onclose
On Thu, Oct 10, 2013 at 3:11 AM, Andrew Wilson atwil...@google.com wrote:
On Thu, Oct 10, 2013 at 8:58 AM, Jonas Sicking jo...@sicking.cc wrote:
I could see the GC case not being solvable.
But is there a reason that we couldn't also fire the event if the
other side is forcefully
On Thu, Oct 10, 2013 at 4:48 AM, Simon Pieters sim...@opera.com wrote:
On Thu, 10 Oct 2013 08:58:52 +0200, Jonas Sicking jo...@sicking.cc
wrote:
On Wed, Oct 9, 2013 at 3:06 PM, Ehsan Akhgari eh...@mozilla.com wrote:
OK, so I gave this some thought and I and Olli managed to convince each
On Thu, Oct 10, 2013 at 2:58 AM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Oct 9, 2013 at 3:06 PM, Ehsan Akhgari eh...@mozilla.com wrote:
OK, so I gave this some thought and I and Olli managed to convince each
other that finding a solution to the problem of dispatching a generic
This is a feature we've long wanted for Google Docs, but not for the most
obvious reason. We have a situation where more than one tab can be
visualizing the same document. Under those conditions, we have a
requirement that one of the documents hold a lock which entitles it to do
things with the
On Thu, Oct 10, 2013 at 5:20 PM, Ehsan Akhgari eh...@mozilla.com wrote:
Why would they expect that? Storing a reference to a port object on a
parent doesn't change the owner of the port. (I agree that this can be a
bit confusing if authors are not familiar with MessagePorts, but this is
On 10/10/13 11:43 AM, David Barrett-Kahn wrote:
Why is revealing when garbage collection happens such a terrible thing
anyway?
Because web pages can then start depending on GC timing, limiting the
kinds of GC optimizations browsers can do.
-Boris
On GC being a source of cross-browser difficulty: I think you can fix that
by stating in the messageport spec when we guarantee to implicitly close
the connection (when its host page closes) and when we provide no
guarantees (when it loses all its references).
On people relying on GC timing:
On 10/10/13 18:14, David Barrett-Kahn wrote:
On GC being a source of cross-browser difficulty: I think you can fix that
by stating in the messageport spec when we guarantee to implicitly close
the connection (when its host page closes) and when we provide no
guarantees (when it loses all its
On Thu, Oct 10, 2013 at 8:26 AM, Ehsan Akhgari eh...@mozilla.com wrote:
On Thu, Oct 10, 2013 at 2:58 AM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Oct 9, 2013 at 3:06 PM, Ehsan Akhgari eh...@mozilla.com wrote:
OK, so I gave this some thought and I and Olli managed to convince each
other
OK, so I gave this some thought and I and Olli managed to convince each
other that finding a solution to the problem of dispatching a generic
onclose event is impossible since there is no deterministic point in time
before a worker is GCed when we know that it will be GCed soon.
So with that
On Tue, Oct 1, 2013 at 11:13 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/1/13 2:11 PM, Ian Hickson wrote:
How often do we expect two tabs to be talking to each other though?
Or a page to an out-of-process subframe?
How often do we expect MessageChannel to be used at all?
Speaking as
On Tue, Oct 1, 2013 at 7:01 PM, Olli Pettay olli.pet...@helsinki.fi wrote:
I don't understand what the lifetime of MessagePorts to the lifetime of
their owner document
means in case of workers. And we sure want to delete MessagePort objects
if nothing from JS side
is keeping it, or the port
Hi guys,
Not really be able to follow all the details and technical terms. However, I'd
also highly agree it's worth adding an onclose event to imply the aliveness of
the owner (on the other end).
We can imagine in the future MessagePort will be a very generic structure
utilised in lots of
Hi everyone,
We're coming across a need to get notified when the other side of a channel
goes away because the user navigates away from the page, or if the page is
killed by the OS, etc. Currently a workaround is for the application to
handle the unload event and send a message on its channel
On Tue, 1 Oct 2013, Ehsan Akhgari wrote:
We're coming across a need to get notified when the other side of a
channel goes away because the user navigates away from the page, or if
the page is killed by the OS, etc.
What is that need? Can you elaborate?
Currently a workaround is for the
On 10/01/2013 06:37 PM, Ehsan Akhgari wrote:
Hi everyone,
We're coming across a need to get notified when the other side of a channel
goes away because the user navigates away from the page, or if the page is
killed by the OS, etc. Currently a workaround is for the application to
handle the
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.
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
On Tue, Oct 1, 2013 at 8:45 PM, Ian Hickson i...@hixie.ch wrote:
Crashing is non-conforming.
rules-lawyer
href=http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#conformance-requirements;
Terminating the process with SIGSEGV if a page exceeds an
On Tue, Oct 1, 2013 at 1:45 PM, Ian Hickson i...@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
On 10/1/13 1:45 PM, Ian Hickson wrote:
Crashing is non-conforming.
That's not useful. Crashing (or rather being killed by the OS) happens
all the time on tablets and phones. You get killed for using too much
memory, for not being active while other stuff is using too much memory,
for just
On Tue, 1 Oct 2013, Boris Zbarsky wrote:
On 10/1/13 1:45 PM, Ian Hickson wrote:
Crashing is non-conforming.
That's not useful.
Hence the smiley.
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
On 10/1/13 2:11 PM, Ian Hickson wrote:
How often do we expect two tabs to be talking to each other though?
Or a page to an out-of-process subframe?
How often do we expect MessageChannel to be used at all?
Is that even possible on phone browsers?
Sure is in Firefox and FirefoxOS.
Anyway,
On Tue, Oct 1, 2013 at 11:13 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/1/13 2:11 PM, Ian Hickson wrote:
How often do we expect two tabs to be talking to each other though?
Or a page to an out-of-process subframe?
Or an out-of-process worker. I would think that in Chrome
SharedWorkers
58 matches
Mail list logo
