75670 - "hostname portion of chrome:// urls should not be converted to lowercase

Status: RESOLVED WONTFIX

(Core :: Networking, defect)

Description

[Robert Ginda]

around line 106 of nsStdURLParser the hostname portion of URLs is converted to
lowercase.  This prevents mixed case chrome urls from working properly.

Too see this in action, untar the attachment in your extensions directory and
make in extensions/MIxedCASe.

On linux you will have to configure --with-extensions=,default,MIxedCASe and
make in extensions.

Comment 1

[Robert Ginda]

Attachment: MIxedCASe.tar.gz; untar this in your mozilla/extensions directory

Comment 2

[Gagan]

this should get fixed with the nsStdURL parsing changes in the pipeline. hang in
there for that. cc'ing rpotts. ->taking over

Comment 3

[lchiang]

from mtg w/gagan: move target milestone to future
Pls see gagan for explanations if needed.

Comment 4

[Brendan Eich [:brendan]]

Oh please -- for all of us who weren't in some closed-door meeting, gagan should
write up the rationale here.

/be

Comment 5

[Gagan]

Oh please also be clear that this is a "PDT" decision not just from any meeting 
with gagan. Here is what I said in the PDT meeting-- there are changes in the 
making for nsStdURL parsing which will allow us to plug in parsers in a more 
flexible manner than the way it is today and that will allow things like 
case-sensitive parsing to work correctly. And I also mentioned that doing this 
in the current world would be difficult since the spec says that hostnames have 
to be case-insensitive. To fix it for chrome would have to special case it. 

Not knowing the exact need for this, the PDT decided to push this off to future. 
I have no problems with the decision one or the other. If you feel you need it 
earliar justify your case here and pull this back into 0.9.1... 

Comment 6

[Brendan Eich [:brendan]]

PDT, that makes everything clear.

Obviously, I was asking why this was futured.  The non-explanation entered by
lchiang was not helpful (not to say lchiang should have explained it; probably
you, gagan, should have done the deed and written some words).

I dunno whether this busts rginda.  If it's just the host part that gets
case-folded, how does that affect components in the path part?  I'm not all
bugged by this, in any case, cuz (as one of the [e-mail] who worries
about source tree directory naming conventions) I think we should be using
lowercase names for all directories.

But let's please not Future bugs without a few substantive, specific words about
why.

/be

Comment 7

[Gagan]

> gagan, should have done the deed and written some words
And I did ... at the first chance I got. 

So rginda: you want to address brendan's question and our concern on your
requirements? If you think this needs to be in 0.9.1 let us know.

Comment 8

[Robert Ginda]

I don't consider it a requirement for 0.9.1.  It's just something that came up
while testing my xul application template (mozilla/tools/wizards.)

BUT, if we don't fix this, it should be documented some place a XUL developer
might actually see.  A meaningful error message at chrome registration time
would be nice too.

Comment 9

[benc]

mass move, v2.
qa to me.

Comment 10

[Andrew Sutherland [:asuth] (he/him)]

To make it not seem like this bug has become moot, I believe this is still a
problem.  I was trying to create a basis for a new thunderbird extension by
modifying an existing extension and cleverly thought I would use mixed-case in
the package name.  Try and run thunderbird (0.7.3) with the overlay and the
window doesn't show up; ddd appears to be indicating that the gtk event loop is
running, suggesting it killed off the whole chrome window.  However, when I fix
the package name to be all lowercase, the main window properly loads and all is
well.

Comment 11

[Patrick McManus [:mcmanus]]

-etimedout