Jonathan Watt [:jwatt] Reporter
	Description • 8 years ago

Now that bug 1177957 (implement the [SecureContext] WebIDL extended attribute) has been fixed, we're going to want to start adding an increasing number of Secure Context tests. Unfortunately Mochitest does not seem to be able to test such APIs. The section on doing SSL testing on MDN:

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Mochitest#SSL

says:

  Mochitests must be run from http://mochi.test/ to succeed

before explaining that there are https mirrors of the content on the original server available for cross-origin testing, presumably by opening popups or sub-documents. Unfortunately this is not enough for Secure Context testing.

To be a Secure Context a document and _all_ of the documents along its parent and _opener_ chain must have been "delivered securely". So popping up another window that uses an https URL from a test loaded via http://mochi.test/ will not create a Secure Context.

	(not currently active) Ted Mielczarek
	Comment 1 • 8 years ago

As stated you're absolutely correct. We run the top-level harness page from "http://mochi.test/", and that loads all the tests in an iframe.

We could try the simple fix here, and try loading the top-level page from "https://mochi.test/" and see what breaks. That'd be a one-line change here:
https://dxr.mozilla.org/mozilla-central/rev/c4449eab07d39e20ea315603f1b1863eeed7dcfe/testing/mochitest/runtests.py#745

If that doesn't work we might have to look at other options. We are running the Mochitest harness via Marionette now, so we could fairly easily do the thing I've always wanted to do, which would be to run each test in a new tab instead of in an iframe. I think that'd probably break a lot more tests, though, unfortunately.

	Jonathan Watt [:jwatt] Reporter
	Comment 2 • 8 years ago

https://treeherder.mozilla.org/#/jobs?repo=try&revision=c4357082b94d

	J.C. Jones [:jcj] (he/him)
	Comment 3 • 8 years ago

Note to implementer:

When this is implemented, if possible, it'd be useful to be able to specify in the mochitest.ini on a per-test basis what the base URL should be; not only whether it's HTTP or HTTPS, but potentially loading from https://example.com/ instead of https://mochi.test/.

If that's extremely difficult, a per-test schema switch would be the next best thing.

	Jonathan Watt [:jwatt] Reporter
	Comment 4 • 8 years ago

(In reply to Jonathan Watt [:jwatt] from comment #2)
> https://treeherder.mozilla.org/#/jobs?repo=try&revision=c4357082b94d

So basically the "simple fix" from comment 1 breaks pretty much everything, presumably because now we have cross-origin restrictions that break the harness-test interactions.

	(not currently active) Ted Mielczarek
	Comment 5 • 8 years ago

(In reply to Jonathan Watt [:jwatt] (catching up after vacation) from comment #4)
> (In reply to Jonathan Watt [:jwatt] from comment #2)
> > https://treeherder.mozilla.org/#/jobs?repo=try&revision=c4357082b94d
> 
> So basically the "simple fix" from comment 1 breaks pretty much everything,
> presumably because now we have cross-origin restrictions that break the
> harness-test interactions.

Well, it seems simpler than that:
http://mozilla-releng-blobs.s3.amazonaws.com/blobs/try/sha512/dd4e01889aebb3336b1517c6cbce71748353f7403e978fbd0e5ede212f867f82f1c600423e4020572b5a4d3f9538fbb9d1dfc7bc9e0a3b3e63e367a070ef0534

That error page shows "server not found" for mochi.test, presumably because your patch didn't also add https://mochi.test to server-locations.txt, and that's what we use to build the proxy pac JS.

n.b.: dougt is working on a patch in bug 1286312.

	J.C. Jones [:jcj] (he/him)
	Comment 6 • 8 years ago

For those waiting on this feature for [SecureContext] support in particular, you can use the new "dom.securecontext.whitelist" pref to mark the "mochi.test" host secure - or whatever host you are loading the test from. For example:

SpecialPowers.pushPrefEnv({"set": [["dom.securecontext.whitelist", "mochi.test"]]},
function() {
// do things that require SecureContext
});

	Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)
	Comment 7 • 8 years ago

(In reply to J.C. Jones [:jcj] from comment #6)
> For those waiting on this feature for [SecureContext] support in particular,
> you can use the new "dom.securecontext.whitelist" pref to mark the
> "mochi.test" host secure - or whatever host you are loading the test from.
> For example:
> 
> SpecialPowers.pushPrefEnv({"set": [["dom.securecontext.whitelist",
> "mochi.test"]]},
> function() {
> // do things that require SecureContext
> });

Do you suggest when to call SpecialPowers.pushPrefEnv?
I found nsContentSecurityManager checks that pref before loading test cases.

	J.C. Jones [:jcj] (he/him)
	Comment 8 • 8 years ago

As early as possible, I guess. For my uses in U2F/WebAuthn where the check is done by WebIDL alone, it seems to work OK. :/

	J.C. Jones [:jcj] (he/him)
	Comment 9 • 8 years ago

:shawnjohnjr, you're correct. I had a test profile that was masking the issue, so this doesn't work. We'll have to wait on the real fix.

That said, you _can_ locally cheat until then at the command line by passing --setpref dom.securecontext.whitelist=mochi.test to mochitest.

	Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)
	Comment 10 • 8 years ago

(In reply to J.C. Jones [:jcj] from comment #9)
> :shawnjohnjr, you're correct. I had a test profile that was masking the
> issue, so this doesn't work. We'll have to wait on the real fix.
> 
> That said, you _can_ locally cheat until then at the command line by passing
> --setpref dom.securecontext.whitelist=mochi.test to mochitest.

The real fix is on the way. I talked with the bug owner. It shall be landed soon.

	J.C. Jones [:jcj] (he/him)
	Comment 11 • 8 years ago

I think this was fixed by Bug 1286312.