Open Bug 849605 Opened 8 years ago Updated 2 years ago
Dynamic change to iframe's "location
.href" is not properly maintained in DOM
Component: Untriaged → Document Navigation
Product: Firefox → Core
Maybe duplication of Bug 170799
Component: Document Navigation → DOM: Core & HTML
OS: Windows 7 → All
Version: 19 Branch → Trunk
The attachment is a tar file with all you need to reproduce the problem on your local file system. It has the various pages, called "try1.html" and "try2.html", and also has the three files that are sourced by the iframes; which are "grey.html", "red.html", and "blue.html".
I have noticed that the problem does not reliably manifest off of the web links I provided. It was reliable last night, but not this afternoon. To me, this is more indication of a timing issue. It continues to reliably manifest when operating locally, from a "file:///" location. Therefore, to be certain of seeing the problem, unpack the tar file I previously attached and access "file:///.../try1.html", etc. By my opinion, this is yet more manifestation of the likelihood that there is a timing issue. It seems that when files are delivered very fast, the problem manifests. This is a big problem for the web developer. We work with files on our local machines, and need for the browser to give consistent and correct behavior, even when the delivery of content is fast. (After all, we want fast delivery.) Summary: Use the tar file contents for testing to reliably see the bugs.
Chrome and Internet Explorer both provide a better end result on re-load. I don't necessarily endorse how they get the results; since neither of them seems to update the DOM during the in between steps. But they do always end up with the correct result displayed on the web page. Internet Explorer takes heed of and displays the re-read value of <image src="...">, Chrome does not. File "try3.html" is attached. It leaves out the calls to "console.log()", and reports "location.href" in the alert box.
Can be viewed on other browsers.
OK, this is exactly duplication of Bug 34568
Asynchronous operation need not result in an unreliable end state. In the case of "try2.html", the end state bears no resemblance to that commanded by the code. It is not a transient anomaly; the incorrect attributes are there to stay.
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046 Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5. If you have questions, please contact :mdaly.
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.