Closed Bug 279048 Opened 20 years ago Closed 14 years ago

dynamically created iframe in a static page doesn't refresh source url on reload

Categories

(Core :: DOM: Navigation, defect)

Product:
Core
Component:
DOM: Navigation
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: pavel, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: helpwanted)

Attachments

(2 files)

Test case 1
1.34 KB, text/html
Details
PHP bug reproduction
1.10 KB, text/plain
Details 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

Here is a sample code, demonstrating the issue:

Sample 1.

<HTML><BODY>
<script language="JavaScript">
   var now = new Date();
   var url = now.getTime() % 2 ? 'http://www.yahoo.com/' : 'http://www.google.ca/';
   document.write(url);
   document.write('<br>');
   document.write('<iframe src="'+url+'" width=700 height=300></iframe>');
</script>
</BODY></HTML>

When the page with this code loads first time, it works correctly, loading into
IFRAME a "randomly" chosen Yahoo or Google home page
(the url the page loaded will be written above the IFRAME).
Logically, on multiple refresh this code should recreate iframe, rotating its
content between Yahoo and Google.
However, the page first loaded will then reappear on every reload of the page.
This effect is for static pages only:
it doesn't appear when the same code is generated by a PHP script, but may be
emulated by explicitly adding the Last-Modified header.

This isn't an effect of page caching: it also reappears if the caching is
switched off.
Moreover, if the url loaded returns a variable content, it will be rotating in
the IFRAME either.

This effect is specific for Gecko-based browsers: IE and Opera both properly
rotate content of the page presented.

This (mis)behavior in some situation creates real problems (ie, if the url to be
rotated returns content with a short lifetime).


For myself, I solved the problem at last by using the next code:

Sample code 2.

<HTML><BODY>
<script language="JavaScript">
   var now = new Date();
   var url = now.getTime() % 2 ? 'http://www.yahoo.com/' : 'http://www.google.ca/';
   document.write(url);
   document.write('<br>');
   document.write('<iframe name="random_iframe_name" width=700
height=300></iframe>');
   document.write('<scr'+'ipt
language="JavaScript">this.random_iframe_name.location="'+url+'";</scr'+'ipt>');
</script>
</BODY></HTML>

...
which, nevertheless, can be hardly regarded as a general solution.


Reproducible: Always

Steps to Reproduce:
1. Create a static page with the first sample code presented
2. Setup Firefox or Mozilla browser to block page caching
3. Load the page created into the browser and then reload it few times with
refresh button

Actual Results:  
Only first time the iframe content is loaded correctly. Then, while refreshing
the page with Refresh button, it keeps reloading content of the first generated
source url

Expected Results:  
On each refresh, the correct url should be used.
The URL loaded in the iframe is restored from session history.  That's the
expected behavior for a regular reload operation....
Reporter's case sounds that next situation is included.
(1) URI-1 & URI-2 are cached.
(2) Last displayed IFRAME's URI is URI-2
(3) Reload Main-HTML
    GET Main-HTML-URI with Last-Modified-Since
    304 not modified => Uses cache data
(4) JavaScript changes IFRAME's URI to URI-1
(5) GET URI-1 with Last-Modified-Since
    304 not modified
    => IFRAME's content isn't changed to URI-1's content(Still URI-2's content)
If Main-HTML is PHP code, HTML stream is returned instead of "304 not found" at
step(3), then IFRAME's content is changed by step(5).

Pavel Natapov, can you attach HTTP header log when "Reload" by Live HTTP Headers?
See http://livehttpheaders.mozdev.org/index.html for Live HTTP Heders.
Boris, change according to step (4) & (5) is not applied to display of IFRAME
when Reload?
It's applied, but then the session history changes what's loaded in the iframe,
I would bet.
Attached file Test case 1 — 
Test case 1, with next modification on reporter's case.
 (1) URLs are changed to google.ca & google.jp
 (2) IFRAME is hard coded in HTML instead of generating by JavaScript.
 (3) URL change is done by changing SRC attribute value by JavaScript.
Sorry.
Problem cannot be recreated by HTML on Bugzilla ("If-Mofified-Since:" is not
requested by Mozilla on HTTP GET for mail HTML.)

Test case-1 1 is placed at   
 http://www.h2.dion.ne.jp/~radon/test/302-redirect-test-1.html

Test case-2.
 http://www.h2.dion.ne.jp/~radon/test/302-redirect-test-1.html
Difference from test case 1 - onLoad='change_url("iframe-01");' is added on
<BODY>, where change_url issues IFRAM.src = google.ca or google.jp.

When test case-1, HTTP GET for IFRAME is sent to cached URL(last displayed URL),
instead of changed URL written in SRC attribute of IFRAME by Script.
This was same as reporter's case, script generated '<IFRAME SRC=new URL>' case.

In test case-2, SRC change is done again by onLoad Script.
HTTP GET was sent to old URL first as test case-1, then HTTP GET was sent to new
URL according to SRC change by onLoad Script.
  http://www.h2.dion.ne.jp/~radon/test/302-redirect-test-2-http-log.txt
   - When google.ca is displayed, script changed IFRAME's URL to google.jp
     both at just after <IFRAME> tag and in onLoad script.  

I think this bug's symptom can be said as ;
  When HTTP GET is issued with If-Modified-Since:
  because main HTML is cached and Reload request,
  and when "304 Not Modified" is returned to the HTTP GET,
  SRC URL change of elements in HTML by JavaScript before onLoad is ignored. 
I created Test case-3, JavaScript generated IFRAME case, same as reporter's case.

Summary of Test cases and results(HTTP header log).
(1) Case-1 : IFRAME is hard coded in HTML. SRC of it is changed by JavaScript
    http://www.h2.dion.ne.jp/~radon/test/302-redirect-test-1.html
    http://www.h2.dion.ne.jp/~radon/test/302-redirect-test-1-http-log.txt
(2) Case-2 : <BODY onLoad>(changes SRC value of IFRAME again) is added to Case-1
    http://www.h2.dion.ne.jp/~radon/test/302-redirect-test-2.html
    http://www.h2.dion.ne.jp/~radon/test/302-redirect-test-2-http-log.txt
(3) Case-3 : IFRAME is generated by JavaScript
    http://www.h2.dion.ne.jp/~radon/test/302-redirect-test-3.html
    http://www.h2.dion.ne.jp/~radon/test/302-redirect-test-3-http-log.txt

    Random URL : www.google.ca or www.google.jp

In all cases, log was taken when next situation.
 - www.google.ca was displayed (cached)
 - When Reload, JavaScript changed IFRAME's URL to www.google.jp
In case-1 & case-3, HTTP GET was issued to www.google.ca.
In case-2, HTTP GET to www.google.ca was issued, then HTTP GET to www.google.jp
was issued.

This bug's problem can be said as ;
  When (a) main HTML is cached,
     & (b) Reload, 
     & (c) "HTTP GET with If-Modified-Since" because of (a) & (b),
     & (d) "304 Not Modified" is returned for (c),
  Mozilla doesn't care on URL modification of HTML elements by JavaScript
  before onLoad completion.

By the way, I'm trying to report another bug, refresh problem of randomly
redirected("302 Found" & URL is different form previous) elements after "304 Not
Modified" on Reload, and www.googple.jp is redirected to www.google.co.jp(see
log of case-2),
then I used "302-redirected" in HTML/log file name.
But www.google.ca doesn't use redirection, doen't return "302 Found", returns 200. 
So this bug's problem never has relation to "302 not found", redirection.
Sorry for my confusing HTML/log file name.


