Made the trusted-types tests run correctly in a vanilla wptrunner.

[koto]

Tests that set up trusted-types-enforcing CSP now execute in a separate iframe, not to clash with the harness using the DOM directly.

[mikewest]

@otherdaniel, mind taking a look?

[mikewest]

(We talked about this briefly yesterday, and @otherdaniel had interesting ideas about modifying testharness.js instead of all the tests.)

[jgraham]

OOI what are the requirements here?

[mikewest]

@jgraham: Trusted Types gives developers the ability to change the requirements for things like innerHTML. The test harness uses innerHTML to dump out a table of results. This explodes in tests that disable string-based innerHTML rendering. @otherdaniel's approach would be to teach testharness.js to use trusted types if the browser supports them, just as any other library would want to do.

[koto]

I went down that path initially a couple of months ago (the patch to harness is in the polyfill repository under tests/). However, the patch was quickly broken by new changes to testharness, and surfaced another errors (e.g. chromedriver likes to use innerhtml as well, and its code is outside of the wpt repository). I could not even debug some of the errors, as they were not throwing in the console. For practical reasons, it might be easier to run the CSP requiring tests in a separate iframe, which is what I did here, which feels less invasive to the harness infrastructure.

…

On Fri, Dec 7, 2018, 15:43 Mike West ***@***.***> wrote: @jgraham <https://github.com/jgraham>: Trusted Types gives developers the ability to change the requirements for things like innerHTML. The test harness uses innerHTML to dump out a table of results. This explodes in tests that disable string-based innerHTML rendering. @otherdaniel <https://github.com/otherdaniel>'s approach would be to teach testharness.js to use trusted types if the browser supports them, just as any other library would want to do. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#14400 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAH0q2JVTGaQWitI4faOTyHlSV5QCWzhks5u2n50gaJpZM4ZGwz2> .

[otherdaniel]

My version of solving this in testharness ends up looking almost exactly like koto's, with likely the same drawbacks. (https://chromium-review.googlesource.com/c/chromium/src/+/1371874) The main plus would be that I've modified all the tests to allow for a 'testharness' policy, so that all WPT users can be sure that a policy with that name can be built for testharness' own use.

On second thought, I'm no longer sure that's the better path than what koto suggests here.

[koto]

The patch from the Chromium version would be incomplete for the vanilla WPT - here testharness.js needs to be modified as well (https://github.com/WICG/trusted-types/blob/master/tests/platform-tests/platform-tests.patch has the relevant changes). Alternatively setup({output: false}) called in the test files to disable debug output might work.

Additionally, the vanilla testharnessreport.js breaks with TT as it assigns the data to script element textContent property here.

I have a strong suspicion that this line in chromedriver will also pose problems, I've encountered this in some of the test runs, but I don't understand the whole harness setup fully.

[koto]

Friendly ping on this one.