[testdriver.js] Internal testdriver messages exposed to onmessage handlers

[jonathan-j-lee]

In cross-origin cases, the WebDriver-based testdriver.js implementation uses postMessage({type: "testdriver-{command,complete}", ...}) to communicate with the wptrunner harness. However, these internal messages are exposed to all message event handlers on the receiving end. This can trip up test-registered handlers that don't expect extra incoming messages, such as:

wpt/serial/requestPort/sandboxed_iframe.https.window.js

Lines 14 to 17 in 8ae822f

	window.addEventListener('message', t.step_func(messageEvent => {
	// The failure message of no device chosen is expected. The point here is
	// to validate not failing because of a sandboxed iframe.
	assert_true(messageEvent.data.includes('NotFoundError'));

... which fails because the handler only expects strings postMessage()ed from its child frame.

Maybe these messages should be filtered out in a high-level step_func-like API, so that every test doesn't need its own ad-hoc check (which also leaks testdriver implementation details)?

CC @jgraham @WeizhongX @cbiesinger (who fixed many such cases for fedcm/)

[jonathan-j-lee]

Looks like this also affects webusb/requestDevice/sandboxed_iframe.https.window.html and digital-credentials/. Updating each test to ignore testdriver messages won't scale (not to mention it's fragile and ugly).

Maybe we should put __wptrunner_message_queue in a different browsing context cross-origin with all test pages, which postMessage() testdriver events to only that test origin?

Edit: Never mind, looks like an easy fix with stopImmediatePropagation() (#48433).