Open Bug 402565 Opened 13 years ago Updated 5 years ago
JS Reload of iframe parent loads subframe with old query string - not the one in the new markup!
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:22.214.171.124) Gecko/20061201 Firefox/126.96.36.199 (Ubuntu-feisty) Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:188.8.131.52) Gecko/20061201 Firefox/184.108.40.206 (Ubuntu-feisty) I have an iframe page which has a few subpages loaded in iframes (say foo.php and bar.php). Certain actions in these subframes will reload those pages with query strings atttached (e.g. foo.php?action=show_products) This all works fine, however there cases when we want to reload the entire window and everything in the iframe (after adding a new product to the database in this app). When this was done using window.parent.location.reload(); it would reload the parent page, but subframes would be loaded with the old query strings attached (which could cause the parent frame to reload infinitely in some cases). I discovered that window.parent.location.href = window.parent.location.href; get around that problem, however, I noticed that in MSIE and KHTML/Safari, location.reload() reloads iframes fresh without the old query strings. Is this a Mozilla bug, or do the other browsers do this incorrectly? I don't know, but I wanted to point this out. While I didn't find this in Bugzilla, it is somewhat similar to bug #133568, but I don't think it's quite the same issue. Thanks! Reproducible: Always Steps to Reproduce: 1. Create a page with iframes 2. Inside one of the iframes, have a form or link that submits to the same page, but adding GET query strings 3. Upon detection of those GET parameters, do whatever then call window.parent.location.reload(); to refresh the application (parent document) 4. The iframed subpage will be reloaded with the GET query strings (Unlike the behavior in other browsers) Actual Results: Subpages in iframes are reloaded with previous query strings (GET parameters) still attached Expected Results: Other browswers such as KHTML/Safari and MSIE load iframes fresh as specified in parent pages HTML source.
I ran across this today, and would like to confirm the bug. Bug 279048 is slightly different from this one I think, as it concerns dynamically created iframes. I don't know whether that makes a difference. 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 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? This can't be "by design"! Can this bug at least be confirmed by developers? Is there any way I can help?
> I don't know whether that makes a difference. It doesn't. The session history system doesn't really know when iframes are created (arguably a bug, and filed). > Why should hitting F5 reload the iframe, when window.location.reload() does not? They two actually run different code and may have slightly different behavior in terms of HTTP validation and the like, for what it's worth. Compare nsDocShell::Reload (which is what window.location.reload() calls and nsSHistory::Reload (which is what the browser UI calls). I can't tell you whether that mess is by design or not.
For what it's worth, given the number of pages that at least used to have random location.reload() scattered about on every CSS change, I suspect the difference in behavior was in fact purposeful.
Thanks for taking the time to explain. > I suspect the difference in behavior was in fact purposeful. Does that mean nothing will be done about this? Do we just leave this bug report ("unconfirmed" even!) and hope this "mess" will one day be refactored? I understand that fixing this bug could break some sites, so I'm curious about the policy (if any).
I have prepared a DEMO of this bug. See my update and files here: https://bugzilla.mozilla.org/show_bug.cgi?id=320792
> I don't know whether that makes a difference. It does now. The dynamic case was changed to throw away session history information.
Depends on: 363840
So, http://jayvee.nl/iframe-test.php prints a random value in the main page and adds the same random value in the query string of an IFRAME, where it is echo'ed back inside the IFRAME markup. This is just plain markup from the server, no fancy JS involved. In both current release and Nightly, I see this: 1) On first load, the random value in the main page and the IFRAME is the same 2) After using the reload() link (triggers a window.location.reload() call in the main page), the values are different. 3) If you reload manually with F5, the values are the same 4) If the page calls location.reload(true), the values are the same The location.reload() case where the values end up being different is surprising. I've verified by viewing source that the IFRAME's SRC attribute contains the *new* value. From the HTTP traffic, we see that Firefox nevertheless sends a new request for the *old* URL, and shows the result of that request. I've checked some of the other bugs mentioned here, and I see absolutely no rationale that makes this seem by design. On the contrary, it seems utterly broken to request and display *another* URL than the one the IFRAME markup tells you to load. It's a good thing that this was fixed for manual reloads in Fx 4 or so (which is probably why the flow of bugs and complaints seems to have stopped) but why doesn't that fix cover location.reload()?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: JS Reload of iframe parent loads subframes without old query strings → JS Reload of iframe parent loads subframe with old query string - not the one in the new markup!
This bug is similar, and talks about a work-around of adding a unique "name" field, which seems to fix the issue: https://bugzilla.mozilla.org/show_bug.cgi?id=356558 I haven't confirmed the work-around yet.
You need to log in before you can comment on or make changes to this bug.