Closed
Bug 49312
Opened 24 years ago
Closed 16 years ago
Setting window.location to a relative URL in a javascript: URL does not work
Categories
(Core :: DOM: Core & HTML, defect, P3)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
FIXED
mozilla1.3final
People
(Reporter: bht237, Unassigned)
References
Details
(Keywords: dom0, Whiteboard: [HAVE FIX])
Attachments
(4 files)
(deleted),
text/html
|
Details | |
(deleted),
text/html
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
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 3•24 years ago
|
||
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...
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
OS: Windows 95 → All
Hardware: PC → All
Summary: JavaScript window.location does not work in frame → Setting window.location to a relative URL in a javascript: URL does not work
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•24 years ago
|
||
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.
Target Milestone: --- → Future
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•23 years ago
|
||
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•23 years ago
|
||
Unfuturing, but I don't know when I'll have time to work on this.
Target Milestone: Future → mozilla0.9.5
Comment 9•23 years ago
|
||
Updated•23 years ago
|
Whiteboard: [HAVE FIX]
Comment 10•23 years ago
|
||
*** Bug 74236 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Comment 12•23 years ago
|
||
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.
Updated•23 years ago
|
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Updated•23 years ago
|
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Updated•23 years ago
|
Johnny, could you explain this fix so we could get some reviews?
Comment 16•22 years ago
|
||
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.
Updated•22 years ago
|
Target Milestone: mozilla1.0 → mozilla1.1alpha
Updated•22 years ago
|
Target Milestone: mozilla1.1alpha → mozilla1.3alpha
Updated•22 years ago
|
Target Milestone: mozilla1.3alpha → mozilla1.3final
Comment 17•22 years ago
|
||
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs
Status: ASSIGNED → NEW
Comment 18•21 years ago
|
||
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!!!
Updated•21 years ago
|
QA Contact: desale → ian
Updated•21 years ago
|
Comment 19•21 years ago
|
||
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•21 years ago
|
||
*** Bug 239921 has been marked as a duplicate of this bug. ***
Comment 21•21 years ago
|
||
www.bankone.com's new website is broken by this bug (the little orange "go" buttons)
Comment 23•16 years ago
|
||
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•16 years ago
|
||
Comment 25•16 years ago
|
||
Fixed by checkin for bug 445004. I checked in the test.
Flags: in-testsuite+
Updated•16 years ago
|
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•