Live HTTP Hedaders log of step (5) to step (7) in next test.

[Problem recereation test procedure]

(1) Preparation for recreation test
  (1-1) Change cache option/Clear cache
        - Compare the page in the cache to the page on network
          "Every time I view the page"
        - Clear chace
        (This step doesn't have relation to problem recreation test.)
        (But this makes test result clear.)
  (1-2) Go http://bside.homeunix.net/webpage/bug_test/050206/preload.html
        THis HTML load next 7 jpeg files into cache.
          <img src="black.jpg">black.jpg<br />
          <img src="blue.jpg">blue.jpg<br />
          <img src="green.jpg">green.jpg<br />
          <img src="pink.jpg">pink.jp<br />
          <img src="red.jpg">red.jpg<br />
          <img src="white.jpg">white.jpg<br />
  (1-3) Go http://bside.homeunix.net/webpage/bug_test/050206/
        This HTML have next three <img> tags.
           <img src="random.php">
           <img src="random_nocache.php">
           <img src="random_ctype.php">
        These PHP script returns "302 Found"
        and redirects to one of above JPEG files randomly.
        Diferrence among random.php, random_nocache.php and random_ctype.php
        is returned HTTP headers such as Cache-Control: when "302 Not found".
        Objective of the difference is to see that
        the difference has no relation to this bug.
  (1-4) Shift+Reload http://bside.homeunix.net/webpage/bug_test/050206/
        several times, until three different color images are displayed.
(4) Start Live HTTP Headers
(5) Shift+Reload of URL at step (1-2)
      ( http://bside.homeunix.net/webpage/bug_test/050206/preload.html )
      in order to get HTTP header log for getting above 7 jpeg files
      and to put them in cache.
(6-1) First Reload of of URL at step (1-3)
      ( http://bside.homeunix.net/webpage/bug_test/050206/ )
      Althogh server returns "302 Found" and rediret to different JPEG file,
      displyed images are not changed.
(6-2) Second Reload of of URL at step (1-3)
      ( http://bside.homeunix.net/webpage/bug_test/050206/ )
      Althogh server returns "302 Found" and rediret to different JPEG file,
      displyed images are not changed.
(6-3) Third Reload of of URL at step (1-3)
      ( http://bside.homeunix.net/webpage/bug_test/050206/ )
      Althogh server returns "302 Found" and rediret to different JPEG file,
      displyed images are not changed.
(7) Shift+Reload of URL at step (1-3)
      ( http://bside.homeunix.net/webpage/bug_test/050206/ )
    Since the HTML is get again from server,
    displayed images are changed.
(8) End of Live HTTP Header log
Above comment #8 is for Bug 281486.
Ignore it please. Sorry for spam again.
Confirming & changing Product=Core,Component=Networking:Cache.
Correct if wrong, please.
Status: UNCONFIRMED → NEW
Component: General → Networking: Cache
Ever confirmed: true
Product: Mozilla Application Suite → Core
Version: unspecified → 1.0 Branch
Severity: normal → major
OS: Linux → All
Version: 1.0 Branch → Trunk
Change assignee to darin@meer.net(default assignee of Component:Networking:Cache),
because Product/Component change didn't changed assignee automatically.
Assignee: general → darin
QA Contact: general → networking.cache
As far as I can tell cache is absolutely wrong, since this is clearly a session
history issue in some way.  But I can't tell since there is so much noise in the
bug, and not much in the way of actual useful information past the testcase;
someone would have to sit down and debug that to figure out where the "problem"
actually is (and whether it's a real problem; see comment 1).
(In reply to comment #12)
> But I can't tell since there is so much noise in the bug.
Why providing test case and HTTP log is nose?

Because it's not an HTTP issue?
Sorry for noise(especialy for wrong & long post by my mis operation).
How can I produce required data for problem analysis?
My test case-3 is comletely same case as reporter's case, then I can re-create
the problem any time.
What data on which timing is required for problem analysis?
You'd probably want to break in nsDocShell::InternalLoad and see from where and
when it's being called on the reload here.
(In reply to comment #12)
> As far as I can tell cache is absolutely wrong
Wrong what? Why?
I think last cache itself is correct.
In my test, www.google.ca was loaded when kast Shift+Reload, and HTTP GET to
www.google.ca was issued on next reload even though SRC URL of IFRAME is changed
to www.google.jp by JavaScript during reload.

(In reply to comment #16)
> You'd probably want to break in nsDocShell::InternalLoad
Oh no! I can't hack program... I only a tester, although I can write usual
JavaScript program...  But I'll try to read InternalLoad.
Are there any external way such as tracing or backuping of file?

Anyway, I think problem is SRC URL change by JavaScript is not tracked during
reload or doesn't triger replacing action during reload.
If SRC URL change is doen by onLoad script, SRC URL change of IFRAME is
effectieve as usual.
What do you think?

By the way, please note that getting HTTP log doesn't mean suspecting HTTP
related problem.
The purpose of HTTP log is to see whether
 (a) URL change during reload by JavaScript is not effective and old URL is used.
 (b) URL change by JavaScript is effective and HTTP GET is issued to changed
     URL, but display is not changed.
HTTP log is only a evidence of "HTTP GET" to last displayed URL, evidence of not
"HTTP GET" to newly changed URL by JavaScript during Reload.


> > As far as I can tell cache is absolutely wrong
> Wrong what?

Wrong component for this bug.

And no, there is no way to trace the program other than by using a debugger...
History:Session is appropriate? or DOM:Event?
session history is it, per comment 12... (note that the component is unowned, so
someone still needs to find time to debug this).
Changing Component=History:Session
Component: Networking: Cache → History: Session
Bug 89419 comment #50 reported different but similar problem.
 When SRC URL of IFRAME is redirected, server access for IFRAME on reload is last
 redirected URL instead of original URL(URL on IFRAME, which will return "302
 Found" and redirect it).
 This means no chance of redirected URL change for server application if reload.
Boris, same reason as this bug's problem?  
To handle URL change of IFRAME on reLoad properly, I think IFRAME should be
re-construncted again even on reLoad instead of restoring from session history.
IFRAME is not FRAME even though IFRAME has same characteristics as FRAME...
Doing that would break pages (for example, consider character encoding change or
autodetection reloads).
(In reply to comment #24)
> Doing that would break pages (for example, consider character encoding change
> or autodetection reloads).

Oh yah... IFRAME is an element in non-frameset HTML document but has same
characteristics as FRAME...

As a client user, Shift+Reload is sufficient for me.
And I think(hope) many Mozilla users can accept using Shift+Reload even in this
case.
But Web designber or servlet programer will be upset when they know different
result from IE or other browsers,
then they will be convinced that Mozilla violated HTTP Cache-Control: protocol
because it looks that old cached data is used...

No way to force use of newly redirected URL when restoring session history?

Sorry, main issue was SRC URL change.
No way to force use of newly specified(or redirected) URL when restoring session
history?
"good question".  Given that no one really knows the session history code,
someone would need to spend some time digging into it.
Keywords: helpwanted
Just an idea.
(based on reporter's workaround & my test case-2).
 (a) Schedule event for IFRAME if IFRAME is generated(or SRC is changed,
     or URL is redirected to different URL) during reload.
     (<Body onLoad="IFRAME.src=... or frames[IFRAME].location="..."> like event)
 (b) The event execute window.location=new_URL(or redirected URL) in the IFRAME,
     if different content is to be loaded.
This can be done without knowledge on "session history code", because logic (a)
has no relation to "session history code" and logic (b) is executed after
completion of "session hisotory code" :-)

I've understood your comment #4 now.
> It's applied, but then the session history changes what's loaded in the iframe,
> I would bet.
Waiting for someone's digging into it, who really knows the session history code.
> Waiting for someone's digging into it, who really knows the session history
> code.

Like I said, there are no such people... the only person who ever maybe knew it
was Radha, and she hasn't been working on Mozilla for a year or two at this point.
Reporter's workaround was an answer.
> Sample code 2.
> document.write('<iframe name="random_iframe_name" ... ></iframe>');
> document.write('<script ...>'
>       this.random_iframe_name.location="'+url+'";</scr'+'ipt>');

<iframe_object>.location just after IFRAME generation forces new SRC URL use to
 session history.
This is same on SRC URL change by JavaScript during reload.
For redirection case, "HTTP GET to old redirected URL" indicates last location
is redirected URL instead of original URL.
So this is also expected to be bypassed by location change to original URL.

Therefore next can be a solution.
 Automatic execution of window.frames[<iframe>].location=<iframe-object>.src ;
 for all IFRAMEs if location!=src, after </HTML> process completion when reload.
# I don't care elements after </HTML>
# (GeoCities automaticaly adds many tags after user's </HTML>.)

Boris, is it possible?

> Automatic execution of window.frames[<iframe>].location=<iframe-object>.src ;
> for all IFRAMEs if location!=src, after </HTML> process completion when reload.

No, that would break if you load a page, click a link in an iframe, then reload.
The user expectation then is that the reloaded page has an iframe and the iframe
is showing the page the link pointed to, not the original page in the iframe.
(In reply to comment #31)
> No, that would break
I see. IFRAME is a Window even though it is an element and normal(URL not
changed) case should'nt be broken.

Reporter, what is you expectation on "Reload"(not "Load")?
 (1) URL of <IFRAME SRC> can have URL-1-A or URL-1-B.
 (2) URL-1-A, URL-1-B has LINK to URL-2-A, URL-2-B respectively.
 (3) Your script generates <IFRAME SRC=URL-1-A> and is loaded by "Load"
 (4) Browser user clicks LINK and IFRAME's content is changed to URL-2-A
 (5) Browser user clicks "Reload" button
 (6) Your script generates <IFRAME SRC=URL-1A> again
 (7) What should be displayed in the IFRAME?
     What is your expectation?
     What do you think about Browser user's expectation?
nsDocShell::LoadURI looks main entry of loading URI into Window/FRAME/IFRAME.
  (1) LoadURI is invoked for main Window.
      (probably loadType=LOAD_RELOAD_NORMAL & shEntry!=Null when "Reload")
  (2) Main HTML is loaded
      (2-A) LoadURI for each FRAME is invoked
            if FRAMEs are contained, then URL is loaded in FRAME.
  (3) LoadURI is invoked for each IFRAMEs under main Window(Tab) or a FRAME.
  (4) LoadURI controls "LoadHistryEntry"(when nsEntry!=Null),
      or "InternalLoad only"(when nsEntry==Null) at the IFRAME.
  (5) LoadHistryEntry gets last URL from session history, then call InternalLoad.
  (6) InternalLoad calls DoURILoad(when target is mysef),
      or call target's InternalLoad(if different target. LINK clink case).
  (7) DoURILoad realy obtains specified URI's data.
      (Issues "HTTP GET" if http:, or gets form cache)

So I think next steps just before
http://lxr.mozilla.org/seamonkey/source/docshell/base/nsDocShell.cpp#707 can be
a solution for Script generated IFRAME case or SRC URL change by SCRIPT case.
   IF (    (Script generated IFRAME during "Reload")
        || (SRC URL of myself is changed by Script during "Reload") )  
     THEN {
            IF (    (I'm a IFRAME)
                 && (loadType is "Reload" type)
                 && (shEntry is not Null)       )
                     // Shoud be done when FRAME too?
              THEN {
                     Change loadType of the IFRAME(myself)
                     to "Shift+Reload" type, or clear session history indicator 
                     (shEntry=nsnull), in order to force "InternalLoad only"
                     in following load process.
                   }
          }
Similar process can be done just before call nsDocShell::LoadURI for IFRAME and
is better than above in nsDocShell::LoadURI, but I coudln't find who invokes
nsDocShell::LoadURI for IFRAME.

If above conditions are detactable, I think above modification is possible. 
Boris, Is my guess correct? Are above conditions detactable?  
That sounds like the "right" place to hook into things, yes... (as right as
anything gets with session history).

>   IF (    (Script generated IFRAME during "Reload")

It's not clear to me how to define this well, much less detect it...

>       || (SRC URL of myself is changed by Script during "Reload") )  

Same.

>            IF (    (I'm a IFRAME)

This can be detected, but should behavior for <frame> and <iframe> really be
different?
(In reply to comment #34)
> This can be detected, but should behavior for <frame> and <iframe> really be
> different?

Imagine next script only HTML.
 <script> document.write("<FRAME></FRAME>"); </script>
This script cannot generate FRAME after start tag complement (html, head,
frameset, noframes, body and so on) under any dtd (Strcit/Transitional/Frameset)
if rules are strictly applied.
So I thought no special care was needed on FRAME. 
But Mozilla's quirks mode accepts above FRAME for compatibility reason.
And legal way, SRC attribute change or createElement/appendChild etc., is
possible by script in <head> even when frameset.dtd.
So I now think FRAME and IFRAME sholud be identical when "Reload".

> It's not clear to me how to define this well, much less detect it...

Mee too.

"during loading(and loadtype)" is already defined and can be known.
"direct DOM attribute change(IFRAME.src change like)" or "direct DOM structure
change" can be defined and detected, and it doesn't seem to be very difficult.
But how can DocShell or HTML parser distinguish documente.write'ed IFRAME tag
from IFRAME tag in HTML source?

A solution can be definition change of "HTML Modified" on "Reload".
Current "Reload" when "304 Not Modifed" is based on static HTML.
If "add/change of HTML elements after source HTML read" is considered to be "304
is not returned(usually 200)", all document.write can be considered to be
"add/change after 304", then loadtype change from "LOAD_RELOAD_NORMAL" to usual
loadtype becomes possible.
  Note :
   - Load by back button, probably something like LOAD_RELOAD_HISTORY, should 
     probably load from session history as current.
   - An opposite problem may arise when the definition change.
       Even when Web developer always generates same <IFRAME> with same SRC=URL,
       "Reload" executes normal load, then session history in IFRAME is ignored.

Boris, is it possible?     
> "direct DOM attribute change(IFRAME.src change like)" or "direct DOM structure
> change" can be defined and detected, and it doesn't seem to be very difficult.

Seems somewhat difficult to me, since the parser also just sets the DOM
attributes and so forth...

> But how can DocShell or HTML parser distinguish documente.write'ed IFRAME tag
> from IFRAME tag in HTML source?

Why are we trying to distinguish the two?  There should be absolutely no
difference in behavior between them.

Changing the load type in mid-load is really a rather bad idea, I suspect... but
I'm not sure when you're proposing we change it, exactly.
> Changing the load type in mid-load is really a rather bad idea, I suspect...
I think so too...
I've awared that, after last question to you, once my last proposal was
accepted, current reloading of <IFRAME> (load from session history) would never
be invoked on "Reload" when next case.
  - One IFRAME on HTML and SRC URL is not changed.
  - And only document.write("<br>") is used in JavaScript.
I thought on reporter's IFRAME only...

My objective of questions were to clarify ;
(Q1) Whether solution other than "session history" for reporter's case,
     (B-2) in below, exists or not,
     which will never break current "Reload" on (A-1)/(B-1)/(C-1).
       (A) (A-1) One IFRAME on HTML, SRC URL is not changed
           (A-2) Another script generated IFRAME, SRC URL is static
       (B) (B-1) One IFRAME on HTML, SRC URL is not changed
           (B-2) Another script generated IFRAME, SRC URL is dynamic(random)
       (C) (C-1) One IFRAME on HTML, SRC URL is not changed
           (C-2) Another script generated IFRAME, SRC URL is static
           (C-3) One more script generated IFRAME, SRC URL is dynamic(random)
     For this puorpose, I needed to clarify whether a way to distinguish
     (A-2) from (A-1), or (B-2) form (B-1), exists or not.
     And your answer was "NO".
     And chaging loadtype based on document.write use is found to be impossible. 
     Then answer for (Q1) is "NO".
(Q2) What is Web designer's expectation on "Reload" espesilay when above (C), 
     before think about what "Reload" should/can do
     when HTML is dynamicaly changed after "304".
     => Answer from bug opener is not obtained yet.

I could understand "Reload" well than before by your answers.
Boris, thakns for your answering to my questions.

For "Reload" of dynamic HTML, another point similar to "304 when static HTML" is
generated HTML at "End-of-Load".  
In order to restore dynamic HTML to this point like static HTML, copy of all
generated HTML source at "End-Load" is required.
However, is it possible?
I don't know whether it's permitted or not(caching of it is permitted?).
And even if permitted, I think it's impossible to guarantee that all the data is
always held in cache when "Reload".
And even if possible, I believe it's not practical.

So, possible solution for this bug is execute "Load" instead of "Reload" only
for (C-3) when above (C).
And if solution exists, I now can't imagine other than detecting SRC URL change
from previous "Load" on execution of "Reload" for the IFRAME.
And if it's possible, I now think that other than "session history" cannot do it.
(DocShell merely calls "session history"...)
But no one knows "session history" as you say...

On the other hand, relatively easy solution exists for this bug's case.
  (1) Reporter's solution : set the URL in window.location of the IFRAME
  (2) My solution in test case-2 : change IFRAME.src in "onLoad"
So I now think "Guidelines for HTML" or "Tech Evangelism document" is sufficient
as mid-range solution for this bug's problem.

  Note: But another problem may arise when above (2).
        In my test case-2, result was as follows.
        (IFRAME's SRC URL is random, SRC URL is changed by onLoad again)
        - Load page
        - change "char encodig" to UTF-8
        - change "char encodig" to Shift_JIS
          If new URL of IFRAME is Shift_JIS page with no charset,
          display in the IFRAME was UTF-8 instead of Shift_JIS
       It's probably Bug 17889 related new problem,
       although easily avoided by explicite charset in HTML.
       ( Bug 17889 : Changing character set reloads the page from web )
       I's possibly same problem of "No auto charset detection"
       when different charset on FORM POST. 

Boris, I think I've understood your comment #1 and comment #4 correctly.
Is it right? 

By the way, third case, URL redirection of IFRAME URL, was different problem,
then I've opened Bug 282198(spin off of Bug 89419 comment #52).
Can you add comment to it?
> copy of all generated HTML source at "End-Load" is required.

It's not even clear what "end-load" means here, really... when the onload event
fires?  Depending on the page and how it uses timeouts, the DOM may not be
consistent when onload fires.

> And even if possible, I believe it's not practical.

Agreed.
(In reply to comment #38)
> > copy of all generated HTML source at "End-Load" is required.
> It's not even clear what "end-load" means here, really... 

I meant when nsDocShell::EndPageLoad is called.
http://lxr.mozilla.org/seamonkey/source/docshell/base/nsDocShell.cpp#4571 says
> 4571     // This will cause any OnLoad(...) handlers to fire, if it is a HTML
> 4572     // document...
I'm not sure but I think this is called on any end of HTML page loading, even if
asynchronous process is involved in loading.
Yes, but that's a pretty arbitrary definition of "end", since iframes can be
added to the DOM after that...
(In reply to comment #40)
> Yes, but that's a pretty arbitrary definition of "end", since iframes can be
> added to the DOM after that...
Oh, I forgot existence of onLoad script.
My image was - saving HTML_Element_Object.innerHTML by nsDocShell::EndPageLoad,
and no onLoad script.
Script can do anything.
When Dynamic HTML, for "Reload", there is no static point like "304 Not
Modified" of static HTML.

I misundersood Boris's comment #10. It was not onLoad script.
JavaScript executed during load can initiate asynchronous process
which will be executed after EndPageLoad(where "onLoad" scheduling is enabled),
using "Timer", "Event" and so on.
This process can initiate another process including himself.
Never ending story...
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Sorry, I accidentaly changed to FIXED. Reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee: darin → nobody
Status: REOPENED → NEW
QA Contact: networking.cache → history.session
Hi all.

I'd like to revive this bug. It didn't appear in FF2, but in FF3 it is present again.

I can offer a simpler testcase to get this going:
http://mibuerge.googlepages.com/fastbackbug.html?

Plus the following insight:
This has nothing to do with caching! I tried with many different cache headers, and the behavior is always the same.

The workaround I use to get around this is to create the iframe in a timeout (after the load event). The above testcase also provides a means to test that (the delay-parameter).
Component: History: Session → Document Navigation
QA Contact: history.session → docshell
Hi,

I'd also like to revive this (tremendous ?) bug, here is a simple example:

<html><head><title>Bug Firefox 3</title></head><body>
<script type="text/javascript">
  var iframe = document.createElement('IFRAME');
  iframe.src = "/nothing/?rand=" + Math.random();
  document.body.appendChild(iframe);
  alert(iframe.src);
</script>
</body></html>

This is a very simple html page, you can refresh it many times, the log will change every time of course thanks to the Math.random(), but in Apache logs, i always see only the first url

Complete nonsense...
I suggest:

1) Reading the bug
2) Reading https://bugzilla.mozilla.org/etiquette.html

I should also note that due to people ignoring #2 there something like 90% of the comments in this bug are pretty irrelevant to ever fixing it, which makes #1 all that much harder.
Does anyone know of a javascript workaround for this? e.g. code to put in the iframe?
Blocks: 421507
Blocks: 402565
Blocks: 427734
I am running into this bug as well. This is a really nasty bug. Someone please fix it.
i see no real applications for which a user would want the behavior requested. failing that, i think the simplest thing is to resolve this bug as WONTFIX.

could someone point to a number of major sites which are "broken" because this bug isn't "fixed"?

pages which are cooperating can use javascript in their iframes to detect that their content is stale and print a warning (google news does this in a manner of speaking) or reload if they decide to be truly annoying.
We run into this bug as well.  The workaround that we use is to use a setTimeout.  Seems pretty dirty though.  Since most ads are still served through iframes, and don't 'co-operate' with your website, this is a big problem.
I've been trying to find a resolution to this very serious issue as well but have had little luck. We have many large-scale websites running multiple iframe ads per page serving from a large-scale ad-serving platform and a setTimeout workaround just won't fit the bill... as comment #54 put it, it's "pretty dirty". Is this the best bug to follow the status of this issue? Is anyone at mozilla actively working on this issue and realizes the severity of the problem? When ads of different sizes are being served into the wrong iframe it creates a very ugly user-experience and we're hoping that after many years a solution could be reached. Thanks!
> When ads of different sizes are being served into the wrong iframe

That sounds like you're in the wrong bug to me.
No, he's got the right one since Brian 'netdragon' Bober marked 363840 as a duplicate of this item.

The problem is that on refresh, FF will misload the contents of dynamically created iframes from cache. Dynamic iframes are a common technique used by ad vendors so this problem manifests in, for example, 300x250 ad content from a previous load being displayed in the space intended for a 600x160 after the page is refreshed.
Yes, I understand all that.  But comment 55 is not talking about the wrong content being loaded into a given iframe.  It's talking about the _right_ content being loaded into the _wrong_ iframe.  Unless coreyb didn't say what he or she meant to say.
Apologies for the misunderstanding Boris. Brett has it correct - I'm definitely talking about the wrong content loading into a given iframe. Thanks folks.
Also, as an alternative to a setTimeout work-around, we've had good luck by resetting the iframes src after appending it to the page as in the first comment on this ticket. Resetting the src can occur right away (on the line after document.write or appendChild) but it's still hackish and requires browser detection because it screws up the 'back' button in IE.
The src trick causes a spurious load to the original cached url.  This may be fine for some implementations , but not in our case.  Turns out all major browsers have a version of this problem, so far safari's implementation seems the most sane, if caches the iframes by name or id, instead of index, so you can just change those attributes to defeat the caching.  I'm working on comprehensive blog post about it.
This bug is still present in version 3.5. I see it constanstky for all version of Firefox for at least two last years in my website which loads different ads into an iframe on reloads. I see the same bug in Safari, but not in Opera or IE.
Possibly related to bug 276824
And seems to be the same as <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=301325">bug 301325</a>
I've got the same problem
firefox 3.5 stable
code is changed by hand
[...]
function load(){
        var ifr = document.createElement('IFRAME');
        ifr.src = 'test.htm';// I change this by hand to ifr.src = '123.htm';
        ifr.style.width='40px';
        ifr.style.height='40px';
        document.getElementsByTagName('BODY')[0].appendChild(ifr);
    }
[...]
<body onload="javascript: load()" onunload="javascript: leave()">
[...]
thing is even if changed by hand even if I press F5 it keeps loading the same frame source
I need to actually delete my cache and reload
screenshot of sourcecode: http://spielzeugfabrik.com/stuff/screenshot.png

I captured the packets with wireshark and I don't get any "not modified" (as in fact I did modify it)

so for me it seem like a caching bug as clearing the cache solves the problem
I have just written a very simple test case for bug 402565 (see bug502565, comment 3), which does _not_ use dynamically created iframes.

I have created a minimal test case here http://jayvee.nl/iframe-test.php

Steps to reproduce:
1. Open page
2. Click either one of the "reload" links (will call window.location.reload())

Actual result:
iframe content _not_ refreshed
(although Firefox _does_ make an HTTP request using the _old_ URL!)

Expected result:
iframe content refreshed

IE6 and IE6 both show the expected result. I am using Firefox 3.5.1
It's been a week since I posted my comment, along with a test case that should show this is obviously a bug. Why should hitting F5 reload the iframe, when window.location.reload() does not?

Can this bug at least be confirmed by developers? Is there any way I can help?
Nobody's working on this case... I would like to help too, I can send beer to anyone who will work on this BIG issue...
According to my tests, it's not related to the name (or id) of the iframe and it doesn't need to involve any dynamic code before the creation of the iframe.

I just made a page with an iframe with src="www.google.fr". I get the correct page on the first call. Then I changed the src of the iframe to "fr.yahoo.com" and I still see Google when the source code is ok in my navigator.

I tried to add an id and a name to the iframe, reload, then change the id/names, it's still the same, my iframe is stuck on Google (the first SRC).

Using Firebug, I see that Firefox is not requesting the new URL, always the old one.

Even with cache deactivated (Webdeveloper's function), I still get Google on a page refresh.

I tried to close Firefox and reopening again, I still get Google...

Again, if I can help in any way, please send me an e-mail.
Breaking news... I found a way to turn the problem on and off at will. To make a long story short, after a lot of messing around I finally noticed that the bug did not occur when using my "developer" profile as opposed to my "default" profile. I tried to compare the settings between the 2 profiles and it seems the bug appears when browser.cache.disk.enable and browser.cache.memory.enable are set to false. If I set them both to true and restart firefox, the bug disappears.
(In reply to comment #71)
> it seems
> the bug appears when browser.cache.disk.enable and browser.cache.memory.enable
> are set to false. If I set them both to true and restart firefox, the bug
> disappears.

In my FF3.5 on Windows XP, both settings are set to true (their default), and the bug is present.

If I toggle the settings (both false), the bug is still present, but got worse: hitting F5 does not refresh the iframe, only CTRL-F5 will. At least now window.location.reload() and F5 have the same consequence (albeit it the wrong one as far as I'm concerned).

I tested this with the testcase I've mentioned earlier: http://jayvee.nl/iframe-test.php
(In reply to comment #71 and #72)

In my FX3.5 both above parameters are set true (this is their default value). The bug is present but... after running my test code for this bug for the second time, that is after reloading the page (without restarting FX), the bug does not show up anymore.
I forgot to say I'm using FF3.0 on ubuntu 9.04. Not only can I turn the problem on and off by changing the value of browser.cache.disk.enable and browser.cache.memory.enable, I can do it without even restarting firefox. Steps to reproduce:

1. change settings to false
2. goto http://jayvee.nl/iframe-test.php?a
3. reload; bug is present
4. change settings to true
5. goto http://jayvee.nl/iframe-test.php?b
6. reload; no bug
goto 1

But if I skip step #5 and just reload the same page from step #2, then I still see the bug.
Depends on: 527897
(In reply to comment #1)
> The URL loaded in the iframe is restored from session history.  That's the
> expected behavior for a regular reload operation....

We have a logged-in and a logged-out state of our site, both with iframes. 
Boris, seeing inside content on the outside is clearly not the expected behavior.
Fx 3.6.4
Attached file PHP bug reproduction — 
PHP cycles between a random 10 pages, with a different ID for the iframe for each page (id="randomPage0" src="http://www.mozilla.com", id="randomPage1" src="http://www.mozilla.com/en-US/products/", etc).

If you continually reload the page, Firefox will occasionally load the wrong one in the iframe. The problem happens for me both with and without cache being enabled.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.3) Gecko/20100423 Ubuntu/10.04 (lucid) Firefox/3.6.3

Live copy of the attached PHP: http://illandril.net/old/iframeBug/

Initially ran into this problem with a similar setup to Ingo Chao - two different states for the same URL, depending on if a user is logged in or not. We first saw the problem when somebody...
1. Had Logged-in version of the page open on their browser
2. Saved tabs for the next time Firefox started
3. Restarted their computer to install some windows updates (they were running a different build than I listed above, obviously)
4. Opened firefox back up the next morning, seeing the logged out version of the page, but with the wrong content in the iframes (actually a "You must be logged in to see this" page)
Attachment #454905 - Attachment mime type: application/x-php → text/plain
Hi! We have this problem too. The solution that we came up with is to
simply add a row like these after actuallly having write the iframe:

parent.frames[0].location.href = url;

at least it seems to work for me.
Whiteboard: [See comment #1 and comment #4 only for why comment #0 occurs, please]
We have the similar problem.
Facebook widget is rendering itself in our iframe.
also we can not do "this parent.frames[0].location.href = url;"

what should we do?
I wish we can get some official response to that problem.
This is an easily-demonstrated bug that "renders" (so to speak) many pages unusable, or forces designers to impose kludgey Javascript 'fixes' for Firefox users. This bug has been around for many versions, and has been mentioned many times.

Please, please someone on the Firefox team -- take on this project.

I'd like to express, in advance a plethora of gratitude, in advance.
Blocks: 363840
This bug, as filed, is fixed in Firefox 4 betas by smaug's session history changes.

The attached "Test case 1" is NOT fixed, because it's fundamentally different: the iframe is in the HTML, not added dynamically.  The behavior on that testcase is NOT something we want to change, imo.

I've gone through the bugs that were marked duplicates of this one; some of them were in fact duplicates.  Some were duplicates of bug 363840 (which is a distinct bug).  Some were simply caused by buggy extensions.

Resolving fixed.  If you are still seeing some sort of problem in a Firefox 4 beta and it's not the same as bug 363840, please file a new bug and cc me.
Status: NEW → RESOLVED
Closed: 19 years ago → 14 years ago
Resolution: --- → FIXED
Whiteboard: [See comment #1 and comment #4 only for why comment #0 occurs, please]
Hi,

I'm also facing the same problem. In my case, each time the page gets reloaded a new iframe is created. But still i dont understand why the url is cahced ? and i also tried appending a random id to the url. But still im facing the problem.
Can some one please provide a fix or workaround ? I need it very urgently. Is this fixed in 4.0 beta ? If yes i can shift to 4.0. 
Actually Fix or workaround would be helpful.

Thanks in advance,
Sharan
Hi,

Sorry for not updating. I learnt that we (in our product) do not support Firefox 4.0. So would it be possible for you to downport the change/ fix to the current version of firefox?

If not the only possibility is to provide a workaround.

Thanks,
Sharan

PS: Could you please get back to me ASAP.
@Sharan: As Boris said two posts before yours, this is fixed in FF4 beta. I can confirm this.
Sharan, 3.6.x are security and stability releases.  "Rewrite session history" is NOT a security or stability fix.  So this bug's will not be backported to 3.6.
Hi,

Thank you very much for you reply. Yeah I have downloaded 4.0 Beta and tested in thta. It is working fine. But as i mentioned currently we are using only 3.6.
So any workarounds would be helpful?

Thanks,
Sharan
This was reportedly fixed in v.4, but I have 17.0.1 and it appears to have the same problem.  I have a page with an iframe that initially (static HTML) has src=blank.html.  A form in the parent page targets the iframe.  Once the form has been submitted and the action page is in the iframe, refreshing the parent does not cause the iframe to revert to blank.html.  I tested Chrome and IE, and they both work fine, so I'm thinking that this old bug is rearing its head.  My code is behind authentication, but I can whip up a test case if you have trouble duplicating it.
I can confirm this is still happening in Pale Moon 24.7.1. The outer page is set to no-cache, no-store, max-age=0. In spite of this, an iframe with a URL of the form http://domain?random is consistently reusing the same random value--even though the iframe's src is correctly set to a new one--when I refresh the page, which is incorrect behavior.
Hello, I had a similar issue with the iframe. I solved it adding the JS code that sets the iframe in both files : the java script and the html (at the end of the html). It seems that mozilla just ignores one iframe change, and it does't matter where the file is, it just need to ignore one iframe change :). Because if this, it may be that the problem is not with the caching, maybe that is why avoiding cache in the iframe doesn't work. If the site that should be loaded in the iframe is random, I would suggest to save the random selection in a variable and use it in both scripts, the one in the JS and the other in the html. Hopefully this will work for you.
No longer blocks: 402565
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: