277322 - XMLHttpRequest from chrome fails to prompt when auth needed

Status: VERIFIED FIXED

(Core :: Networking: HTTP, defect)

Description

[Mark Smith [:mcs]]

If a sidebar extension sends an XMLHttpRequest and the server returns a 401
(Auth Required), the user is not prompted for the user ID and password.  We have
seen this on MacOS and Windows XP in both Mozilla 1.7.5 and Firefox 1.0 (we have
not checked Linux).

This is a regression (we do not see this problem in Mozilla 1.7.3).

This may have been introduced by the fix for bug 267367.

Comment 1

[Mark Smith [:mcs]]

Attachment: test case (sidebar extension for Firefox)

To use the test case, install the .XPI, then open the sidebar by selecting View
/ Sidebar / Test Case Sidebar.	When loaded, it sends a request that requires
auth.

Comment 2

[Darin Fisher]

I can reproduce this bug using a recent trunk build of Firefox.  (I had to
manually install the extension, given some recent XPI regressions.)

Comment 3

[Darin Fisher]

Ah, the problem is that HTTP was changed recently to query for
nsIAuthPromptProvider before nsIAuthPrompt.  XMLHttpRequest doesn't implement
nsIAuthPromptProvider, so HTTP tries the LoadGroup's notification callbacks. 
Those happen to be implemented by the DocShell, and the DocShell hands back a
nsIAuthPromptProvider that respects DocShell's allowAuth flag.

So, yes... this is a pretty serious regression.

Comment 4

[Boris Zbarsky [:bzbarsky]]

So... do we really want to be looking at loadgroups nsIAuthPromptProvider before
we look for the notification callbacks' nsIAuthPrompt?  That seems wrong...

Comment 5

[Darin Fisher]

Agreed.  I think that is the correct fix.

Comment 6

[Darin Fisher]

Attachment: v1 patch

Comment 7

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 170684 [details] [diff] [review]
v1 patch

why not declare authPromptProvider where it's first used?

Comment 8

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 170684 [details] [diff] [review]
v1 patch

r+sr=bzbarsky with biesi's nit addressed.

Comment 9

[Darin Fisher]

> why not declare authPromptProvider where it's first used?

Yeah, no reason.  That just slipped through the cracks as I was moving things
around :-/  Thanks for catching that.

Comment 10

[Darin Fisher]

fixed-on-trunk

Comment 11

[Darin Fisher]

marking FIXED

Comment 12

[Mark Smith [:mcs]]

Darin and everyone -- thanks for fixing this so quickly.

I'd like to see this land for aviary 1.1 and 1.76 as well.

Comment 13

[Benjamin Smedberg]

aviary 1.1 comes from the truk, so no further action is needed there. In
addition, this does not block the the 1.7.6 release, but you can request
approval for the 1.7 branch by "edit"ing the attachment.

Comment 14

[Mike Kaply [:mkaply]]

Comment on attachment 170684 [details] [diff] [review]
v1 patch

a=mkaply for 1.7.6

Comment 15

[Christopher Aillon (sabbatical, not receiving bugmail)]

Adding to blocker list for the branches.  Please land quickly.

Comment 16

[Christopher Aillon (sabbatical, not receiving bugmail)]

Comment on attachment 170684 [details] [diff] [review]
v1 patch

a=caillon (on behalf of drivers) for aviary1.0.1

Comment 17

[Jay Patel [:jay]]

Verified Fixed with 2/21 Firefox Aviary 1.0.1 and Trunk builds.  Couldn't test
with Mozilla 1.7.6, so if someone can verify this fix on the Suite, that will be
great.

Comment 18

[Mark Smith [:mcs]]

Verified Fixed in the Suite (using the 20050224 Mozilla 1.7 branch build). 
Thanks everyone!