Jesper Hansen Reporter
	Description • 9 years ago

e10s breaks falling back to the default http auth digest if an addon provides the nsIAuthPromptProvider interface with getAuthPrompt.

If getAuthPrompt throws (see url) then Firefox is suppose to show the user the build in http auth digest dialog. 

If the queryInterface doesn't match nsIAuthPromptProvider, then the dialog will appear as normally.


https://addons.mozilla.org/en-US/firefox/addon/foxyproxy-standard/

	Jesper Hansen Reporter
	Comment 1 • 9 years ago

I rolled up a build I could add break points in and these were my findings:

From http://mxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/nsHttpChannelAuthProvider.cpp#935
929     nsCOMPtr<nsILoadGroup> loadGroup;
930     rv = mAuthChannel->GetLoadGroup(getter_AddRefs(loadGroup));
931     if (NS_FAILED(rv)) return rv;
932 
933     nsCOMPtr<nsIAuthPrompt2> authPrompt;
934     GetAuthPrompt(callbacks, proxyAuth, getter_AddRefs(authPrompt));
935     if (!authPrompt && loadGroup) {

-With e10s off:
authPrompt is NULL
loadGroup is not NULL

-With e10s on:
authPrompt is NULL
loadGroup is NULL

	Jesper Hansen Reporter
	Comment 2 • 9 years ago

proxy on & e10s on:
authPrompt=NULL && loadGroup=NULL
proxy off & e10s on:
authPrompt!=NULL && loadGroup=NULL
proxy on & e10s off:
authPrompt!=NULL && loadGroup!=NULL
proxy off & e10s off:
authPrompt!=NULL && loadGroup!=NULL

	Dave Townsend [:mossop]
	Comment 3 • 9 years ago

Is there a simplified testcase or code I can look at to reproduce this? What should I do with the URL linked to and what effect will I see that I shouldn't?

	Jesper Hansen Reporter
	Comment 4 • 9 years ago

This provides a simplified addon of FoxyProxy that shows the breakage in e10s.
The addon can be tested against any http digest auth page or just use http://test.getfoxyproxy.org/temp/jesper/index.html (cant guarantee the page will be around forever). 

I left in a few dump()s to assist. The "magic" fallback is suppose to happen in getAuthPrompt

Simple instructions:
1. Install addon.
2. Visit http://test.getfoxyproxy.org/temp/jesper/index.html
3. In non-e10s: auth dialog comes up
4. In e10s: no auth dialog comes up.

	Jesper Hansen Reporter
	Comment 5 • 9 years ago

Test case uploaded to https://github.com/jespersh/bug1119592

	Dave Townsend [:mossop]
	Comment 6 • 9 years ago

Dug in as far as I can here, probably worthwhile a necko person looking now. It seems that the http channel doesn't have a loadgroup when a page is loaded in e10s. So we hit here: http://mxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/nsHttpChannelAuthProvider.cpp#929. The first call to GetAuthPrompt goes through the extension which returns null but then it never does the second call for the loadGroup's notification callbacks.

Any thoughts Jason?

	Jason Duell
	Comment 7 • 9 years ago

IIRC Honza did most of our e10s auth stuff (I think :jdm might also have touched some).

	Honza Bambas (:mayhemer) Assignee
	Comment 8 • 9 years ago

Because of a good test case and a pretty good report I'll give this a priority.

	Honza Bambas (:mayhemer) Assignee
	Comment 9 • 9 years ago

Note: reproducible for Basic auth as well, obviously.

I a bit think this is INVALID.  In e10s we don't have loadGroups (yes, it has drawbacks and we are starting to think it would be good to have at least some of it, but that's a bigger project).

You completely rewrite the notification callbacks.  That is the first thing you actually do wrong when you don't forward to the original callbacks.  

When you fail to provide a prompt, you must do the dance that nsHttpChannelAuthProvider::PromptForIdentity does again in JS.  You must GetInterface() on the _original_ callbacks of the channel and then getAuthPrompt() the result.  There is no way around right now.


Leaving as INCOMPLETE, since having some load group concept on the parent process would have solved this.