473436 - Dynamic iframe shows wrong content when using soft-refresh or back button.

Status: NEW

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

Description

[Jeremy Dunck]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.5) Gecko/2008120121 Firefox/3.0.5
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.5) Gecko/2008120121 Firefox/3.0.5

I'm attaching a simplified test case.


Reproducible: Always

Steps to Reproduce:
1 When this page is first loaded, the frames should say "Stupid" and "I'm with Stupid".
2 Perform a soft refresh, or click "Go somewhere else" and then use the back button.


Actual Results:  
Both frames will now say "I'm with Stupid".

Expected Results:  
Expected behavior was that the frames would say "Stupid" and "I'm with Stupid" as before.

A soft refresh continues this unexpected behavior.
A hard refresh reverts to the expected behavior.

Comment 1

[Jeremy Dunck]

Attachment: Testcase attached.

Comment 2

[Nochum Sossonko [:Natch]]

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5

This page works fine for me. Please try this in safe mode http://support.mozilla.com/en-US/kb/Safe+Mode

Comment 3

[David Gouldin]

The bug was still present using safe mode, Firefox 3.0.5, OSX 10.5.6, attempted here:

http://www.watching-cars.com/test/iframe_cache_test.html

Boxes appear red and blue, soft refresh (cmd-r), both boxes appear red.

Comment 4

[Nochum Sossonko [:Natch]]

Ok, just reproduced it with the following str:
1) go to the page, hit "go somewhere else"
2) hit the back button
3) hit refresh.

I'm pretty sure there's a dupe on this though.

Comment 5

[Jeremy Dunck]

How long should a bug stay in Unconfirmed/DUPEME?
Also, who decides assignee if it goes to NEW?

Comment 6

[Nochum Sossonko [:Natch]]

Jeremy: would you like to patch this bug? If you do, upload the patch and someone will certainly assign it to you.

Over to Core->DOM for better triage.

Comment 7

[Jeremy Dunck]

Natch,
  Yes, I would like to fix the bug-- but I haven't done any development on Firefox before.  I've reproduced this bug with Firefox 2.x and with trunk, so it definitely hasn't been a recent change or something only in 3.x.

  Can you suggest any pointers to attack this bug?  I'm not really familiar with the codebase.  I can read https://developer.mozilla.org/en/Developing_Mozilla but is there anything specific to this bug you could suggest as a starting point to narrow it down?

Comment 8

[Nochum Sossonko [:Natch]]

(In reply to comment #7)

I can't, but I can try to get you someone that can. ;)

Confirming. This is probably in the wrong product/component as it seems to be related to the cache...

Comment 9

[Boris Zbarsky [:bzbarsky]]

It's almost certainly a duplicate.  Please look through the existing bugs on reload and dynamically created iframes....  I'm pretty sure cache is not involved, and that the fact that session history can't deal with iframes moving around in the DOM is.

Comment 10

[Nochum Sossonko [:Natch]]

bug 462076?

Comment 11

[Boris Zbarsky [:bzbarsky]]

Let's mark dependent on that for now and see how things look once that's fixed, yeah.

Comment 12

[Brett Hoerner]

Yeah, attachment 345699 [details] [diff] [review] on bug 462076 fixed the test case on a recent 1.9.1 checkout.

I guess the only problem is in comment #8 of bug 462076, "This unfortunately makes our history data way too large." https://bugzilla.mozilla.org/show_bug.cgi?id=462076#c8

Comment 13

[Oded Arbel]

Attachment: A test case showing the problem

The original test case points to pages that no longer exist. This updated test case points to pages that still don't exist but at least report the URL used to call them, so the problem can be seen.

With this test case a first load shows errors for "frame1" and "frame2", while a reload shows errors for "frame2" and frame2"

Comment 14

[Oded Arbel]

I can't reproduce this behavior on the web, ATM, though loading the file locally it does sometimes happen. This is probably related to bug #527897, though this specific use case should work correctly considering the behavior documented there.

Comment 15

[Olli Pettay [:smaug][[e-mail]]]

So what is the working testcase for this?

Comment 16

[Oded Arbel]

bug #527897 has a few related bugs with good test cases that still work. The last test case I uploaded here (attachment #411741 [details] which is just the original test case with iframes that show the URL being called in the 404 error) does not reproduce the problem using the original instructions, but I can get an invalid behavior using the following use case:

1. load the test case
2. click "go somewhere else".
3. Clear the cache
4. click back.
The test case page would now show "frame2" for both frames.

I'm not sure if its the same problem, though.

Comment 17

[Olli Pettay [:smaug][[e-mail]]]

So can anyone still reproduce this on trunk?

Comment 18

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