improper relative path on script referred to from other frames

NEW
Unassigned

Status

()

P5
major
18 years ago
6 months ago

People

(Reporter: brkemper, Unassigned)

Tracking

(Blocks: 2 bugs, {testcase})

Trunk
testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

3.70 KB, application/x-zip-compressed
Details
(Reporter)

Description

18 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.2) Gecko/20010629
BuildID:    2001062823

In a framed environment, I have javascript functions in the main frameset that
are called by handlers in a separate document in one of the frames. It calls it
in this manner: 

onclick="parent.theFunctionName('parameters')"

The parent frameset document and the child frame document are in two different
directories. The function in the parent frame refers to images it needs by way
of a relative URL, similar to this:

myPicture.src = "../images/picture1.gif"

The path is relative to the parent frameset that contains the function. This has
always worked with other browsers. In Mozilla browser, however, it does not. It
seems to require the path to be relative to page calling the function. 

That just seems wrong. That would be correct behavior if the function was in an
external .js file that was linked to by the child frame, but that is not the
case here. The path should be relative to the function that is dealing with it,
which in this case is in the outer parent frameset.



Reproducible: Always
Steps to Reproduce:
See above.

Actual Results:  script does not work correctly.

Expected Results:  It should have interpretted the relative path as being
relative to the page that contained the function definition.
Over to DOM0
Assignee: rogerl → jst
Component: Javascript Engine → DOM Level 0
QA Contact: pschwartau → desale

Comment 2

18 years ago
Reporter, does this still happen using Mozilla 0.9.4?
(Reporter)

Comment 3

18 years ago
Yes. Still happens using Mozilla 0.9.4.

Comment 4

18 years ago
Reporter, can you either attach your testcase or put it up on a server somewhere it can 
stay available until this bug is resolved?

Comment 5

17 years ago
Reporter, can you still reproduce this using 0.9.5?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: 4xp
OK... I can't reproduce this with the original site and a current nightly.  I
see the images.  Furthermore I put together a testcase at
http://www.zbarsky.org:8000/~bzbarsky/foo/imagetest.html and it's handled
identically by IE, NS4, and Mozilla -- the url is relative to the child, not the
parent.
WORKSFORME, there are issues on the page, but I can't see any problems with
relative URL's. My guess is that some of the problems are related to our
currently broken dynamic loading of images, and there are bugs on that already.
If there's really a problem with relative URL's, create a simplified testcase if
possible and reopen this bug.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 8

17 years ago
Created attachment 63251 [details]
Zipped directory with sample

Test Case. Unzip file, then open "frameset.html" from that directory.
Attachment #63251 - Attachment mime type: text/plain → application/x-zip-compressed
(Reporter)

Comment 9

17 years ago
In case that attachment didn't help you, here is a new URL that illustrates 
the problem:

http://home.attbi.com/~brkemper/PathProblem/frameset.html

Also this link shows what it looks like in Mac IE:

http://home.attbi.com/~brkemper/NetscapeRender.gif

vs. Mac Netscape:

http://home.attbi.com/~brkemper/IERender.gif
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(Reporter)

Comment 10

17 years ago
Whoops, I had those last two URLs reversed. Sorry. Should be:

This link shows what it looks like in Mac IE:

http://home.attbi.com/~brkemper/IERender.gif

vs. Mac Netscape:

http://home.attbi.com/~brkemper/NetscapeRender.gif
I get the "Incorrect replacement" graphic in Netscape 4.x/Win.  I get the 
"correct replacement" graphic in IE 5.0/Win.  jst, could you test with a newer 
IE version?
(Reporter)

Comment 12

17 years ago
Interesting. I didn't realize NN4.x would do it incorrectly too. It seems that if 
the variables for the images are declared outside the function then NN4.x 
will handle it correctly, but Mozilla will not. I updated the code on my site. 
Pass your mouse over the bottom picture to see it replaced with the 
correct graphic now in NN4.x, then look at the source code for the 
frameset.

http://home.attbi.com/~brkemper/PathProblem/frameset.html
(Reporter)

Comment 13

17 years ago
I just tested in Mozilla .9.7, and the problem still exists.

Comment 14

17 years ago
problem still in 0.9.7 - it also appears without any java script. If in a frame 
environment a new frame document is opened, which is in a different directory 
than the calling document, all relative paths in the new frame document are 
relative to the calling document, not to the newly opened one.

