BroadcastChannel: potential bug in "close" concept

[gterzian]

Firstly, I think there might be a bug in the spec with regards to the use of close when broadcasting a message.

Currently, close is used as a filter to determine the channels to include in the "destinations" list, at Step 7 of https://html.spec.whatwg.org/multipage/#dom-broadcastchannel-postmessage

At that point, we're inside the task from where the message is "sent".

Step 10 then says to queue a task for each channel that was added to the "destination" list, in order to actually fire the MessageEvent.

So, would it not make more sense to check the close flag from inside the task queued at 10, to determine at the receiving end whether the destination channel has been closed already?

[gterzian]

Ok so I've had a look at various UAs, the spec doesn't follow implementations, as they seem to be checking the close flag before firing the event from inside the task that is queued, not at step 7 when filtering for "destinations".

For example, the below test passes in FF and Chrome(my manual check), and should fail as per the current wording of the spec.

async_test(t => {
    let c1 = new BroadcastChannel('closed');
    let c2 = new BroadcastChannel('closed');

    c2.onmessage = t.unreached_func();
    
    c3.onmessage = t.step_func(() => t.done());
    // Note: not closed here. 
    // Per the spec the close flag is checked in the call to postMessage,
    // before queuing tasks to fire message events.
    c1.postMessage('test');
 
    // Note: closing after the tasks have already been queued.
    c2.close();
  }, 'messages aren\'t delivered to a closed port');

[gterzian]

Dupe of #1371

Should we try to close both? That one is from 2016...

[annevk]

Ah, thanks for finding that. If you want to write a PR and tests, that'd be great.