Many html tests assume data: URLs are treated as same-origin

[inexorabletash]

We're working on switching how Blink runs web-platform-tests for CI from our default mechanism as file:-based to using wptserve. This has turned up that many tests create subresources (iframes, vtt) using data: URLs then treat them as same-origin.

Per https://bugzilla.mozilla.org/show_bug.cgi?id=255107 only FF has the same-origin behavior. Opera/Chrome/Safari/IE all treat data: URLs as cross-origin and intentionally disagree with what is written in the spec, and therefore fail.

A handful of the tests for reference:
html/browsers/browsing-the-web/read-media/pageload-image.html
html/browsers/browsing-the-web/read-media/pageload-video.html
html/semantics/embedded-content/media-elements/interfaces/TextTrack/addCue.html
(and many others in TextTrack/)
html/syntax/parsing/html5lib_adoption01.html
(and many others in parsing/)
html/webappapis/scripting/processing-model-2/compile-error-data-url.html
... and probably others in directories we're not importing yet.

Since the browser behavior differences are long-standing (and perhaps unlikely to be resolved soon), and since these tests aren't testing data: URLs directly, it seems like we should update the tests to not depend on data: URLs.

[jgraham]

Historically Opera — i.e. Presto — matched the spec here and many of these tests were written by Opera engineers to match the spec. Given the disagreement about the model here I welcome PRs to change these tests to not use data: URIs (but in at least some cases I expect that to be difficult e.g. the html5lib tests are based around loading a document generated in content using the regular HTML parser; I'm not sure how else to do that).

[sideshowbarker]

@jgraham

I welcome PRs to change these tests to not use data: URIs (but in at least some cases I expect that to be difficult e.g. the html5lib tests are based around loading a document generated in content using the regular HTML parser; I'm not sure how else to do that)

Is using <iframe srcdoc> instead for those a possible solution?

Given the discussion in https://bugzilla.mozilla.org/show_bug.cgi?id=1018872 it might be useful to also get feedback from @annevk, @bzbarsky, and @mikewest here on how we should deal with this in the test suite. And maybe also from @hillbrad—especially if he @mikewest got any new ideas on what if anything might be possible as far as dealing with the underlying issue.

[annevk]

Mozilla would appreciate the tests being updated. That would make it easier for us to migrate to a stricter data URL world. It's not especially high priority for us at the moment though.

[inexorabletash]

An attempt at <iframe srcdoc> over in #2429 - seems to work but perhaps it's not capturing all of the semantics.

[bzbarsky]

<iframe srcdoc> is always in standards mode. Are any of these tests testing quirks mode?

[annevk]

First two are fixed by d6e6530.

<track> pointing to a data: URL seems okay and not cross-origin per se.

Not sure I see the problem in https://github.com/web-platform-tests/wpt/blame/master/html/syntax/parsing/html5lib_adoption01.html and generally those tests seem to run fine in all browsers?

https://github.com/web-platform-tests/wpt/blame/master/html/webappapis/scripting/processing-model-2/compile-error-data-url.html also seems fine and passes in all browsers.

Going to close this but feel free to reopen or shout if I missed something.