301325 - iframe remembers old src when changed, even after hard refresh

Status: RESOLVED WONTFIX

(Camino Graveyard :: Page Layout, defect)

Description

[Patrick Keenan]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b3) Gecko/20050714 Camino/0.9a2
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b3) Gecko/20050714 Camino/0.9a2

I have iframes that remember their location. When I add a new iframe it goes to
the right page but then only goes to that page. I tried emptying my cache but
that didn't work.
To get the iframe to have the right src I have to make a new one each time I
want to test it. This means I now have 6 iframes on the page(5 of which are
pointing to the wrong place)

Reproducible: Always

Steps to Reproduce:
1.make an iframe
2.set the src
3.open the page
4.change the source
5.save
6.refresh

Actual Results:  
does not show the right src

Expected Results:  
shown the updates src

Comment 1

[Samuel Sidler (old account; do not CC)]

Without testing, this sounds like a core bug.

Comment 2

[Samuel Sidler (old account; do not CC)]

When you say "refresh" are you hard refreshing or soft refreshing? To do a
complete refresh, hold down shift while you press the "reload" button.

This *should* refresh all iframes.

Comment 3

[Patrick Keenan]

(In reply to comment #2)
> When you say "refresh" are you hard refreshing or soft refreshing? To do a
> complete refresh, hold down shift while you press the "reload" button.
> 
> This *should* refresh all iframes.

I did a hard refresh. Same issue.

Comment 4

[Mike Pinkerton (not reading bugmail)]

can you test in deer park alpha2?

Comment 5

[Patrick Keenan]

works fine in deerpark

Comment 6

[Patrick Keenan]

This is still an issue in Camino. It is not an issue in Deerpark.
steps:
1. create iframe on page
2. Navigate to page
3. Change iframe src(in editor)
4. refresh page
5. this will remember the old source rather than the new one

Comment 7

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Let me see if I understand:

1. Create a local HTML file that contains an iframe,
src=https://bugzilla.mozilla.org/show_bug.cgi?id=301325
2. Save the file and load in Camino; see the lovely bug in the iframe.
3. Edit the local HTML file's iframe's src, src=http://www.smfr.org
4. Save the file.  Switch to Camino and hit reload.
iframe still contains https://bugzilla.mozilla.org/show_bug.cgi?id=301325 
5. Hit shift-reload.
iframe still contains https://bugzilla.mozilla.org/show_bug.cgi?id=301325

Is this the correct series of steps to reproduce the problematic behavior?

In tonight's DeerPark, the results were the same after step 4, but a
shift-reload (step 5) did switch the iframe to http://www.smfr.org.

Comment 8

[Patrick Keenan]

seems to be working with the newest release

Comment 9

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Comment 7 still stands for me with the 20050802 build on 10.3.9 (i.e., the
iframe does not change).

Comment 10

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: testcase for local use

Does anyone else see this?  From bz's comments in some other bugs, I think
regular reload is not supposed to pick up on the changed iframe(?) but
shift-reload definitely should (and does in DeerPark).

Comment 11

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Reopening for further investigation (Samuel, Wevah, can you have a quick look?)
 See comment 7 and notes in the text of the testcase.

Comment 12

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

We're still behaving differently from DeerPark in my testing.

Comment 13

[cannedbrain+mozilla]

I can confirm this using build #2006080404. Soft/hard reload won't load the modified frame(s) even after emptying caches. What works is closing the tab/window then reopen the location (works even without emptying caches).

Comment 14

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

We really need a testcase for this that doesn't rely on local editing; Wevah, can you help?

Comment 15

[Samuel Sidler (old account; do not CC)]

Attachment: Testcase

Mossop was kind enough to make this testcase for me.

This testcase exhibits the behavior when refreshing or hard refreshing.

Of note, reloading the page by pressing 'return' in the location bar doesn't exhibit the behavior. It can only be reproduced when pretty cmd-r, shift-cmd-r or using the various menus/buttons.

Comment 16

[Samuel Sidler (old account; do not CC)]

I should mention that the testcase is supposed to randomly choose between five URIs on refresh, so in Firefox, this might (once or twice) load the same URI, but most of the time loads a different one.

Comment 17

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Mass un-setting milestone per 1.6 roadmap.

Filter on RemoveRedonkulousBuglist to remove bugspam.

Developers: if you have a patch in hand for one of these bugs, you may pull the bug back to 1.6 *at that point*.

Comment 18

[treeform]

This seams to be related to https://bugzilla.mozilla.org/show_bug.cgi?id=363840 

Comment 19

[Brian 'netdragon' Bober]

That previous one was duped. Related to bug 279048.

Comment 20

[Gordon P. Hemsley [:GPHemsley]]

This bug has been buried in the graveyard and has not been updated in over 5 years. It is probably safe to assume that it will never be fixed, so resolving as WONTFIX.

[Mass-change filter: graveyard-wontfix-2014-09-24]