Pending an update to the spec [1], calling postMessage on BroadcastChannel objects associated with detached iframes or closing workers should have no effect. See new tests in [2] for more details. Per [3] it sounds like postMessage might throw an exception (as if the BroadcastChannel was closed) instead of the postMessage having no effect in at least certain detached iframe cases. [1] https://github.com/whatwg/html/issues/7219 [2] https://github.com/web-platform-tests/wpt/pull/31290 [3] https://github.com/whatwg/html/issues/7219#issuecomment-943480682
Created attachment 443618 [details] Patch
Created attachment 443623 [details] Patch
Comment on attachment 443623 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=443623&action=review > LayoutTests/imported/w3c/web-platform-tests/webmessaging/broadcastchannel/service-worker.https-expected.txt:2 > +FAIL BroadcastChannel works in service workers promise_test: Unhandled rejection with value: object "TypeError: ReferenceError: Can't find variable: BroadcastChannel" Will address this failure via https://bugs.webkit.org/show_bug.cgi?id=232855.
Created attachment 443635 [details] Patch
Comment on attachment 443635 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=443635&action=review > Source/WebCore/dom/BroadcastChannel.cpp:187 > + if (!isEligibleForMessaging()) > + return { }; > + > if (m_isClosed) > return Exception { InvalidStateError, "This BroadcastChannel is closed" }; So while closing we silently do nothing, and once closed we throw an exception. To me this seems like a peculiar design. > Source/WebCore/dom/BroadcastChannel.cpp:235 > + if (!isEligibleForMessaging()) > + return; > + > if (m_isClosed) > return; If it wasn’t for the unusual case above, I would suggest we merge the m_closed check into isEligibleForMessaging.
Comment on attachment 443635 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=443635&action=review >> Source/WebCore/dom/BroadcastChannel.cpp:187 >> return Exception { InvalidStateError, "This BroadcastChannel is closed" }; > > So while closing we silently do nothing, and once closed we throw an exception. To me this seems like a peculiar design. A little peculiar but definitely what was just added to the spec: - https://html.spec.whatwg.org/#dom-broadcastchannel-postmessage Maybe they were worried about breakage when throwing since this check is new?
Committed r285503 (244027@main): <https://commits.webkit.org/244027@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 443635 [details].
<rdar://problem/85207221>