Bug 232693 - Ignore BroadcastChannel::postMessage from detached iframe / closing worker contexts
Summary: Ignore BroadcastChannel::postMessage from detached iframe / closing worker co...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: Safari Technology Preview
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Chris Dumez
URL:
Keywords: InRadar
Depends on:
Blocks: 232855
  Show dependency treegraph
 
Reported: 2021-11-03 20:37 PDT by Andrew Williams
Modified: 2021-11-10 09:19 PST (History)
11 users (show)

See Also:


Attachments
Patch (44.94 KB, patch)
2021-11-08 15:30 PST, Chris Dumez
no flags Details | Formatted Diff | Diff
Patch (44.36 KB, patch)
2021-11-08 15:45 PST, Chris Dumez
no flags Details | Formatted Diff | Diff
Patch (46.65 KB, patch)
2021-11-08 17:20 PST, Chris Dumez
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Williams 2021-11-03 20:37:59 PDT
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
Comment 1 Chris Dumez 2021-11-08 15:30:41 PST
Created attachment 443618 [details]
Patch
Comment 2 Chris Dumez 2021-11-08 15:45:23 PST
Created attachment 443623 [details]
Patch
Comment 3 Chris Dumez 2021-11-08 15:47:31 PST
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.
Comment 4 Chris Dumez 2021-11-08 17:20:53 PST
Created attachment 443635 [details]
Patch
Comment 5 Darin Adler 2021-11-09 09:34:29 PST
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 6 Chris Dumez 2021-11-09 09:36:35 PST
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?
Comment 7 EWS 2021-11-09 09:49:45 PST
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].
Comment 8 Radar WebKit Bug Importer 2021-11-09 09:50:22 PST
<rdar://problem/85207221>