Update some screencapture/ tests to work with HTTPS-First mode
Categories
(Core :: DOM: Security, task, P2)
Tracking
()
People
(Reporter: freddy, Assigned: freddy)
References
(Blocks 1 open bug)
Details
(Whiteboard: [domsecurity-active])
Attachments
(1 obsolete file)
Assignee | ||
Comment 1•3 years ago
|
||
Comment 2•3 years ago
|
||
Why does this apply to specifically these tests? Should we disable this for the whole wpt testsuite (if it causes us to start loading non-https tests or their resources over https that seems like a bug)?
Assignee | ||
Comment 3•3 years ago
|
||
Well, HTTPS-First is a big feature and we had to think of a way to start splitting things up.
For the affected non-wpt tests, we've been trying simple fixes and rewrites, so we're doing it folder-by-folder to see if some tests are easily changeable.
I'm hoping that other, follow-up bugs will identify tests than can be fixed in upstream wpt, so we don't have to disable it altogether which seems preferable. Makes sense?
Updated•3 years ago
|
Comment 4•3 years ago
|
||
I possibly don't understand the scope of the feature well enough to be sure, but if this means that we'll start loading all the tests as https rather than http, and require test-specific prefs to override, that seems like a problematic situation (it means that you can't write a test for "this API should not be available in HTTP" and expect it to work in gecko without test-specific prefs being set), and might mean that tests which intentionally try to do cross-origin things using HTTP and HTTPS suddenly aren't doing that anymore.
I think if this is where we're going we need to have a broader conversation about adding an explicit http marker for wpt, and requiring tests that need either http or https to opt in, and making the default "use either". But maybe I've misunderstood what the feature is doing?
Assignee | ||
Comment 5•3 years ago
|
||
Eh, probably not needed anymore. Thanks for taking a look, James.
Updated•3 years ago
|
Description
•