1919248 - Investigate why WPT <to-javascript-url-script-src.html> times out for Gecko (SecurityPolicyViolationEvent target is an iframe in other browsers)

Status: RESOLVED FIXED

(Core :: DOM: Security, task, P2)

Description

[Mirko Brodesser (:mbrodesser-Igalia)]

https://searchfox.org/mozilla-central/rev/26a98a7ba56f315df146512c43449412f0592942/testing/web-platform/tests/content-security-policy/navigation/to-javascript-url-script-src.html

Comment 1

[Frederik Braun [:freddy]]

No need to jump to a fix, but it would be nice to do an early investigation why this isn't passing

Comment 2

[Mirko Brodesser (:mbrodesser-Igalia)]

It times out because e.target at [1] isn't the iframe element, but the outer document.

According to the spec [2] the violation's element is null. Later in the spec [3] in step 3.2 that results in a target of null. Which, in the same step is replaced by the global object, or, if the latter is a Window, by the windows' document.
Presumably the latter happens in Gecko.
The test passes in Chrome, so there the global object should be the iframe.

So it needs to be figured out which global is the correct one to use in step 3.1.1.3 of [2].

[1] https://searchfox.org/mozilla-central/rev/26a98a7ba56f315df146512c43449412f0592942/testing/web-platform/tests/content-security-policy/navigation/to-javascript-url-script-src.html#13
[2] https://w3c.github.io/webappsec-csp/#should-block-navigation-request
[3] https://w3c.github.io/webappsec-csp/#report-violation

Comment 3

[Mirko Brodesser (:mbrodesser-Igalia)]

Seems to be related to https://github.com/whatwg/html/issues/4651#issue-447334382:

so there is only one sane global to use around. But for location.href sets or modifications of the src attribute of <iframe>, it should be observable which global's CSP gets used here.

Comment 4

[Mirko Brodesser (:mbrodesser-Igalia)]

The test passes in Chrome and all other major browsers [1].

In the spec, the violation's element, i.e. in the test the iframe element [2], could be passed to [3] invoked by step 5 of [4] by passing the navigable's container [5] if that is an iframe element.

[1] https://wpt.fyi/results/content-security-policy/navigation/to-javascript-url-script-src.html?label=master&label=experimental&aligned&q=to-javascript-url-script-src.html
[2] https://searchfox.org/mozilla-central/rev/26a98a7ba56f315df146512c43449412f0592942/testing/web-platform/tests/content-security-policy/navigation/to-javascript-url-script-src.html#39
[3] https://w3c.github.io/webappsec-csp/#should-block-navigation-request
[4] https://html.spec.whatwg.org/#navigate-to-a-javascript:-url
[5] https://html.spec.whatwg.org/#nav-container

Comment 5

[Tom Schuster]

It would be good to get this properly specified and fixed. I think from an user's perspective using the iframe as the target makes sense?

Comment 6

[Mirko Brodesser (:mbrodesser-Igalia)]

(In reply to Tom Schuster (MoCo) from comment #5)

It would be good to get this properly specified and fixed. I think from an user's perspective using the iframe as the target makes sense?

Yes.

Currently trying to figure out how to get the iframe element in https://searchfox.org/mozilla-central/rev/1e8cec3727d6e09f4af41bb3d202b7a4c326ed84/dom/jsurl/nsJSProtocolHandler.cpp#171.

Comment 7

[Mirko Brodesser (:mbrodesser-Igalia)]

(In reply to Mirko Brodesser (:mbrodesser-Igalia) from comment #2)

It times out because e.target at [1] isn't the iframe element, but the outer document.

According to the spec [2] the violation's element is null. Later in the spec [3] in step 3.2 that results in a target of null. Which, in the same step is replaced by the global object, or, if the latter is a Window, by the windows' document.
Presumably the latter happens in Gecko.

Confirming the presumption.

Comment 8

[Mirko Brodesser (:mbrodesser-Igalia)]

Attachment: Bug 1919248: transform WPT <to-javascript-url-script-src.html>'s async sub-tests to promise-tests and remove checking the securitypolicyevent's target element. r=smaug

Gecko doesn't set the securitypolicyevent violation's target element,
which prevented the async tests from passing with Gecko.
Setting the violation's target element isn't specified (
https://github.com/w3c/webappsec-csp/issues/687).

Promise-based tests allow removing checking the target element, because
the tests are run in sequence
(https://web-platform-tests.org/writing-tests/testharness-api.html#promise-tests).

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b941985be923
transform WPT <to-javascript-url-script-src.html>'s async sub-tests to promise-tests and remove checking the securitypolicyevent's target element. r=smaug

Comment 10

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/48884 for changes under testing/web-platform/tests

Comment 11

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/b941985be923

Comment 12

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot