131143 - Misleading error "c is not a registered protocol" when accessing chome://

Status: VERIFIED FIXED

(Core :: DOM: Navigation, defect)

Description

[Matthew Wilson]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.9) Gecko/20020311
BuildID:    2002031104

After mis-typing a URL so that it began with "chome://" instead of "chrome://",
the error message reported was "c is not a registered protocol"; i.e. only the
first character of the incorrect protocol was reported.

Reproducible: Always
Steps to Reproduce:
Type 'chome://' in the URL bar (or any non-registered protocol).

Actual Results:  The error message shows only the first character of the
incorrect protocol.

Expected Results:  The full protocol name should be displayed.

Comment 1

[Tom Everingham]

-> docshell

Comment 2

[Matthias Versen [:Matti]]

*** Bug 131285 has been marked as a duplicate of this bug. ***

Comment 3

[benc]

qa to me.
Sigh. I really wanted error messages to be robust for mozilla 1.0, but there are
so many of these getting through...

I've seen this as well in 0.9.9.

Comment 4

[Adam Lock]

appstrings.properties appears to be using a lower-case %s throughout when - at
least for this instance - it should be using uppercase %S. Most of the other
strings are processed in nsWebShell which calls snprintf for itself, but in this
instance docshell is calling nsIStringBundle::FormatStringFromName which expects
only unichar strings.

Patch follows.

Comment 5

[Adam Lock]

Attachment: Patch uses %S

Reviews please.

Comment 6

[Adam Lock]

We're in localization lockdown, but it might be possible to sneak this into 1.0,
so I'll mark it as such for the time being.

Comment 7

[Chak Nanga]

Comment on attachment 76772 [details] [diff] [review]
Patch uses %S

r=chak

Comment 8

[Adam Lock]

Lining this up to go in 1.0 if possible. Waiting on the sr but pushing it
through as quickly as possible for consideration.

Summary - very low risk, visible impact

Comment 9

[rpotts (gone)]

Comment on attachment 76772 [details] [diff] [review]
Patch uses %S

sr=[e-mail]

Comment 10

[Asa Dotzler [:asa]]

Comment on attachment 76772 [details] [diff] [review]
Patch uses %S

a=asa (on behalf of drivers) for checkin to the 1.0 trunk

Comment 11

[Adam Lock]

Lori, can you add your approval as far as localization is concerned? 

Nominate for adt1.0.0+.

Low risk, big impact.

Comment 12

[Lori Kaplan]

a=UI
adding impact status. This bug prevents users from figuring out what to do when
they make a typo in the URL field. 
cc'ing mcarlson for localization approval 

Comment 13

[Jaime Rodriguez, Jr.]

adt1.0.0+ (on ADT's behalf) approval for checkin to 1.0, pending L10N approval.
Changing ADT3

Comment 14

[Jaime Rodriguez, Jr.]

meant "+" ... mia culpa.

Comment 15

[Michele Carlson]

Can you please check in this change today. l10n approved for check in today. thanks

Comment 16

[Adam Lock]

1.0 is branching at this moment. I have asked for re-approval and assuming it is
given the checkin should go in when the tree has reopened (which will be
tomorrow for me)

Comment 17

[Adam Lock]

Fix checked into trunk, still waiting for branch approval

Comment 18

[Adam Lock]

Fix checked into branch

Comment 19

[Asa Dotzler [:asa]]

adding fixed1.0.0 keyword (branch resolution). This bug has comments saying it
was fixed on the 1.0 branch and a bonsai checkin comment that agrees. To verify
the bug has been fixed on the 1.0 branch please replace the fixed1.0.0 keyword
with verified1.0.0.

Comment 20

[Matthias Versen [:Matti]]

*** Bug 155257 has been marked as a duplicate of this bug. ***

Comment 21

[benc]

VERIFIED/branch - Netscape 7.0
VERIFIED/trunk - via Mozilla 1.1
allplats