Joel Maher ( :jmaher ) (UTC -8) Reporter
	Description • 14 years ago

I am unable to run most of the basic mochitest tests due to the fact that they rely on PAC settings to access things like example.com mochi.test, etc...

	Joel Maher ( :jmaher ) (UTC -8) Reporter
	Comment 1 • 14 years ago

the sooner we fix this bug, the sooner we can run mochitests on fennec + e10s.

	Doug Turner (:dougt)
	Comment 2 • 14 years ago

depended on 506269?

	Jason Duell
	Comment 3 • 14 years ago

Note that mochitests will currently run with a separate necko stack per process.  That's why this is failing (the content process's necko stack can't access PAC settings because the profile info isn't visible to it).

If we set NECKO_E10S_HTTP=1 in the environment, the PAC profile problem will go away, as necko lives only in chrome for PAC purposes.  But there may be extensive breakage from using the in-development e10s necko code.  Or perhaps not--if the network usage is fairly straightforward, things might work well enough for mochitests' purposes. I recommend trying a run and seeing what happens.

This bug should thus be eventually turned into either 1) get content profile access working, so that PAC works with per-process necko (in which case this bug depends on bug 506269 as dougt mentioned); or 2) turn on NECKO_E10S_HTTP=1 in mochitests.  

If the tests runs well enough with the env var=1, then #2 is definitely the choice, since that's what we're going to need to be eventually testing anyway.  But if it's broken there may be utility in testing fennec with the per-process necko--but I'm the wrong person to ask about that.

	cmtalbert
	Comment 4 • 14 years ago

(In reply to comment #3)
> If the tests runs well enough with the env var=1, then #2 is definitely the
> choice, since that's what we're going to need to be eventually testing anyway. 
> But if it's broken there may be utility in testing fennec with the per-process
> necko--but I'm the wrong person to ask about that.
I'm a little confused.  Eventually, E10S will be running per-process necko, right?  And that is what NECKO_E10S_HTTP is going to enable, so by doing that we are testing what we hope to ship as E10S, correct?

Or is per-process necko different from "interprocess HTTP" (which is what this setting is referred to in the code)?

	Jason Duell
	Comment 5 • 14 years ago

> Eventually, E10S will be running per-process necko,
right?  And that is what NECKO_E10S_HTTP is going to enable, so by doing that
we are testing what we hope to ship as E10S, correct?

Yes.  The end goal is definitely to test with the env var on (actually, the end goal is to remove the env var and enable by default). 

But depending on the current state of necko and mochitest's network needs, we may find that we get more useful coverage for now of *other*, non-networking code if the env var is off.  We should try a run with it on/off and see what the results look like.

	Jason Duell
	Comment 6 • 14 years ago

Joel, can you try running mochitests with NECKO_E10S_HTTP=1 set in your environment and see what happens?

	Jason Duell
	Comment 7 • 14 years ago

P.S.  In case setting an environment variable for mochitests is an issue, this patch forces e10s/necko to be on w/o checking the env var.

	Joel Maher ( :jmaher ) (UTC -8) Reporter
	Comment 8 • 14 years ago

setting NECKO_E10S_HTTP=1 seemed to solve the problem with some basic mochitest sanity checking.

	Jason Duell
	Comment 9 • 14 years ago

Great!  So let's turn on NECKO_E10S_HTTP=1 (or make it the default--let me know if you need that) and we should be able to set up fennec mochitests (at least as far as this bug is concerned).