URLs not properly resolved in debugger

RESOLVED FIXED in mozilla1.0.1

Status

Other Applications
Venkman JS Debugger
RESOLVED FIXED
16 years ago
13 years ago

People

(Reporter: Matthew Mastracci, Assigned: Robert Ginda)

Tracking

(Blocks: 1 bug)

Trunk
mozilla1.0.1
x86
Windows 2000

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
Insert a script block like:

<script src="/foo/bar.js"></script>

in a file placed in a subdirectory (ie: /some/directory)

When you look in the top-left (file exploring) pane in the debugger and locate 
the script, the URL is wrong- it comes out as 
http://server/some/directory//foo/bar.js and the file can't be found.
(Assignee)

Comment 1

16 years ago
we should set the script filename to the full path, not the value of the src
attribute.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → mozilla1.0
(Assignee)

Comment 2

16 years ago
...actually, we do.  I didn't notice you were talking about the top left view. 
  You are talking about the *top* left view, the one with "Windows" and
"Breakpoints" in it, right?

Regardless, both top left and middle left views correctly resolve relative
scripts for me.  Reporter, are you still seeing this?
(Reporter)

Comment 3

16 years ago
It's actually the top-right frame.  It displays an error page from the webserver
because it is trying to resolve a JS file that doesn't exist.  I'll grab the
latest nightly and re-confirm.
(Reporter)

Comment 4

16 years ago
Yeah- still happens.  Some other possibilities:

I'm using a frameset
One frame references a script like so:
<script src="/aspnet_client/1_0_0_0/xxx.js"></script>

This root URL is appended to the path, rather than replacing the path to the
frame and appears in the window like:

"http://localhost/prototype/petroLook/frameset//aspnet_client/1_0_0_0/xxx.js"

It should be:

"http://localhost/aspnet_client/1_0_0_0/xxx.js"
(Assignee)

Comment 5

16 years ago
*** Bug 130566 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

16 years ago
Target Milestone: mozilla1.0 → mozilla1.0.1

Comment 6

16 years ago
I'll add a me too, and a vote, since this bug is a real pain.

I'm getting this bug on win2k, build 2002041711. The source frame shows a 404
message like:

<H1>Not Found</H1>
The requested URL /mylibrary//includes/topmenus.js was not found on this server.
(Assignee)

Updated

16 years ago
Blocks: 141097
(Assignee)

Updated

16 years ago
No longer blocks: 141097
(Assignee)

Updated

16 years ago
Depends on: 141097
(Assignee)

Updated

16 years ago
No longer depends on: 141097
(Assignee)

Updated

16 years ago
Blocks: 141097

Comment 7

16 years ago
Confirming for Build 2002060408 / WinNT4 (and adding a vote).

Comment 8

16 years ago
There is another problem with relative URL handling that's probably related.
When the URL of the file containing the relative reference contains a query
string, wenkman doesn't remove the query string when calculating relative paths.

Suppose we have a page, <http://www.foo.com/bar/?kingkong=big>, that contains
<script language="JavaScript" src="apes/hairygorilla.js"></script>, then
double-clicking 'hairygorilla.js' in the top-left wenkman window results in
wenkman trying to load
<http://www.foo.com/bar/?kingkong=big/apes/hairygorilla.js> instead of
<www.foo.com/bar/apes/hairygorilla.js>
(Assignee)

Comment 9

16 years ago
*** Bug 154749 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 10

16 years ago
This should (finally) be fixed.  Get the latest mozilla nightly or an XPI from
<http://www.hacksrus.com/~ginda/venkman/>.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
Product: Core → Other Applications
You need to log in before you can comment on or make changes to this bug.