Closed
Bug 34568
Opened 25 years ago
Closed 25 years ago
the document objet in javascript don't change when window.location.href change
Categories
(Core :: DOM: Core & HTML, defect, P3)
Tracking
()
VERIFIED
INVALID
People
(Reporter: poussin, Assigned: jst)
References
Details
(Whiteboard: [nsbeta2+])
Attachments
(1 file)
|
926 bytes,
application/octet-stream
|
Details |
From Bugzilla Helper:
User-Agent: Mozilla/4.7 [en] (X11; I; Linux 2.2.5-15 i686)
BuildID: 2000022916
when i try to change URL in iframe by theiframe.location.href, the view change
but the document object in javascript is not modified
Reproducible: Always
Steps to Reproduce:
1.create a xul document with html:iframe
2.add script mozilla/xpfe/browser/src/DumpDOM.js for dump the document
3.in javascript function call by onload in window tag, get the iframe object
2.1 dump the document of the iframe window (with DumpDOM(f.document))
3.2 change the location.href (the view change)
3.3 re-dump the document of the iframe window
Actual Results: this is the result of dump in the xterm:
--------------------- DumpDOM ---------------------
<#document>
<HTML>
<HEAD>
<BODY>
------------------- End DumpDOM -------------------
change the location.href
--------------------- DumpDOM ---------------------
<#document>
<HTML>
<HEAD>
<BODY>
------------------- End DumpDOM -------------------
Expected Results: --------------------- DumpDOM ---------------------
<#document>
<HTML>
<HEAD>
<BODY>
------------------- End DumpDOM -------------------
change the location.href
--------------------- DumpDOM ---------------------
<#document>
<html>
<head>
<title>mozilla.org
... etc
example for reproduce the bug:
<?xml version="1.0"?>
<!DOCTYPE window>
<window xmlns:html="http://www.w3.org/TR/REC-html40"
xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
onload="init();">
<html:script src="/js/DumpDOM.js"/>
<html:iframe id="frame" name="frame" class="frame" flex="100%"
src="about:blank"/>
<html:script>
function init(){
f = window.frames["frame"];
DumpDOM(f.document);
f.location.href="http://www.mozilla.org";
dump("change the location.href\n");
DumpDOM(f.document);
}
</html:script>
</window>
|
||
Comment 1•25 years ago
|
||
This is actually a general DOM problem (not specific to XUL).
Basically, when 'window.location.href' is set to some string, then a
succeeding call to the window.document gets a hold of the stale
document handle.
Download the .zip attachment to a directory, unzip it and load the
file "iframer1.html".
---------------------------------------------------------
Load "iframer1.html" and click on 'call g() with no delay'
Result/ console output:
changeHref() with no delay factor
f.location.href is file:///d|/temp/simple-1.html
f.location.href is now file:///d|/temp/simple-1.html
failed to set the page title.
Document: Done (0.172 secs)
---------------------------------------------------------
Load "iframer1.html" and click on 'with setTimeout(g(),0)'
Result/ console output:
changeHref() on a 0 msec setTimeout()
f.location.href is file:///d|/temp/simple-1.html
failed to set the page title.
Document: Done (0.188 secs)
f.location.href is now file:///d|/temp/simple-2.html
---------------------------------------------------------
Notice that if the call directly follows the change in location, then
the value of location.href is incorrect (and in fact, the wrong document
is referenced).
Note also that setTimeout() is used only as a simple way to highlight
the problem -- any function that attempts to access the DOM of the
loaded document, if called immediately after the new document is loaded,
will get a handle to the wrong document. (It's not necessarily a timing
issue though).
[I have a more extended example that makes use of dumpDOM.js, but I
thought this was sufficient (and simpler)].
Assignee: trudelle → jst
Component: XP Toolkit/Widgets: XUL → DOM Level 0
QA Contact: jrgm → desale
|
|
||
Comment 2•25 years ago
|
||
|
|
||
Comment 3•25 years ago
|
||
That attachment is a 'zip' file.
|
|
||
Updated•25 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
|
Assignee | |
Comment 4•25 years ago
|
||
Moving beond beta2.
Status: NEW → ASSIGNED
Target Milestone: --- → M19
|
|
||
Comment 5•25 years ago
|
||
Nominating nsbeta2. We have to start drawing a line on DOM0 backward
compatibility; these bugs are supposed to be a high priority for nsbeta2 per the
beta2 criteria. (And this is really fundamental DOM0!)
Keywords: nsbeta2
This is needed for RTM, but we can survive beta2 without it.
Whiteboard: [nsbeta2-]
|
|
||
Comment 7•25 years ago
|
||
Rick, I'd kill or die for you, but I have to disagree on this one. Setting to
[nsbeta2+]. (It's on my delegated list from PDT.) Reasoning:
1) window.location.href is fundamental JS 1.0 DOM0
2) this call is widely used
3) if we're not even pointing at the right document object after it executes,
(a) we'll get lots of bugs filed that are a result of this, and (b) we'll miss
finding other bugs we would have found otherwise, jeopardizing quality for final
ship
4) I'm trying to ensure that we have enough core DOM0 JS working for nsbeta2
that we'll surface the other bugs that must surely be out there in time to fix
for FCS; pointing at the right document object after common calls is crucial to
that end
If you want to escalate, I challenge you to a duel to settle the question by
seeing who takes less time to successfully navigate from DC to Dulles *without*
the use of a GPS guide. (You'll still be circling on parkways while I'm relaxing
at the hotel ... ;-> )
Whiteboard: [nsbeta2-] → [nsbeta2+]
|
|
Assignee | |
Comment 8•25 years ago
|
||
I had a chat about this problem with Vidur and it turns out that this bug is
actually invalid, mozilla behaves exectly as expected here, and I even checked
what IE 5 does with the attached testcase and same thing happens there. Setting
the location of a window, frame or iframe is not a synchronous call, it just
tells mozilla to load the new URL and returns, IOW the document object in the
window/frame/iframe doesn't change untill the new document starts loading, and
this is the only way we could easily and reliably implement this, we don't know
what type of document to expect when setting the location property of a window
and thus we can not change the JS document object untill we get a responce
including the mime type for the new document) from the web server. Likewise the
location of the window doesn't change before the new document is starting to
arrive.
Marking INVALID.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
|
|
||
Comment 9•25 years ago
|
||
Per Johnney and vidur mozilla behaves exectly as expected. Marking verified.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•