Closed Bug 34568 Opened 24 years ago Closed 24 years ago

the document objet in javascript don't change when window.location.href change

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED INVALID

People

(Reporter: poussin, Assigned: jst)

References

Details

(Whiteboard: [nsbeta2+])

Attachments

(1 file)

testcase; window.location.href not updated in js api calls
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>
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
That attachment is a 'zip' file.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Moving beond beta2.
Status: NEW → ASSIGNED
Target Milestone: --- → M19
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-]
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+]
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: 24 years ago
Resolution: --- → INVALID
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.

Attachment

General

Creator:
Created:
Updated:
Size: