523418 - Mozilla loads incorrect URL from the cache in an iframe on a new page.

Status: RESOLVED DUPLICATE of bug 517381

(Core :: DOM: Navigation, defect)

Description

[Oded Arbel]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.3) Gecko/20091007 Ubuntu/9.10 (karmic) Firefox/3.5.3
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.3) Gecko/20091007 Ubuntu/9.10 (karmic) Firefox/3.5.3

This is a weird one and I'm not sure that the cache is really at fault here, but here is how to reproduce:


Reproducible: Always

Steps to Reproduce:
1. Make sure you have some sort of network tracker, otherwise this issue can't be easily seen. I use firebug's network monitor and I verified with external tools that its output is correct.
2. go to the URL as specified in the bug: the code is very simple (take a look) and does the following:
  * A function is used to send HTTP events to a remote server by adding an iframe with a specific URL (in a real implementation the iframe will be of course hidden), and when the response finishes loading it will remove the iframe.
  * When the page loads it immediately fires two events: "correct1" and "correct2". Verify this with the network tracer.
  * A button allows to send a third event called "wrong".
3. After the page has finished loading and the two initial iframes where removed, click the "Start broken behavior" button to fire the "wrong" event.
4. Reload normally and watch the network tracer (not shift reload or any cache clearing mechanism).

Actual Results:  
The tracer will show that the two events being sent on page load are now "wrong" and "correct2".

Expected Results:  
The tracer should show Mozilla loading "correct1" and "correct2" as expected from the script.

Use normal refresh again to watch the same behavior. Use SHIFT+reload or clear cache before reloading to reset the behavior to the working mode.

I've tested this on Firefox 3.0 and 3.5.3, on Windows x86 and Linux x86 and x86_64 - all exhibit the exact same behavior.

Commenting out the onload function that removes the iframe makes the problem goes away. This problem also doesn't happen if the first call is made after window.onload finished processing - adding a window.setTimeout() for the initial iframe calls - event with a zero timeout - also works around the problem.

I've set the severity as "major" even though the problem looks to be marginal, because it indicates some seriously broken code.

Comment 1

[Oded Arbel]

I think this is possibly related to bug #517381, as the behavior described there is similar in that an iframe is generated with a new src URL but an old URL is retrieved instead.