check out http://www.iai-ev.de/spezifikation/Ifc2x/index.htm
(click on schema listing in upper left frame, than on first arrow (this opens a 
new document in the frame below, which is in a different directory), now click 
on any link in that middle left frame - links do not work, as they are not 
relative to the new document) - it works however in IE and NS4x.

Correct should be to always have path relative to the document, where the link 
is inserted.

Comment 15

17 years ago
short correction - my previous report was wrong, since the error does not appear
if you reach the page (in the given http:// example) through "schema listing" -
it actually works.

However if you select in the upper left frame "architectural diagram", and then
click on any box in the picture (right frame, being an image map), a new
document opens in the middle left frame. Now clicking on a link there does not
work (wrong relative path).

differences:
- page is opened from an image map
- page is opened by "document_dir\document_name.html", instead of
"document_dir/document_name.html" (as when clicking on "schema listing")

when I changed (in a local copy) all links within the image map (file
order_by_architecture.html) by replacing "\" with "/" it works fine. Could that
be a hint?
URLs including "\" are invalid and so I doubt your testcase is related to this
bug (which has a testcase with valid urls that demonstrates the problem).

I'm seeing exactly what Brad is seeing on Linux.  Setting OS/Platform = all.
OS: Mac System 9.x → All
Hardware: Macintosh → All

Comment 17

17 years ago
Severity = MEDIUM [No Crash, No severe functional failure, Results in Cosmetic 
failure]
Visibility = MEDIUM [Dont see any real world website usage, Gets one point of 
compatibility with other browsers since it works on other browsers. gets one 
more point on compliance with adopted techonology, that is JS] 

Priority = Visibility * Severity

Priority = p3

adding word "qawanted" because I'm setting this priority on available data & if 
someone feels otherwise then please investigate this more & feel free to change 
this priority.
Keywords: qawanted
Priority: -- → P3

Comment 18

17 years ago
Reporter [Brad] sent me following email I'm pasting. 

"Thank you for reviewing and setting the priority. Actually, this does effect
a real world Web site that I author. I currently have a work around that
involves using absolute URLs everywhere instead of relative ones. This makes
testing my pages on a test system very problematic. I don't know if that
effects your rating of "medium severity" or not. The site I author is at
http://providentcu.org and https://accountmanager.providentcu.org ."

This means that there is real world web-site usage & also it is affecting Brad's 
testing process. If Brad can use this in web site he authors there could be 
multiple websites out there. Boosting visibility to HIGH. 

Severity = MEDIUM 
Visibility = HIGH

Priority = Visibility * Severity

Priority = p2
Priority: P3 → P2

Comment 19

17 years ago
adding testcase keyword in order to remove from BugAThon testcase needed list.
(seems it has one already)
Keywords: testcase

Comment 20

16 years ago
*** Bug 134929 has been marked as a duplicate of this bug. ***

Updated

16 years ago
Blocks: 141002
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs
Status: REOPENED → NEW
OK, so the basic problem as I understand it is that when we call new Image() the
image doesn't have a document so it gets one from the caller.  It does this by
calling nsContentUtils::GetDocumentFromCaller(), which calls
nsContentUtils::GetDynamicScriptGlobal() which calls
GetScriptContextFromJSContext().

So the point is, the Image object is created in the JS context the code is
running in, which is the calling code's context.

Brendan, is that right?  Is there a way we could create it in the callee's
context?  Would there be security issues with that?

In case anyone cares, my testing shows:

NS4, Konqueror 3.0.3 act like Mozilla.
Opera 7 acts like IE.

Comment 23

14 years ago
Created attachment 159076 [details]
Sample case showing incorrect handling of relative addresses

Zip file containing very simple (3 files) sample case with pure html

Comment 24

14 years ago
Comment on attachment 159076 [details]
Sample case showing incorrect handling of relative addresses

Issue related to the use of backslahes, rather than forward slash.
Unfortunately because IE handles them in the same way, people (like me!) get
lax.  Sorry.
Attachment #159076 - Attachment is obsolete: true
Assignee: general → nobody
QA Contact: desale → general

Comment 25

5 years ago
This works fine for me on the latest Nightly. The "Correct Replacement" and "Original Image" images are displayed when loading the attached test case.

Can anyone still reproduce this issue with other cases?
Keywords: qawanted
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven't been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.
Priority: P2 → P5
You need to log in before you can comment on or make changes to this bug.