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 <[email protected]> has been tackling some issues here recently. On Tue, 28 Nov 2023 at 12:31, Nonoka Muraki <[email protected]> wrote: > Contact emails > > [email protected], [email protected], [email protected] > > Explainer > > https://github.com/fergald/explainer-messageport-close > <https://github.com/fergald/explainer-messageport-close#exposing-that-cross-origin-navigation-has-occurred> > > 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 <https://bugs.chromium.org/p/chromium/issues/list?q=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 <https://chromestatus.com/features#tags:close>, onclose > <https://chromestatus.com/features#tags: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 > <https://github.com/whatwg/html/issues/1766>. > > WebKit: No response ( > https://github.com/WebKit/standards-positions/issues/271) > > WebKit people are already involved in the initial Github issue > <https://github.com/whatwg/html/issues/1766>. > > 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 > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> > ? > > 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 > <https://chromestatus.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 [email protected]. > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA66OT2mWU9WJnkVzD2gm_%2Bk%2Bewag5Lhq_K39Vo9WGdtGW79cQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. 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.
