234109 - HTTP authentication doesn't work

Status: RESOLVED FIXED

(Camino Graveyard :: General, defect)

Description

[J Luh]

HTTP authentication doesn't work in the latest nightly build. Instead of raising
a username and password dialog, the browser just goes to the "Access Denied" page.

Build 2004021208, Mac OS X 10.3.2 7D24.

Comment 1

[J Luh]

Firefox 20040212 works properly on the same system.

Comment 2

[Mike Pinkerton (not reading bugmail)]

i've seen this happening in new profiles. it doesn't happen in my converted
profile. Trying to track down the difference. It might be the application.regs
file no longer is generated. Previously, corruptions in this file would cause
this problem and the fix was to generate a new one.

conrad?

Comment 3

[Mike Pinkerton (not reading bugmail)]

actually, it's the chrome/chrome.rdf file. copying it from my working profile to
a non-working profile makes it work :)

wtf? how is this not being generated anymore?

Comment 4

[Mike Pinkerton (not reading bugmail)]

anything requiring a string bundle (status bar msgs) no longer work either
(since that's what the chrome reg has in it).

how do we fix this?

Comment 5

[Conrad Carlen (not reading bugmail)]

The standalone profile directory service provider sends out the same messages
that a profile is available that the profile mgr did. Somehow, the chrome
registry must be depending on something else as well. Need to see what causes
chrome/chrome.rdf to get made in the Seamonkey environment and make sure it does
in this environment.

Comment 6

[Conrad Carlen (not reading bugmail)]

Ben, I CC'd you becasue you had some interest/issue with chrome registry
initialization. If it wasn't you, sorry.

Comment 7

[Mike Pinkerton (not reading bugmail)]

Attachment: working chrome.rdf

as a workaround, put this chrome.rdf file in

~/Library/Application Support/Camino/chrome

and it should fix it. I was talking with bsmedberg about why this wasn't
working and he thinks he's seen a similar problem over in fire* with the chrome
file not being regenerated. Maybe that's a red herring and we're not doing
something we should be.

Comment 8

[Conrad Carlen (not reading bugmail)]

> Maybe that's a red herring and we're not doing something we should be.

The app shouldn't have to tickle the chrome reg in just the right way to get
this to work. I think this exposes a bug in the chrome reg initialization.
Looking at that...

Comment 9

[Mike Pinkerton (not reading bugmail)]

bsmedberg and i were talking and at a glance it appears that this is a
long-standing issue that's being exposed through a comedy of errors.

our best guess is that since there's no locale provided (new profile), the
chromereg code at line 614 just bails. It needs to do what line 627 does to
recover from a missing/bad locale.

perhaps this is related to bug 230558. it sure looks exactly the same.

Comment 10

[Mike Pinkerton (not reading bugmail)]

bsmedberg, any progress on this?

Comment 11

[Noemi]

Been having this problem with the 2004012303 nightly - thought until a few days
ago it was a browser identification issue.

Anyhow, looks like it dates back at least from December.

Comment 12

[Benjamin Smedberg]

I've found the problem: the chrome registry will not auto-select a locale
(i.e. chrome://necko/locale/) unless there is a matching content package (i.e.
chrome://necko/content/). Because we trim down embed.jar, there are several
packages in this state.

I have a bandaid patch coming up that adds empty content packages to embed.jar.
 Unfortunately, a real fix in the chrome registry is downright complicated, due
to the bizarre way the RDF data is organized.

Comment 13

[Benjamin Smedberg]

Attachment: add dummy content packages to embed.jar

Comment 14

[Mike Pinkerton (not reading bugmail)]

why are you removing pipnss references?

-locale,install,url,jar:resource:/chrome/embed.jar!/locale/en-US/pipnss/

Comment 15

[Benjamin Smedberg]

It's still there, I just moved it next to the content/ package.

Comment 16

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 142810 [details] [diff] [review]
add dummy content packages to embed.jar

r=pink, the patch fixes this bug and creates chrome.rdf

Comment 17

[Mike Pinkerton (not reading bugmail)]

patch landed. bsmedberg, is another bug already open on the real fix, or should
I open a new one?