This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 23327 - MessagePort should provide onstart/onclose event handlers
Summary: MessagePort should provide onstart/onclose event handlers
Status: RESOLVED WONTFIX
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-09-23 11:40 UTC by Gene Lian [:gene]
Modified: 2013-10-04 23:24 UTC (History)
7 users (show)

See Also:


Attachments

Description Gene Lian [:gene] 2013-09-23 11:40:14 UTC
Please refer to [1] for the motivation.

It could be necessary and useful for a message port to know if the message port on other end is started or closed, so that the message port can decide if it needs to start or stop posting/receiving messages.

For example, through the message port, an Music App can post its now-playing song info to the Lock Screen App and show it on the screen. However, the Lock Screen App still needs a dynamic way to know if the message port on the Music App side is still alive or not (message port can be dead when the Music App is killed). Otherwise, the Lock Screen App would misunderstand the message port on the Music App stops posting, but it is actually dead, thus failing to turn off the now-playing song info.

We hope to add onstart/onclose event handlers in addition to onmessage, which will be triggered when:

1. the message port on the other end explicitly calls start()/close() or
2. the message port is killed and the system will be in chage of firing onstart/onclose events.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=915880
Comment 1 Gene Lian [:gene] 2013-09-23 11:48:31 UTC
This is my first time firing bugs here. Please correct me if the components, assignee or anything are wrong. Thanks!
Comment 2 Anne 2013-09-23 14:03:54 UTC
This is not a DOM bug, but an HTML bug. However, it's WONTFIX as far as I know because we don't want to make garbage collection observable.
Comment 3 Olli Pettay 2013-09-23 14:24:36 UTC
Indeed. Silly me, didn't think about GC behavior in
in https://bugzilla.mozilla.org/show_bug.cgi?id=915880
Comment 4 Gene Lian [:gene] 2013-09-24 06:55:22 UTC
(In reply to Anne from comment #2)
> This is not a DOM bug, but an HTML bug. However, it's WONTFIX as far as I
> know because we don't want to make garbage collection observable.

Sorry I don't get it. Could you please elaborate more about "garbage collection observable"?
Comment 5 Ehsan Akhgari [:ehsan] 2013-10-01 15:38:41 UTC
I posted about this to the whatwg list.
Comment 6 Ian 'Hixie' Hickson 2013-10-04 21:54:16 UTC
(In reply to Gene Lian [:gene] from comment #4)
> 
> Sorry I don't get it. Could you please elaborate more about "garbage
> collection observable"?

Garbage collection: https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)

Different browsers have different algorithms, and we don't want to expose the specifics of those algorithms, since once a page relies on a particular behaviour, it'd constrain all future innovation in this space.


(In reply to Ehsan Akhgari [:ehsan] from comment #5)
> I posted about this to the whatwg list.

Please either file bugs or send feedback to the list, but not both. It gets very confusing when we are talking about things in both places. I'm going to close this bug since there's outstanding feedback on the topic on the list.
Comment 7 Olli Pettay 2013-10-04 23:24:13 UTC
(In reply to Ian 'Hixie' Hickson from comment #6)
> Different browsers have different algorithms, and we don't want to expose
> the specifics of those algorithms, since once a page relies on a particular
> behaviour, it'd constrain all future innovation in this space.
(Which is why PortCollection should be removed from the spec until some
better API is designed. bug 23412)