Intent to Prototype and Ship: MessagePort.onclose

[Nonoka Muraki]

Contact emails

muraki...@chromium.org, my...@chromium.org, rak...@chromium.org

Explainer

https://github.com/fergald/explainer-messageport-close

Specification

https://github.com/whatwg/html/pull/9933

Design docs

https://docs.google.com/document/d/1lXZU2Pk2ycitqj8aL9kxT2aauwXqpA0vJDUalkXA29Y

Summary

Notifies one of the MessagePorts that the other port has been disentangled (i.e., close() is called, an owning document is destroyed, or the port is garbage collected).

Blink component

Blink

Motivation

Channel Messaging API enables two separate scripts running in different browsing contexts to communicate directly. Once MessageChannel is created, we can access two entangled  MessagePorts (MessageChannel.port1 and MessageChannel.port2), transfer port2 to the other browsing context, allowing these two scripts to post and receive messages. 

The problem with this API is that there is currently no timely and reliable way to detect when a MessagePort becomes disentangled. This makes it difficult to release resources associated with ports. Some users have used the unload event to detect disconnection, but it is unreliable especially on mobile. Therefore, the approach available now is to hold a MessagePort in WeakRef and periodically check if this port has been garbage collected by using deref() or to make use of the pagehide event. However, this event is also not an effective solution. The reasons are as follows:

1) It doesn't work when the document crashes.

2) The port must cooperate in signaling the port is going to be disentangled.(i.e., the port must post the message which is "it is going to be closed" to the entangled port.)

3) It fires even if the page is not being destroyed and just enters BFCache.

Adding a close event helps to detect timely and reliably that MessagePort is disentangled and make it easier to release resources associated with ports.

Initial public proposal

https://github.com/whatwg/html/issues/1766#issuecomment-1708027883

Search tags

close, onclose

TAG review

Not needed because This is a small feature where we just dispatch a new event.

Risks

Interoperability and Compatibility

None

Gecko:  Positive (https://github.com/mozilla/standards-positions/issues/914) 

Mozilla people are already involved in the initial Github issue.

WebKit: No response (https://github.com/WebKit/standards-positions/issues/271) 

WebKit people are already involved in the initial Github issue.

Web developers: Positive (https://github.com/whatwg/html/issues/1766) 

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

None

Is this feature fully tested by web-platform-tests?

Yes.

 https://chromium-review.googlesource.com/c/chromium/src/+/5003089

Flag name on chrome://flags

None

Finch feature name

None

Non-finch justification

This is a small feature (just dispatching a new event) that doesn’t need experimentation.

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1495616

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5086799659794432

This intent message was generated by Chrome Platform Status.

[Torne (Richard Coles)]

Android WebView exposes the ability to create and use MessagePorts to the host app through a Java API, and currently one of the limitations of this API is the lack of a signal about the channel being closed, which in some cases can lead to apps holding on to Java objects longer than intended.

So, I'm very happy to see this proposed for the web API side, as this should hopefully also enable us to support the same thing in WebView's Java API. +Peter Birk Pakkenberg has been tackling some issues here recently.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA66OT2mWU9WJnkVzD2gm_%2Bk%2Bewag5Lhq_K39Vo9WGdtGW79cQ%40mail.gmail.com.

[Yoav Weiss]

I ran into a Chromium-internal case where having a `close` signal would've helped me reduce complexity significantly. So I'm very excited about this work.

I also believe there's an equivalent mechanism in Electron. Might be worthwhile to get those folks involved and see if there are any learnings to be had.

Unfortunately that's not a criteria for skipping a TAG review. Can you file one?

 

Risks

Interoperability and Compatibility

None

Gecko:  Positive (https://github.com/mozilla/standards-positions/issues/914) 

There are definitely positive signals on that thread, but it's not yet labeled as "positive" AFAICT.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEV-rjcZL5YnizhWf0xA%3DBaSt4EmY32p1tjhYG%3DfEOP1B-Kk%2BQ%40mail.gmail.com.

[Yoav Weiss]

Also, can you tick the review boxes in your Chrome status entry to kick off security, privacy and other reviews?

[Fergal Daly]

I'm concerned by this because every TAG review I've seen in the last couple of years has taken months to get a response. If our own privacy review is positive and we have agreement with other vendors would we block on the TAG review?

F

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA66OT2mWU9WJnkVzD2gm_%2Bk%2Bewag5Lhq_K39Vo9WGdtGW79cQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Mike Taylor]

On 11/30/23 10:56 PM, Fergal Daly wrote:

On Wednesday, November 29, 2023 at 2:23:12 PM UTC+9 Yoav Weiss wrote:

On Tue, 28 Nov 2023 at 12:31, Nonoka Muraki <muraki...@chromium.org> wrote:
TAG review

Not needed because This is a small feature where we just dispatch a new event.

Unfortunately that's not a criteria for skipping a TAG review. Can you file one?

I'm concerned by this because every TAG review I've seen in the last couple of years has taken months to get a response. If our own privacy review is positive and we have agreement with other vendors would we block on the TAG review?

In practice, we don't block on TAG reviews, but we like to give them a chance to review or comment within a reasonable time period (typically a week or two).

[Mike Taylor]

Gentle reminder to request approvals for the other review gates in chromestatus, thanks.

[Alex Russell]

+1 to Yoav's excitement about this. Thank you for pushing it forward.

On TAG review, we're living in hope that the newly-expanded TAG will have more bandwidth and focus for reviews, but as Mike says, we're increasingly timing out. Filing for review at I2P time is always the pro-move, and I it's a bad look for us to be leaving it to late regardless.

Hoping that the design doc can become an GH explainer with the usual format, as the design doc doesn't answer questions in the strucutre we like to see:

https://w3ctag.org/explainers/

Best,

Alex

[Rakina Zata Amni]

> Hoping that the design doc can become an GH explainer with the usual format, as the design doc doesn't answer questions in the strucutre we like to see

Can you clarify which part isn't answered yet in the explainer? 

From the list in your link:

• The user-facing problem which needs to be solved;
  
• Covered by this section.
• The proposed approach to solving the problem;
  
• Covered by this section.
• The way the proposed solution may be used in practice to address the intended use cases, via example code;
  
• Pretty much covered by this section although there's no actual code example. We will add the code example (basically just an event listener using the close event)
• Any other venues (such as mailing list, pull requests or issue threads external to the location of the explainer) where the reader may catch up on discussions regarding the proposed feature or features;
  
• The issue is linked from the explainer.
• The alternatives which have already been considered and why they were not chosen;
  
• Covered by this section.
• Accessibility, security and privacy implications which have been considered as part of the design process.
  
• Security & Privacy is covered by this section, and there is no accessibility implication introduced by the new event.

Please let us know if there are any parts that need further clarification.

(BTW just to update the thread, the TAG review has been requested last month)

[Mike Taylor]

Thanks Rakina - right now the biggest blocker is the unlanded spec PR. Things should move pretty quickly once that's resolved.

[Nonoka Muraki]

spec PR was merged.(https://github.com/whatwg/html/pull/9933)

[Yoav Weiss (@Shopify)]

LGTM1

[Mike Taylor]

LGTM2

[Chris Harrelson]

LGTM3

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/28299184-c2d1-4000-be13-f7489a5a242b%40chromium.org.