1586005 - Iframe gets reloaded from cached URL, despite DOM showing new URL; the view gets updated correctly with new fetched document.

Status: RESOLVED DUPLICATE of bug 356558

(Core :: DOM: Navigation, defect, P3)

Description

[ailmanki]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90 Safari/537.36

Steps to reproduce:

I have a page which has an embeded iframe. The iframe always points to the same URL, only the params change. I use the params to display different content.

I then reload the page, it does not always happen - might take multiple reloads.

Using Firefox 69.0.1 (64-bit) on Windows 10.

Actual results:

On reload of the page, I can see in developer tools that the DOM has the new iframe src (the main page gets correctly loaded).

Then the iframe itself gets loaded from the cached URL, it does not use the URL which is in the actual src. I can see this in Network tab, and I can also see it on the server getting the request, that I get previous params.

It then shows the freshly fetched (from wrong url) iframe correctly, at least that works - and it does not show a cached version.

Expected results:

It should use the src given in the actual html, and not the cached from a previous load.

Comment 1

[ailmanki]

Maybe a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=279048

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 3

[ailmanki]

What does work is setting the src to "about:blank"; and then set it through Javascript to the new URL.
As described here: https://bugzilla.mozilla.org/show_bug.cgi?id=363840#c28

Comment 4

[Edgar Chen [:edgar]]

It looks like a duplicate of bug 279048.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Wait, how can this be a duplicate of a fixed bug if it's still happening?

It doesn't sound like the page in question uses a dynamically inserted iframe; the source HTML of the page is just changing, right?

In general, the user expectation is "reload what I see", hence the observed behavior of doing a reload in the iframe as if reload() were called on it, as opposed to loading the new url. A forced reload (shift-reload) will completely reload everything from scratch, I believe, if the idea is to have something in development to test updates.

Comment 6

[ailmanki]

Does not happen anymore with Firefox 69.0.3 (64-bit) on Windows 10.
Will monitor this, if it happens again will comment.

Comment 7

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

Please reopen if this happens again.

Comment 8

[kessl]

This is happening to me with Firefox 82 on macOS Catalina.
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Firefox/78.0

I have two static (server-rendered) pages containing a single iframe with the same src except for a query param. On navigating between the two pages, I see the param in iframe src update, but the iframe content remains as if the param didn't change.

Reload without cache (command + shift + R) loads the correct content reliably.

Comment 9

[guilipan]

this issue still happens on Firefox 83 on windows 10, could anyone tell me when this will be fixed?

Comment 10

[guilipan]

(In reply to Olli Pettay [:smaug] from comment #7)

Please reopen if this happens again.

still happens on firefox 83

Comment 11

[Chris Peterson [:cpeterson]]

(In reply to kessl from comment #8)

I have two static (server-rendered) pages containing a single iframe with the same src except for a query param. On navigating between the two pages, I see the param in iframe src update, but the iframe content remains as if the param didn't change.

Dan, can you please link to a test case or attach to this bug?

Changing the query param should bypass the local cache, so this is unexpected behavior.

Comment 12

[Chris Peterson [:cpeterson]]

Guilipan, you saw this bug recently. Do you have a link to a public website that we can test?

We need a test case that reproduces this bug. Are the test cases in bug 356558 relevant for this bug?

This is probably a session history bug.

P3/S3