358286 - jsd_BuildNormalizedURL strips two slashes from file: urls which causes problems for venkman

Status: RESOLVED FIXED

(Other Applications Graveyard :: Venkman JS Debugger, defect)

Description

[Joel M. Rives]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0

After loading my HTML page, I open the debugger and see all of my Javascript files listed in the Loaded Scripts section. However, when I double click to open any of them, I get the following error in the console:

Error loading URL <file:localhost/Users/joel/Projects/fwt/Button.js>: [Exception... "Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIChannel.asyncOpen]" nsresult: "0x80520012 (NS_ERROR_FILE_NOT_FOUND)" location: "JS frame :: chrome://venkman/content/venkman-url-loader.js :: loadURLAsync :: line 79" data: no].

I am able to open Javascript files loaded by other pages that I visit. Also, this was working fine until I upgraded to Firefox 2.0.

Reproducible: Always

Steps to Reproduce:
1.The steps are outlined in the details section
2.
3.

Actual Results:  
The results are the file does not load into the debugger and the above mentioned error message is output on the console.

Expected Results:  
The file should load into the debugger source code listing panel.

I have turned off or removed all extensions except the following:
DOM Inspector 1.8.1
FireBug 0.4.1
Talkback 2.0

Comment 1

[James Ross]

The URL given by the underlying debugger engine, and the JS engine, is invalid. That's why it fails to load the source. The question, then, is why is that URL being given?

You can turn on Pretty Printing to debug the code anyway, although that can only show a single function at a time.

Comment 2

[James Ross]

Out of interest, what URL is shown in the URL bar for the page you are viewing? Which of these does it start with?
  file:///
  file://localhost/

I've seen at least one other bug about Firefox 2 where it ends up with the "localhost" bit, and it could be related to this, since the invalid URL mentions it. Can you try changing the URL bar so that it doesn't say "localhost" and just starts with "file:///"?

Comment 3

[James Ross]

Also, for my reference, something does munge the URLs even for the non-"localhost" case, as they all end up being "file:/C:/..." here, which has lost two of the slashes. That, in fact, may be all that's wrong here. I don't know where or why those slashes go, though.

Comment 4

[James Ross]

Confirming, because it occurs with "localhost" entered manually. The bug is not in the failing to load, but the invalid URL. I'm pretty sure this goes down into JSD, or possibly into Spidermonkey. Joy.

Comment 5

[James Ross]

Bug 358141 is the one I saw about this "localhost" appearing.

Comment 6

[Joel M. Rives]

(In reply to comment #2)
> Out of interest, what URL is shown in the URL bar for the page you are viewing?
> Which of these does it start with?
>   file:///
>   file://localhost/
> 
> I've seen at least one other bug about Firefox 2 where it ends up with the
> "localhost" bit, and it could be related to this, since the invalid URL
> mentions it. Can you try changing the URL bar so that it doesn't say
> "localhost" and just starts with "file:///"?
> 

When I saw the problem, the URL in the browser started with file://localhost/

Today, it is showing file:/// and -- as you would expect, the debugger is working fine.

Comment 7

[:Gijs (he/him)]

James: this took me quite a bit of digging, but this seems to be where 2 slashes go missing. No idea why, though. CVS blame is of no help what-so-ever.

http://mxr.mozilla.org/seamonkey/source/js/jsd/jsd_text.c#217

Now what do we do? :-(

Comment 8

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Is this the same issue for loading errors resulting from a subscript load?

I have a file calItemModule.js that is in the components subdir of our extension, which uses the subscript loader to load files like calItemBase.js which is in a different directory.

Venkman fails to load this, since the jsd debugger service passes a very strange url string:

file:/home/kewisch/mozilla/comm-central/obj-i686-pc-linux-gnu/mozilla/dist/bin/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calItemModule.js -> file:///home/kewisch/mozilla/comm-central/obj-i686-pc-linux-gnu/mozilla/dist/bin/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calItemBase.js

(Yes, thats returned as one URL, not two urls split by a " -> ")

Comment 9

[:Gijs (he/him)]

(In reply to comment #8)
> Is this the same issue for loading errors resulting from a subscript load?
> 
> I have a file calItemModule.js that is in the components subdir of our
> extension, which uses the subscript loader to load files like calItemBase.js
> which is in a different directory.
> 
> Venkman fails to load this, since the jsd debugger service passes a very
> strange url string:
> 
> file:/home/kewisch/mozilla/comm-central/obj-i686-pc-linux-gnu/mozilla/dist/bin/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calItemModule.js
> ->
> file:///home/kewisch/mozilla/comm-central/obj-i686-pc-linux-gnu/mozilla/dist/bin/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calItemBase.js
> 
> (Yes, thats returned as one URL, not two urls split by a " -> ")

No, that's bug 449673.

Comment 10

[timeless]

http://mxr.mozilla.org/mozilla-central/source/js/jsd/jsd_text.c?mark=224-229#213

is the code which intentionally strips this.

for reference, this is how to set the breakpoint w/ windbg to verify:

bp xul!_newJSDScript+0x4b "j @@c++(raw_filename[0]!=99) '.echo \"Breakpoint hit, condition (raw_filename[0]!=99)\"' ; 'gc'"

the code is original to the file:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/jsd/jsd_text.c&rev=1.1&mark=237-242#230

sadly this is something like an API contract, so I'm hesitant to break it.

http://mxr.mozilla.org/mozilla-central/source/js/jsd/jsd.h?mark=580#569

Comment 11

[Karsten Düsterloh]

(In reply to comment #10)
> the code is original to the file:
> http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/jsd/jsd_text.c&rev=1.1&mark=237-242#230
> 
> sadly this is something like an API contract, so I'm hesitant to break it.

That code is unchanged since the dawn of time (1998), which doesn't necessarily make it potentially less wrong - in fact, the "canonification" directly violates RfC 1738, section 3.10 "FILES" (written in 1994):

| A file URL takes the form:
|        file://<host>/<path>
| where <host> is the fully qualified domain name of the system on
| which the <path> is accessible, and <path> is a hierarchical
| directory path of the form <directory>/<directory>/.../<name>.
...
| As a special case, <host> can be the string "localhost" or the empty
| string; this is interpreted as `the machine from which the URL is
| being interpreted'.

The question is: which caller of jsd_BuildNormalizedURL expect such a broken file URL?

Comment 12

[:Gijs (he/him)]

I've just fixed this in the fixURL function that was added by bug 449673, however silly that is. Fixed by the patch from bug 576869, I hope...