Fallout from bug 537782. Test is currently disabled (the 'wrap' version only): http://hg.mozilla.org/mozilla-central/annotate/69e2e34ccddc/netwerk/test/unit/test_resumable_channel.js#l218 It fails in http://hg.mozilla.org/mozilla-central/annotate/69e2e34ccddc/netwerk/test/unit/test_resumable_channel.js#l247, where we get NS_ERROR_ENTITY_CHANGED instead of NS_ERROR_NOT_RESUMABLE. The responseStatus on the following line is 401. The NS_ERROR_ENTITY_CHANGED is coming from http://hg.mozilla.org/mozilla-central/annotate/69e2e34ccddc/netwerk/protocol/http/nsHttpChannel.cpp#l1102; on a successful run the NS_ERROR_NOT_RESUMABLE comes from http://hg.mozilla.org/mozilla-central/annotate/69e2e34ccddc/netwerk/protocol/http/nsHttpChannel.cpp#l933.

Actually, forget the fallout bit. This test was never running in the child process before bug 537782, so it's probably been busted a while, if not forever.

Also note that this is racy -- I can repro locally when running xpcshell without --verbose, but not with. (Changes the timing, I guess.)

Just runs the relevant test.

I guess this is broken forever. The test running on the content process sets notification callbacks on the child channel. That object have to return AuthPrompt2 object in answer to GI(nsIAuthPrompt2). But it is not the child channel whom callbacks are finally GI'ed, but the nsHttpChannel's instance on the parent process is. This has nothing to do with bug 537782, I'd say. To fix this? Store the password to the authcache as auth mochitests do through "@mozilla.org/login-manager;1".

Hmm.. now I realize, this won't be that simple. We have to fill the login manager in the chrome process to make this work. Could the wrapper do this and then clean up?

Ok, I managed to install logins on the chrome process, but it is useless, because the channel cannot reach it, there is no window (TabParent) associated with it. So, simplest solution: change URL in the test to 'http://guest:guest@localhost:4444' where we want authentication to pass. If everyone is ok with this, I will submit the patch. If not, I can add OMR listener on the chrome process, set a special header on the content process that we want the authentication to pass, and in chrome then install the provider, as we do on the content process. More work, but we preserve cache ids that might be vital for the test, though it passes w/ identity in the URL. Depends.

(In reply to comment #4) > I guess this is broken forever. The test running on the content process sets > notification callbacks on the child channel. That object have to return > AuthPrompt2 object in answer to GI(nsIAuthPrompt2). But it is not the child > channel whom callbacks are finally GI'ed, but the nsHttpChannel's instance on > the parent process is. Would this be an issue in real (non-test) code? Is it just extensions that might implement an authprompt callback on the child, or is that nonsensical?

(In reply to comment #7) Not sure I understand your question very well. > Would this be an issue in real (non-test) code? No, the test is just trying not to invoke any authprompts (if even possible in an xpcshell test), it just wants to pretend there has been credentials entered by user. > Is it just extensions that > might implement an authprompt callback on the child, or is that nonsensical? I don't think there is anything that could implement the callback on child. If we want it, than let's consider filing a bug on it, but I don't think it is doable - the callback just has to provide an object that we may then call to invoke the prompt. So, there would be a lot of rpc then because the authprompt callback running on the child process would return ref to an object also running on the child process. And we would then call it from the chrome process.

guest@guest sounds good then. Whatever's simplest ;)

(And by that I mean guest:guest. Sigh.)

Re-enable + fix the test.

Comment on attachment 470294 [details] [diff] [review] v1 > // Authentication (no password; working resume) > // (should not give us any data) > // XXX skip authentication tests on e10s (bug 587146) Stale comment. r=dwitte

(No need for approval since this is test-only.)

Comment updated.

Comment on attachment 481174 [details] [diff] [review] v1.1 [Check in comment 15] http://hg.mozilla.org/mozilla-central/rev/d872651d23cb