From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; m18) Gecko/20000815 BuildID: 2000081508 JavaScript window.location does not work in a frame unless the URL is fully qualified. Reproducible: Always Steps to Reproduce: Please use 2 attached files to verify Actual Results: Frame is empty Expected Results: Frame contains file

Ok, turns the problem is that the page uses a javascript:'<html...' URL and in the HTML in the javascript: URL there's a script tag that sets the location to a relative URL. Now, the problem is that when the script that sets the location is svaluated the 'base' for the relative URL is the javascript: URL, not the URL of the document where the javascript: URL is. This seems odd to me, I'm not sure that this is really a bug, but mozilla handles this differently than 4.x so I guess we should fix it...

Johnny, I have thought about this again after your comments - theoretically it is not an error: The scripted frame has a javascript: URL that is seemingly unrelated to any file directory (local or server). But practically, it should be forced to inherit the base from the parent frame for the following reasons: - Cross frame security. Depends how this is implemented but I guess that it is easier to evaluate this after it is established that the scripted frame inherits the base URL from the parent. I haven't tested it yet, but there might be surprises on secure framesetters where hybrid pages trigger ugly security warnings. - It's the only thing that makes sense. There is no relative URL with respect to a javaScript: base. The javascript URL base has no later uses. It could be compared with wysiwyg:// URLs, where Navigator inherits from the parent, too. - Versatility, efficiency from experience. There are, depending on browsers, 3 different interpretations as to where JavaScript gets the base from when constructing an absolute URL from a relative argument. 1) the base of the document from where the event originates (e.g. form element, javascript: URL) 2) the base of the old document that the new document replaces 3) the base of the document that contains the script statement that finally loads the document 1) is the most useful method, basically what Navigator has been doing in all versions. But as it happens in the cases of javasript: and wysiwyg://, usable base URLs don't always exist. In such cases it is safest to use the base of the parent, because it even works in top.

I do think this should be fixed, but unfortunately... This bug has been marked "future" because the original netscape engineer working on this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug,or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.

I have many "JavaScript Bible" example listings that utilize this technique (javascript: pseudo-URLs for SRC attributes) and have worked for numerous previous browsers. If it doesn't work in NN6 (and I will have to point this out in the new 4th edition), it will appear to be a step backward for NN. If you intend to continue to FUTURE this bug, let me know now so that I can stamp these examples as NO-NN6.

Curiously enough, window.location.href provides the desirable effect (just as it is on Netscape 4, Internet Explorer and Konqueror), while window.location differs in Mozilla (takes the base URL for relative URLs according to the changed frame, not the executing frame) while all other browsers see it just like they see window.location.href. Why is a serious Javascript incompatibility with all other implementations around is assigned "future"? Also, please set the Summary to something more correct, such as: frame.location assumes relative URLs as relative to the frame's base

Unfuturing, but I don't know when I'll have time to work on this.

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

Pushing to mozilla0.9.7

Ping ping, just wondering, are we futuring, or fixing, this thing, that is bugging, our sibling? Seriously now: what about the patch in this bug? :-) I'm not sure I understand it.

Pushing to mozilla1.0

Johnny, could you explain this fix so we could get some reviews?

nsbeta1- per ADT triage.

rv:1.1b; Gecko/20020730 I am having the same problem without using frames. If I use a relative URL, the page just refreshes. If I use a fully qualified URL, the page goes to the assigned URL. Both methods route to the assigned URL in IE 6. Since it was asked if this bug was a concern, I was going to use this in a client's project in a certain area to reduce download time considerably, but if I want it to be compatible with Mozilla (and other flavors) I have to leave it as is or try some workaround. Personally, I'd rather assign a relative URL (have multiple environments) using this method.

Mass-reassigning bugs to dom_bugs@netscape.com

this also affects stylesheets which are relative addressed within a dynamic page jumped to with javascript:... it means that instead of an external style.css the styling has to be buried in a style tag... Thiscould lead to author maintenence problems that style sheets are designed to overcome these also woked in net4 as well as msie and opera!!!

the patch in this bug (from jst, 2001) has never been checked in. Bug still happens. I don't understand the fix, tho.

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

www.bankone.com's new website is broken by this bug (the little orange "go" buttons)

The patch in bug 445004 will fix this.

Note that this particular testcase got fixed by the "fix" for bug 162128, but bug 445004 fixes it for real. I'll try to go through and write a test that shows the difference.

Fixed by checkin for bug 445004. I checked in the test.