849605 - Dynamic change to iframe's "location.href" is not properly maintained in DOM

Status: RESOLVED DUPLICATE of bug 34568

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

Description

[Alexander Danel]

Attachment: iframe-DOM.tar

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0
Build ID: 20130307023931

Steps to reproduce:

Found that when the "location.href" of an iframe is updated in javascript, the page display changes, but the value of string "location.href" in the DOM is not reliably changed, or rather, is reliably not changed.  The fact is reflected in "console.log()" messages, and shows up visibly to the user when the "reload" button is pressed.

I have created a minimal demonstration file plus companion files.  The companion files are what gets loaded into the iframe.  I can reliably get three different outcomes from identical or nearly identical code -- the difference being sequence of events and the timing of events.  None of these outcomes is correct; "location.href" is never properly maintained, as is evidenced by looking at "console.log()" output.

I suspect this problem has been around for a long time.  Bugzilla 237760 from way back in 2004 got "fixed" by halting recursion; but that didn't get at the root cause.  

To get the first incorrect outcome, open "firebug" and enable the console.  Now load the following little demo page:

    http://level-x.biz/client-portal/bug01/try1.html

Looks fine on screen, but if you check what the console prints, versus what you would expect the console to print, (based upon reading the code,) you will see something is wrong; namely, although the web page is being displayed ok, the DOM is not reflecting what is going on there.  The "location" gets changed, but the "location.href" string in the DOM apparently does not.

Actually, the string does get updated; but with delay; the second action will show this.  It will also show that the "src=" in the HTML <iframe> does not have affect, at least not in real time.  This causes a problem for the user, as I will explain.

The second action to perform is to just hit the "reload" button, like an ordinary user might do.  Again, check the console on your browser.  You will see that "location.href" now reflects what should have been the end state from action one.  So action one did update "location.href", but with delay.  And now, that state is not being changed in the DOM, at least not in real time.  This causes a problem for the user because <iframe src=...> is not registering in time, and so the user cannot return to a pristine state.  (In an app more complicated than my demo, an iframe might go through several transformations.  The user might want to return to the start state by pressing "reload", but can't.  This was the problem that drove me to discover the bug; I need to let the user get back to the pristine state, but can't.)  

The third action further demonstrates that there is a major timing issue happening here.  To execute the third action, and to see the third set of weird results, open a new tab, again with firebug console open, and load this URL:

    http://level-x.biz/client-portal/bug01/try2.html

This is the identical code as before, with one exception -- some alerts are put into place to separate the logging events.  Pay careful attention to the console output of the initial load; the delay allows some but not all of the updates to "location.href" in the DOM to happen.  Amazingly, the end result displayed on the web page is wrong; it ends with the wrong file displayed!  

The situation can be further explored by doing an ordinary "reload".  Because the alert()s stop the action, one can see that updates are not happening to the display.



Actual results:

What happened?

With initial load of "try1.html", the console prints "grey", "grey", and "grey".

With reload of "try1.html", the console prints "blue", "blue", and "blue".

With initial load of "try2.htm", the console prints "grey", "grey", and "red".  Furthermore, the "red" file ends up displayed.

With the reload of "try2.html", the console prints "red", "red", and "red".  Furthermore, the "red.html" file is displayed throughout.



Expected results:

What should have happened?

With every load and reload, the console should have printed "grey", "red", "blue".

With the load of "try2.html", since we have time to observe, we should see the loading of files "grey.html", then "red.html", then finally "blue.html"; for both the initial load and the reload.

Comment 1

[Alice0775 White]

Maybe duplication of Bug 170799

Comment 2

[Alexander Danel]

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

Comment 3

[Alexander Danel]

It is clearly not a duplication of 170799, although I can't rule out that 170799 might also get fixed if the new bug 849605 is fixed.  This new bug has a less complicated manifestation; unlike the old bug which involved destroying and recreating frames or framesets, nothing like that is going on in the new bug.  The new bug manifests just from assigning to "location.href", a very basic operation.

By the way, when I say "new bug", please understand I suspect the problem has been present in Firefox for many years.  What is new is the bug report and the accompanying demonstration code.

Because it seems that timing is involved, this might be very difficult for the Firefox programmers to debug.  The root cause of the bug might be in a fundamental premise about the operations of the browser; so you might have to dig deep.  (See also my last paragraph, below.) On the other hand, it is worth the effort -- the root cause of the problem illustrated here is quite possibly also the root cause of some other problems.  Here is an opportunity to stop writing work-arounds and get to a real fundamental fix that results in a markedly cleaner product.

This is a pernicious bug; it can cause a web developer to cry.  The state of the DOM should change in an order that is strictly determined by the web developer using the javascript; but instead, the DOM is being changed in an order of events that is mysterious.  

Even ignoring the possibility of other problems caused by the same root cause, the problems already reported in this bug report have serious negative consequences.  This bug causes javascript to subvert html.  When re-loading a page, we have a right to expect that if the html says <iframe src="grey.html"> and nothing else is causing a change to the iframe, then the iframe should indeed contain the file "grey.html" -- but with this bug, that is not true.  With this bug, if prior navigation involved a javascript assignment to "location.href", then the old value stored there determines the re-load, and the html "src=..." is not effective.

I believe the reason the "src=..." is not effective is due to a timing issue.  I believe the sequence of events goes like this:

    *) Assumption is that some prior javascript activity has changed 
       "location.href", so "location.href" == "blue.html".
    *) User presses [re-load] browser button.
    *) Browser re-reads the html.
    *) Browser sees <iframe src="grey.html"> and notes that it should 
       update the matching value in the DOM for the iframe; 
       HOWEVER, execution of this update to the DOM is delayed.
    *) Browser pulls in the file for the iframe, using the current
       value of the iframe's "location.href", which is still "blue.html"!
    *) I have no idea what happens to the delayed DOM update, 
       maybe it gets lost, maybe overwritten by "blue.html", 
       maybe value ends up being "grey.html".

This begs the question: Why would Firefox have a delayed update to the DOM?  One guess is that the update of the DOM is scheduled to happen asynchronously and only after successful file load.  Someone might have chosen to do it this way so that a failed load does not change the DOM.  If that's happening, then I suggest the behavior should be changed to the following: save the old value of "location.href" to a temp variable, do the update to the DOM to reflect the intended file, then do the file load asynchronously, and then if the load fails come back and restore the DOM value to whatever is appropriate.

Alexander Danel

Comment 4

[Alexander Danel]

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.

Comment 5

[Alexander Danel]

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.

Comment 6

[Alexander Danel]

Attachment: Similar main page, but without "console.log()"; has info in alerts.

Can be viewed on other browsers.

Comment 7

[Alice0775 White]

OK, this is exactly duplication of Bug 34568

Comment 8

[Alexander Danel]

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.

Comment 9

[Firefox Bug Husbandry Bot]

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.

Comment 10

[Anne (:annevk)]

This is how location works by design. Changing this would require changing the HTML Standard first.