49312 - Setting window.location to a relative URL in a javascript: URL does not work

Status: RESOLVED FIXED

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

Description

[bht237]

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

Comment 1

[bht237]

Attachment: Frameset

Comment 2

[bht237]

Attachment: Frame

Comment 3

[Johnny Stenback (:jst)]

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...

Comment 4

[bht237]

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.

Comment 5

[Johnny Stenback (:jst)]

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.

Comment 6

[dannyg]

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.

Comment 7

[Ilya Konstantinov]

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

Comment 8

[Johnny Stenback (:jst)]

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

Comment 9

[Johnny Stenback (:jst)]

Attachment: Proposed fix.

Comment 10

[Johnny Stenback (:jst)]

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

Comment 11

[Johnny Stenback (:jst)]

Pushing to mozilla0.9.7

Comment 12

[Fabian Guisset]

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.

Comment 13

[Johnny Stenback (:jst)]

Pushing to mozilla1.0

Comment 14

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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

Comment 15

[scottputterman]

nsbeta1- per ADT triage.

Comment 16

[Jess Collicott]

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.

Comment 17

[Johnny Stenback (:jst)]

Mass-reassigning bugs to [e-mail]

Comment 18

[john russell]

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!!! 

Comment 19

[Fabian Guisset]

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

Comment 20

[Bill Mason]

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

Comment 21

[Tim Moose]

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

Comment 22

[Boris Zbarsky [:bzbarsky]]

The patch in bug 445004 will fix this.

Comment 23

[Boris Zbarsky [:bzbarsky]]

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.

Comment 24

[Boris Zbarsky [:bzbarsky]]

Attachment: The test

Comment 25

[Boris Zbarsky [:bzbarsky]]

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