1566582 - iframe is loading parent page

Status: RESOLVED WORKSFORME

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

Description

[warren zaccone]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0

Steps to reproduce:

Using Firefox 60.0.8 ESR , a portion of our application that invokes the HTERM terminal emulator in an iframe inside a div to display a virtual terminal using web sockets. It is working correctly in ESR 60.0.8 ESR

Actual results:

We upgraded today to ESR 68.0 and the iframe resubmits the page content from the parent page to the parent URL inside of the iframe. We see the expected content in the iframe for a split second, and then the parent URL replaces it inside the iframe div This breaks our production application. The only change was to upgrade to ESR 68.0 from ESR 60.0.8. It seems some sort of change having to do with iframes which are created and controlled by JavaScript has broken in ESR 68.0.

Expected results:

the parent page should not have been displayed inside of the iframe. The iframe is controlled by javascript which displays contents using the HTERM terminal emulator which is returned from a web sockets reply from a different server.

Comment 1

[warren zaccone]

correction: release we upgraded from was 60.8.0 ESR

Comment 2

[warren zaccone]

more information -- we are setting

iframe.src = '#';

I set a breakpoint in our code and discovered that the parent url is being loaded in the frame subsequent to the expected content being displayed perhaps when an event is fired. (the parent page replaces the expected contents after I resume my break point

Comment 3

[Florencia Di Ciocco, NI to vbalducci]

Hi Warren,

Thanks for the info, but could you share with me the URL where this issue is found? On the other hand, maybe you can provide me with a bit more info.

Does this issue occur with a fresh profile? you can find the steps here: https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles?redirectlocale=en-US&redirectslug=Managing-profiles#w_starting-the-profile-manager

Can you please download Firefox Nightly from here: https://nightly.mozilla.org/ and retest the problem and see if the issue still occurs there as well?

If after doing this you can still reproduce the bug, could you send me a screenshot or a video of the bug? That always helps a lot.

Thanks in advance, Flor.

Comment 4

[warren zaccone]

I am not able to share a URL because it is an internal application.

It appears when the load event is fired, frame is loaded with the enclosing page as of Firefox 68

The following code works around the issue:

if ('mozInnerScreenX' in window) { // detect Firefox
myIframe_.addEventListener('load', () => loadmyIframeContent());
} else {
loadmyIframeContent();
}

Comment 5

[warren zaccone]

Before I added this code to our application today, Firefox 68 would replace the iframe contents with the content from the page which contains the iframe. i.e.

page
has an iframe
iframe is supposed to have content loaded in it by javascript.

in Firefox esr 60, and before, it was fine. in firefox esr 68, the iframe reloads the enclosing page again, it would be recursive and lock up the browser if it were not for how our application works. adding the code above, overrides the firefox 68 behavior, by loading our content after the load event has been fired.

Comment 6

[warren zaccone]

I meant to say the iframe loads the enclosing page inside of it (instead of the expected content), so we have the enclosing page inside of itself.

Comment 7

[warren zaccone]

to answer your question -- before I applied the workaround, I installed the nightly version of firefox, and the problem was still occuring.

Comment 8

[Florencia Di Ciocco, NI to vbalducci]

Hi Warren,

Obviously, I wasn't able to test this bug since it's an internal application but I've set a component so that the devs can be involved. If you consider that there's another component that's more proper for this case you may change it.

Best regards, Flor.

Comment 9

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to warren zaccone from comment #4)

I am not able to share a URL because it is an internal application.

It appears when the load event is fired, frame is loaded with the enclosing page as of Firefox 68

The following code works around the issue:

if ('mozInnerScreenX' in window) { // detect Firefox
myIframe_.addEventListener('load', () => loadmyIframeContent());
} else {
loadmyIframeContent();
}

Hi Warren,
Thanks for the comments. In addition to the workaround code, is it possible that you provide us a simplified but completed test case that reproduces the issue? Much appreciated!

Comment 10

[warren zaccone]

Please see simplified test case below.. Expected Result: see the words test case once in the window.
Actual Result in other browsers and Firefox ESR 60.0.2: the word test case appears once in the window -- passed
Actual Result = Firefox ESR 68.0.1 - the word test case appears twice in the window because the iframe is reloading the parent page - failed

<!DOCTYPE html>
<html>
<head>
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta http-equiv="X-UA-Compatible" content="IE=edge"/>
<meta charset="UTF-8">
<title>iframe test</title>
<script language="JavaScript">
function createFrame (div) {

var iframe_ = div.ownerDocument.createElement('iframe');
iframe_.style.cssText = (
'border: 0;' +
'height: 100%;' +
'position: absolute;' +
'width: 100%');

if ('mozInnerScreenX' in window) iframe_.src = '#'; // if this line is removed, then the test case will pass in firefox 68.0.1

div.appendChild(iframe_);

var doc_ = iframe_.contentDocument;
doc_.body.style.cssText = (
'margin: 0px;' +
'padding: 0px;' +
'height: 100%;' +
'width: 100%;' +
'overflow: hidden;' +
'-webkit-user-select: none;' +
'-moz-user-select: none;');
}
</script>
</head>
<body>
<p>test case </p>
<div id="my_window"> </div>
<script language="JavaScript">
var myId = document.querySelector("#my_window");
createFrame(myId);
</script>
</body>
</html>

Comment 11

[Alice0775 White]

Attachment: Reporter's test case

I can reproduce the issue on Nightly70.0a1 Windows10

Expected Results:
test case

Actual Results:
test case

testcase

Comment 12

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=982f91f69b39773ac302d4d01610de1414894529&tochange=70f63648a0f6cf738d5555eb347986d7323ef16e

Regressed by: Bug 1497126

:baku, Your patch seems to cause the regression.
Can you please look into this?

Comment 13

[Liz Henry (:lizzard) (relman/hg->git project)]

Happy to take a patch still for 70/71. Is there anyone who can work on this now that we have a test case?

Comment 14

[Andrea Marchesini [:baku]]

Forcing iframe.src="#", you are making the iframe src to be equal to the parent URL + "#". This means that the iframe will load the same content.
In bug 1497126, we allow 1 level of recursion when loading nested iframes. Before, we didn't. This is the reason why before you didn't see 'test case' twice, and now you do. This seems the correct behavior. I NI annevk for a confirmation.

Comment 15

[Anne (:annevk)]

The testcase is problematic as it contains code that only runs in Firefox and not in Safari or Chrome. If I make it so that the same code runs in Firefox and other browsers, they all behave the same, so I'm inclined to agree with Andrea here that there's less risk for us to not change this.

Unfortunately recursion of frame loading is not well standardized, but with all browsers behaving identically that shouldn't be hard. The main issue here is that the application runs some code only in Firefox and not other browsers, as far as I can tell.

Comment 16

[Andrea Marchesini [:baku]]

Closing the bug for comment 15.