99689 - improper relative path on script referred to from other frames

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect, P5)

Description

[Brad Kemper]

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.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Over to DOM0

Comment 2

[Greg K.]

Reporter, does this still happen using Mozilla 0.9.4?

Comment 3

[Brad Kemper]

Yes. Still happens using Mozilla 0.9.4.

Comment 4

[Greg K.]

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

[Greg K.]

Reporter, can you still reproduce this using 0.9.5?

Comment 6

[Boris Zbarsky [:bzbarsky]]

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.

Comment 7

[Johnny Stenback (:jst)]

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.

Comment 8

[Brad Kemper]

Attachment: Zipped directory with sample

Test Case. Unzip file, then open "frameset.html" from that directory.

Comment 9

[Brad Kemper]

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

Comment 10

[Brad Kemper]

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

Comment 11

[Boris Zbarsky [:bzbarsky]]

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?

Comment 12

[Brad Kemper]

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

Comment 13

[Brad Kemper]

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

Comment 14

[liebich]

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

[liebich]

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?

Comment 16

[Boris Zbarsky [:bzbarsky]]

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.

Comment 17

[Prashant Desale]

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.

Comment 18

[Prashant Desale]

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

Comment 19

[Bartosz Wucke]

adding testcase keyword in order to remove from BugAThon testcase needed list.
(seems it has one already)

Comment 20

[Daniel Wang]

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

Comment 21

[Johnny Stenback (:jst)]

Mass-reassigning bugs to [e-mail]

Comment 22

[Boris Zbarsky [:bzbarsky]]

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

[Adrian]

Attachment: Sample case showing incorrect handling of relative addresses

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

Comment 24

[Adrian]

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.

Comment 25

[Ioana (away)]

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?

Comment 26

[Firefox Bug Husbandry Bot]

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.

Comment 27

[Anne (:annevk)]

WORKSFORME per comment 25.