jar: protocol doesn't work if "!/" is missing, resulting in Google search for "jar"

Assigned to



Networking: JAR
12 years ago
9 months ago


(Reporter: Jesse Ruderman, Assigned: Waldo)


Mac OS X

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [necko-would-take])



12 years ago
Steps to reproduce:
1. Enter jar:http://www.getfirebug.com/releases/firebug1.0-b4.xpi
into the address bar.  (Note the missing "!/" at the end of the URL.)

Result: Firefox does a Google search for "jar".

Expected: Show me a list of the contents of the XPI file.

Comment 1

12 years ago

This is standard behavior for every protocol which is given a malformed URI: we attempt to construct a URI for it, and if we can't for any reason it's passed to the default fixup, which does the Internet search for it.  (This is why, for example, http:///directory/file.html does a Google search, instead of complaining about a malformed URI.)  I suppose we could check whether the string matches /^[a-zA-Z]:/ and in that case handle as if we had a malformed URI, and that might work without disrupting the expected behavior too much.  Thoughts?
Assignee: nobody → jwalden+bmo
Component: Networking: JAR → Embedding: Docshell
QA Contact: networking.jar → docshell
Target Milestone: --- → mozilla1.9alpha

Comment 2

12 years ago
It sounds like there are two bugs here:

1. The jar: protocol code considers jar:http://www.getfirebug.com/releases/firebug1.0-b4.xpi to be a malformed URI; I wish it would fix it (by adding "!/" to the end) or accept it as is (treating it as if it had "!/" at the end) instead.

2. When nsDocShell.cpp encounters a malformed URI for a known protocol, it does the wrong thing.

Can you file a new bug for #2 to avoid morphing this bug?
> 2. When nsDocShell.cpp encounters a malformed URI for a known protocol

Meaning what?  Consider the string "http: is something that appears at the beginning of a lot of URIs".  This is a "malformed URI for known protocol" (to whit the "http" protocol).  We absolutely want to do a search for this string if we ever do a search anywhere.

So given what docshell knows here (not much, really), it's doing exactly what it should be.

And if this is a jar: bug, it's totally in the wrong component.

Component: Embedding: Docshell → Networking: JAR
QA Contact: docshell → networking.jar
Whiteboard: [necko-would-take]
You need to log in before you can comment on or make changes to this bug.