Closed Bug 219954 Opened 21 years ago Closed 7 years ago

c is not a registered protocol

Categories

(Core :: DOM: Navigation, defect)

x86
Windows 2000
defect
Not set
trivial

Tracking

()

RESOLVED INVALID

People

(Reporter: padraig, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030916
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030916

"c is not a registered protocol" error occurs when I click on: 
<a target="_blank" href="C:\Program Files\Microsoft Visual Studio .NET
2003\SDK\v1.1\QuickStart\winforms\Samples\GDIPlus\Pens\CS">Run Sample</a>

when I right click and open a new tab/windows it works


Reproducible: Always

Steps to Reproduce:
1. Microsoft .NET Framework SDK v1.1 
2. Samples and QuickStart Tutorials 
3. windows forms 
4. working with graphics 
5. run sample.

Actual Results:  
a new window opens with the popup message "c is not a registered protocol"

Expected Results:  
open a new window and display the directory contents
This is simply bad html ... with a twist. An url embedded into an html document
needs to have a protocol attached to it. href="C:\Program Files\Microsoft Visual
Studio .NET2003\SDK\v1.1\QuickStart\winforms\Samples\GDIPlus\Pens\CS" has none
(bad html!!!!), but trying to do only limited urifixup in links in html
documents mozilla thinks "c" (everything before the colon) is the protocol.
Hence the box "c is not a registered protocol". Also using \ instead of / as
path separator violates several RFCs (2396 for example)... as I said ... really
bad html.

Why does it work with a new window? Because a new window opens a new docshell
and that sparks a much more complete urifixup (because usually the docshell
deals with userinput from the urlbar). That urifixup can detect (on windows) a
local *filepath* and convert it into a *fileurl* which is why the code now works.

Why don't we use this urifixup also in html documents? Because we expect more
from someone creating a html document them simply fall with his head on the
keyboard and create random strings of characters (which frankly is what is your
example code).

The error in mozilla is that when opening a link in a new window it sparks the
more complete urifixup. It shouldn't, it should just give you the same message
as before: "c is not a registered protocol".
Assignee: general → adamlock
Status: UNCONFIRMED → NEW
Component: Browser-General → Embedding: Docshell
Ever confirmed: true
QA Contact: general → adamlock
The problem also appears when double-clicking on a .xul file in windows.
However changing the "open" file association in the windows explorer solves this
problem:

change this:
[installation path]\MOZILLA.EXE -chrome "%1"

to this:
[installation path]\MOZILLA.EXE -chrome "file://%1"

where [installation path] is of course the actual path mozilla is installed in
like 'C:\PROGRAMS\MOZILLA.ORG\MOZILLA\'

and you are set.

I think this is an error either in the file handling or in the mozilla installer.
(In reply to comment #2)
> The problem also appears when double-clicking on a .xul file in windows.
> However changing the "open" file association in the windows explorer solves this
> ...
> [installation path]\MOZILLA.EXE -chrome "file://%1"

That is Bug 238830. Correct is ... -chrome "file:///%1".
*** Bug 273937 has been marked as a duplicate of this bug. ***
I see this bug when using WindRiver's Tornado Online Manuals -- it's a standard
Windows help file (hierarchy of purple book icons) but when you click a topic it
attempts to load a webpage stored on the local computer.  Current workaround is
to set IE as default browser :(
(In reply to comment #1)

By this logic, you should throw out Quirks Mode entirely because the only reason
to have Quirks Mode is to work around people writing incorrect or sloppy HTML. 
After all, we expect people writing HTML documents to write real HTML code and
not just bang their head on the keyboard... right?
(In reply to comment #6)
> (In reply to comment #1)
> 
> By this logic, you should throw out Quirks Mode entirely because the only reason
> to have Quirks Mode is to work around people writing incorrect or sloppy HTML. 
> After all, we expect people writing HTML documents to write real HTML code and
> not just bang their head on the keyboard... right?

No, but there is a certain limit to quirkiness that can be tolerated. In my
opinion this breaks it. Also there is no quirks mode for URLs just for HTML. We
just have a little bit of url-fixup at our disposal not a quirks mode.
Assignee: adamlock → nobody
QA Contact: adamlock → docshell
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.