Bug 193184 – MessagePort is unexpectedly GC'ed after activity absence

• Component: WebCore JavaScript
• Status: RESOLVED FIXED

[Yoshiaki Jitsukawa]

MessagePort is unexpectedly GC'ed after several GC if there'no activity around the MessagePort, though the MessagePort may be used afterwards.

[Yoshiaki Jitsukawa]

Created attachment 358473 [details]
Patch (test only)

[Yoshiaki Jitsukawa]

Attachment 358473 [details] is a test for reproduction.

The main frame generates two MessagePorts port1 and port2 from a MessageChannel. port2 is passed to the iframe and bound to a XMLHttpRequest.

 <main frame>
 port1

 <iframe>
 port2 <- xhr

XHR gets a response after one second and then let port2 post a message to port1. However port1 is GC'ed after three times GC and port1 cannot receive the message. (Running GC two times was OK.)

[Yoshiaki Jitsukawa]

I suspect this but not sure.
Bug 181910 - Make garbage collection of MessagePort objects be asynchronous

[EWS Watchlist]

Comment on attachment 358473 [details]
Patch (test only)

Attachment 358473 [details] did not pass ios-sim-ews (ios-simulator-wk2):
Output: https://webkit-queues.webkit.org/results/10653761

New failing tests:
http/tests/messaging/messageport-gc-after-xhr.html

[EWS Watchlist]

Created attachment 358477 [details]
Archive of layout-test-results from ews122 for ios-simulator-wk2

The attached test failures were seen while running run-webkit-tests on the ios-sim-ews.
Bot: ews122  Port: ios-simulator-wk2  Platform: Mac OS X 10.13.6

[Radar WebKit Bug Importer]

<rdar://problem/54095480>

[Alexey Proskuryakov]

*** Bug 247372 has been marked as a duplicate of this bug. ***

[Geoffrey Garen]

It looks like Bug 181910 was a partial implementation that, by design, allowed a MessagePort to be GC'd after receiving its first message. I guess that's consistent with the observation in this test case, that the MessagePort is GC'd after receiving its first message.

It seems like the behavior we want is that a MessagePort should be ineligible for GC (hasPendingActivity() == true) until (a) it is closed OR (b) its ScriptExecutionContext is torn down OR (c) every connected MessagePort's ScriptExecutionContext is torn down.

[Chris Dumez]

MessagePort garbage collection is specified here:
- https://html.spec.whatwg.org/multipage/web-messaging.html#ports-and-garbage-collection

I can look at aligning with the spec.

[Chris Dumez]

Pull request: https://github.com/WebKit/WebKit/pull/6099

[youenn fablet]

This might explain https://github.com/GoogleChromeLabs/comlink/issues/600 and rdar://99145178

[EWS]

Committed 256342@main (a4790ba92ba7): <https://commits.webkit.org/256342@main>

Reviewed commits have been landed. Closing PR #6099 and removing active labels.