1745638 - iframe contents end up blank after a reload (despite being given content by script)

Status: RESOLVED FIXED

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

Description

[Dr. Uwe Risse]

Attachment: FF95_vs_Edge.jpg

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

Steps to reproduce:

After update to FF 95.0, some pages are not correctly rendered anymore. Example:
For my page at QRZ.com (https://www.qrz.com/db/DG2YCB), sometimes the entire content of the "Biograpy" tab is no longer displayed. Instead, only white space is shown. It worked flawlessly with all prior versions of Firefox. Also all other browsers (Edge, IE, Chrome) show the page without any issues.

Actual results:

Instead of the web content only white space is shown. See left part of my screen shot "FF95_vs_Edge.jpg".

Expected results:

The web content shall be shown as with all other browsers. See right part of my screen shot "FF95_vs_Edge.jpg".

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Text and Fonts' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Kenan]

WFM with Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:97.0) Gecko/20100101 Firefox/97.0

Comment 3

[Emilio Cobos Álvarez (:emilio)]

I can't repro this either on 95 nor Nightly... Reporter, if this happens consistently, can you run mozregression so that we can try to track down what caused this for you? Also, perhaps you can attach your about:support information to the bug in case it's a graphics-driver/hardware dependent issue? Thank you.

Comment 4

[Dr. Uwe Risse]

Today, the error is back. I thought already I fixed it just by installing FF 95.0 again, but a few minutes ago I updated to FF 95.01, and with the first start again a blanc white screen where there shlould be the contant of the 'Biography' tab of my page at QRZ.com. See the new screen shot.

Comment 5

[Dr. Uwe Risse]

Attachment: FF95.0.1.jpg, After updating to v95.0.1 again a white screen instead of the web content

Comment 6

[Dr. Uwe Risse]

I need more detailed instructions on how to install / use mozregression, and what exactly need to be done with that tool. Never used it before.

Comment 7

[Kenan]

You can easlily install mozregression from https://mozilla.github.io/mozregression/install.html
and find a tutorial how to use (video) on: https://mozilla.github.io/mozregression/quickstart.html

Comment 8

[Dr. Uwe Risse]

I installed mozregression, but so far it showed no error. However, today in my normal FF 95.0.1 the error was back again. Therefore I recorded a screen shot video, where you can see the error. Find it on my following server: http://dr-risse-consulting.de/FF_bug_1745638.mp4 .

Comment 9

[Patrick (he/him)]

Able to reproduce this issue in Firefox 95.0.1, at URL https://www.qrz.com/db/DG2YCB - upon refreshing the page, the 'biography' tab became blank. Issue appears intermittent which makes it difficult to reproduce

Comment 10

[Dr. Uwe Risse]

Bug now also on Linux: After updating Firefox from version 94 to 95, for the first time the bug came now also on my Linux Mint 20.2 Cinnamon system. This means that it must have something to do with any of the code changes from 94 to 95. Screen shot attached.

Comment 11

[Dr. Uwe Risse]

Attachment: [e-mail]

After updating FF94 to FF95, for the first time the bug was now also on my Linux Mint 20.2 system visible. Reloading the page fixed it, however, this bug was never ever there until FF94.

Comment 12

[Dr. Uwe Risse]

In case the Firefox developers cannot find and fix the bug: Please make a 95.0.2 "bug fix release" where you withdraw all the code changes done from 94 to 95 !!!

Comment 13

[Dr. Uwe Risse]

FYI. I just updated my FF to version 95.0.2, but the error is still there. After the first time I pushed the reload button, again only white instead of the content of the 'Biography' tab of my page on qrz.com. PLEASE WITHDRAW THESE FF95.x VERSIONS !!!

Comment 14

[Patrick (he/him)]

Hi
Thanks for reporting this issue. I use QRZ.com myself, so can understand your frustration.
While I was able to reproduce this issue once, I cannot consistently reproduce it, which makes it difficult to find a regression range and work out what change in FF might have caused it.
I was hoping you could attach your about:support information, in case there is something specific to your system contributing to the issue?
Also, just to confirm, was FF 94 the last version where the issue did not occur?

Comment 15

[Patrick (he/him)]

I am not able to reproduce this issue at all on Nightly. Could you please install it and see if the issue occurs on there?
https://www.mozilla.org/en-US/firefox/all/#product-desktop-nightly

Comment 16

[Dr. Uwe Risse]

Hello Patrick, I am currently doing some systematic tests hoping to be able to identify more precisely with which version the bub came first. I installed some older FF versions from PoartableApps, each time using my profile with the same settings (I have some older backups). Results:

Comment 17

[Dr. Uwe Risse]

Results: FF89 is good (no bug), FF93 seems also to be good (so far no bug seen), but both with FF94.0.1 and FF94.0.2 the bug is there again. So, likely the error came already with the update from FF93 to 94.

Comment 18

[Patrick (he/him)]

Hello Uwe
Thank you for the additional information
Would you be able to repeat this test using mozregression? That would tell us exactly what change made between FF 93 and FF 94 has caused the issue

Comment 19

[Dr. Uwe Risse]

I repeated the test with mozregression (between FF93=good and FF94=bad). Unfortunately, during this test, none of the tested version showed the bug. Hmm... Or can it be, that during update from FF93 to FF94 (due to a systematic error in the update algorithm) my profile became somehow corrupted? I mean, it must be a systematic error, because as said I got the same error now also on Linux. Unfortunalety it needs about to put all the needed configuration settings for FF and for my add-ons into a fresh profile. Not that easy to do that on Windows as well as on Linux just for testing...

Comment 20

[Dr. Uwe Risse]

Sorry, some typos. I meant "it needs about one hour to put all the needed configuration settings for FF and for my add-ons into a fresh profile..."

Comment 21

[Dr. Uwe Risse]

FYI. FF93-portable is still without any bugs. I will switch to this for a while and see whether the bug in FF94 and above can be found and fixed. If not, there is no other way for me as to switch back to FF93 and disable updates. QRZ.com is the page most often used on a day.
Do you know how I can roll back FF 95 to 93 on Linux?

Comment 22

[Dr. Uwe Risse]

One interesting observation: I managed to roll back FF on my Linux Mint 20.2 system from 95 to 94. Result: While FF95 showed the bug also on Linux, so far FF94 on Linux DID NOT SHOW the bug. This means the following:

Comment 23

[Dr. Uwe Risse]

On Windows the bug came with the update from FF 93 to 94, but on Linux it seems that there the bug came with th eupdate from FF94 to 95. So, my question: Which of the FF change commits have been implemented on the Windows version from 93 to 94, but on the Linux Mint version from 94 to 95?

Comment 24

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

The severity field is not set for this bug.
:jwatt, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 25

[Dr. Uwe Risse]

I think you are all on the wrong track, guys. My complaint is NOT that sometimes some images are not shown, but that THE ENTIRE CONTENT OF THE BIOGRAPHY TAB IS NOT DISPLAYED. No text, no graphics, just a fully white page. And as said, this bug came on Windows with the update from FF 93 to 94.

Comment 26

[Daniel Holbert [:dholbert]]

(In reply to Dr. Uwe Risse from comment #25)

I think you are all on the wrong track, guys. My complaint is NOT that sometimes some images are not shown, but that THE ENTIRE CONTENT OF THE BIOGRAPHY TAB IS NOT DISPLAYED

Nobody's mentioned images here, as far as I can tell -- that's been discussed over on separate bug 1746886 (for an issue that Alice0775 was able to reproduce when trying and failing to reproduce your issue, I think).

For what it's worth, I seem to be able to reproduce the issue that you've brought up here (the page is mostly blank) only if I load the page with devtools open.

Based on the analysis of the separate issue in bug 1746886 (for the same page), I'm suspicious that this issue is from the page having a fragile dependency on some race condition in its JS, but I haven't confirmed that yet.

Comment 27

[Daniel Holbert [:dholbert]]

The blank area here is a super-tall iframe:

<iframe src="about:blank" onready="resize();" title="dg2ycb Biography" sandbox="allow-popups allow-popups-to-escape-sandbox allow-top-navigation allow-top-navigation-by-user-activation allow-forms allow-same-origin" border="0" style="margin: 0px; padding: 0px; width: 100%; border: medium none; display: block !important; height: 22038px;" id="biodata" class="action-render-" frameborder="0"></iframe>

The page seems to dynamically populate it with JS, I think. When things go wrong and the page ends up blank, it seems that JS is failing to run for some reason.

Comment 28

[Daniel Holbert [:dholbert]]

Yeah, I think it's likely similar to the fragile-JQuery-event-dependency that I diagnosed in bug 1746886.

The page populates the initially-empty biodata iframe this way (from the source of https://www.qrz.com/db/DG2YCB):

jQuery(document).ready( function() {
[...]
jQuery('.action-render-').contents().find('#biodata').html( Base64.decode("PHA+PHNw[....more-base64-coded-data here...])

That Base64 decoding is the relevant thing that needs to happen for the page to show up. That base64 string is the whole iframe contents, basically (including "Hi, thanks for visiting my page!" etc.)

Comment 29

[Dr. Uwe Risse]

Finally a trace to the root cause! Good job, Daniel! Go on ...

Comment 30

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

The severity field is not set for this bug.
:dholbert, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 31

[Daniel Bodea [:danibodea]]

I have tried extensively to reproduce the original issue and I've reproduced it once in many, many tries. This one reproduction happened on a first load in a 32-bit Nightly v97.0a1, in a new profile, but could not reproduce it ever again.
I have to mention that I've tried new profiles and used/dirty ones, in several different Windows 10 systems.

Considering that this issue has such a low reproduction rate, I can't possibly find a regressor for it.

Dr. Uwe Risse, could you please answer some questions:

1. How often does it actually happen in your case? (preferably an approximation of... how many times it happened per how many times the page is viewed, in a random day)
2. Would you please provide the about:support information from your affected browser
   Steps: open the affected browser, load the following address: "about:support", then click "Copy text to clipboard", paste the info into the comment section and give it a name.
   Hopefully, some information about your system might help me reproduce it consistently.
3. Do you know if this issue reproduces more often on other systems than your own? (I'm thinking it might be connected to some of your user data)
4. Do you use sync? Did you sign into Sync?
5. You could also try if your issue is reproducible same as often when using Safe Mode.
   (steps on how to open in safe mode: https://support.mozilla.org/en-US/kb/troubleshoot-extensions-themes-to-fix-problems)

P.S. In other news, the other issue that Alice has uncovered with your webpage is reproducible 100% on all tested systems.
Thank you for your report!

Comment 32

[Dr. Uwe Risse]

Attachment: Data from about:support

Comment 33

[Dr. Uwe Risse]

Here are my answers to your questions:
ad 1. It happens every day a couple of times.
ad 2. done
ad 3. Yes, it happens on my two Windows 10 computers (from FF94 on) as well as my Linux Mint 20.2 system (there from FF 95 on). When I am using FF 93 portable (using the same profile, taken from a backup), the bug is NOT there. But when I then update this FF 93 portable, the bud is immediately there again. Tried it already two times. Is 100 % reproducible here.
4. No, I am not using sysnc (and I don't want to use it).
5. I tried also already the safe mode. It doesn't change anything.

I have prepared for you another screenshot video where you can see the bug. Find it on my following server: http://dr-risse-consulting.de/FF_Bug1745638.mp4 .

Comment 34

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #28)

Yeah, I think it's likely similar to the fragile-JQuery-event-dependency that I diagnosed in bug 1746886

Update: this^ wasn't correct -- in this case, ready() fires reliably and the Base64 string does get decoded into the iframe, and then subsequently the iframe ends up blank.

This one seems like probably-a-browser-bug.

Dr. Risse, would you mind testing one more thing, to help confirm something that I think is involved:
(1) In a Firefox instance that's affected by this bug (one of your Firefox 95 installations), visit the special page about:config
(2) Type fission.autostart into the search field at the top of that page.
(3) Once you see the row show up for the preference of that name, double-click it to change its value to false
(4) Restart Firefox (e.g. Ctrl+Q) so that this change can take effect, and see if you can still reproduce.

My theory is that this will work around the bug; it seems to for me, and it would be great to confirm that on your side as well.

(After testing this, you should probably undo that change and set the pref back to true, since fission.autostart provides some valuable security benefits. But I suspect it may be involved in causing this issue.)

Comment 35

[Emilio Cobos Álvarez (:emilio)]

(In reply to Daniel Holbert [:dholbert] from comment #34)

(In reply to Daniel Holbert [:dholbert] from comment #28)

Yeah, I think it's likely similar to the fragile-JQuery-event-dependency that I diagnosed in bug 1746886

Update: this^ wasn't correct -- in this case, ready() fires reliably and the Base64 string does get decoded into the iframe, and then subsequently the iframe ends up blank.

That smells like bug 543435.

Comment 36

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

I think this is a reduced testcase for the original page here.

STR with this reduced testcase:
(1) Load testcase.
(2) Reload.

ACTUAL RESULTS:
The iframe ends up blank.

EXPECTED RESULTS:
The iframe should contain text.

I get ACTUAL RESULTS if I have fission enabled (as it is by default).

I get EXPECTED RESULTS in Chrome, and in Firefox Nightly if I turn off fission.

Comment 37

[Daniel Holbert [:dholbert]]

hsivonen, would you mind looking at the attached testcase (in my previous comment) and seeing if it feels like a dupe of bug 543435 as emilio suspected?

(I think it likely-is, but you're in a better position than I am to confirm that.)

Comment 38

[Daniel Holbert [:dholbert]]

Hmm, I just rebuilt with bug 543435's latest patch and my testcase still gives ACTUAL RESULTS (blank after a reload), so maybe not a dupe of bug 543435; but feels related.

Comment 39

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (with console.log to show iframe location changing)

Here's a version of testcase 1 with some logging added, to show that the iframe's window.location is changing back to about:blank after we've populated it with content; i.e. it's navigating when it shouldn't be.

In Firefox Nightly, the first time I load this testcase, the first logged line here shows about:blank and the latter three show the testcase's URL.

But when I reload, the last logged line changes to show about:blank as the location instead (which matches the observed symptom of the iframe appearing blank).

Comment 40

[Daniel Holbert [:dholbert]]

Attachment: testcase 3: demonstrating that iframe testFrame.contentWindow.location changes back to about:blank, between 'go' and body's onload (after a reload)

Comment 41

[Daniel Holbert [:dholbert]]

If I reload testcase 3 in Nightly, it gives me this output:

FAIL; iframe location changed from 'https://bug1745638.bmoattachments.org/attachment.cgi?id=9257744' to 'about:blank'.

If I disable fission, I get SUCCESS instead. (And Chrome gives SUCCESS.)

Comment 42

[Dr. Uwe Risse]

This morning I set fission.autostart to false. So far I have NOT seen the white screen again. This seems to confirm what your suspected.

Comment 43

[Dr. Uwe Risse]

Of course the root case should befound and fixed. But besides this one suggestion: Wouldn't it make sense to have in aout:config an option to whitelist some URLs from fission? For example a "fission.whitelist" string where I can put in trusted URLs where - for whatever reasons - fission has some troubles with.

Comment 44

[Dr. Uwe Risse]

Sorry, typos. I meant "Of course the root cause should be found"...

Comment 45

[Daniel Holbert [:dholbert]]

(In reply to Dr. Uwe Risse from comment #43)

But besides this one suggestion: Wouldn't it make sense to have in aout:config an option to whitelist some URLs from fission?

Unfortunately that's not possible - fission is a core low-level behavior that can't be turned on or off dynamically (which is why it requires a browser restart after you toggle the preference, in order for the pref change to take effect). It is also essentially "done" (aside from occasional bugs like this one) -- so, given its important security benefits, it's unlikely to be worth it to add additional infrastructure for turning it off in new and interesting ways. :) Better to just fix the bugs.

Comment 46

[Henri Sivonen (:hsivonen) (temporarily away from Bugzilla)]

This is likely a duplicate of bug 1736570.

Bug 1736570 comment 39 has a link to builds with a WIP patch for that bug. I can repro with Nightly but not with a build with the patch.

Comment 47

[Daniel Holbert [:dholbert]]

(In reply to Henri Sivonen (:hsivonen) from comment #46)

This is likely a duplicate of bug 1736570.

Bug 1736570 comment 39 has a link to builds with a WIP patch for that bug. I can repro with Nightly but not with a build with the patch.

Thanks! That's great news. Looks like we don't have an automated test in the patch over there yet (or a reduced testcase on that bug) -- hopefully my reduced testcases here can be adapted to serve that purpose, if you don't already have a testcase locally.

Comment 48

[Daniel Holbert [:dholbert]]

(In reply to Henri Sivonen (:hsivonen) from comment #46)

This is likely a duplicate of bug 1736570.

Bug 1736570 comment 39 has a link to builds with a WIP patch for that bug. I can repro with Nightly but not with a build with the patch.

Hmm, it seems the WIP patch does not in fact fix it after all. I downloaded the Linux x64 Shippable build from the try run, and it initially seemed not to reproduce the bug with the testcases here, but then I checked about:support and noticed that it has fission disabled-by-default[1].

EDIT, turns out I was testing the wrong (old) build, which is why fission was off by default. However: after I noticed that and retested using the correct build, I'm still able to reproduce this bug 100% reliably with the attached testcases.

Comment 49

[Daniel Holbert [:dholbert]]

(Sorry, I just noticed I was initially testing the wrong build in comment 48 -- turns out I had an old target.tar.bz2 file in my Downloads directory which I had extracted by mistake. I only realized the error when I checked about:buildconfig and noticed an unexpected source revision there.)

I've now tested the correct target.tar.bz2 build, and I can still reproduce this bug with all attached 3 testcases using that build and a fresh profile.

So: wondering if this is really a dupe of bug 1736570 or not (assuming that the try build does indeed fix bug 1736570).

Comment 50

[Daniel Holbert [:dholbert]]

(I tried the more-recent try build from bug 1736570 comment 46, too, and I can also reproduce with that one. All three of my attached self-describing testcases trigger their failure-conditions when reloaded (testcases 1 and 2 end up with blank iframes, and testcase 3 shows "FAIL")

Comment 51

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

This is a ship bug

Comment 52

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

Attachment: Bug 1745638, allow stopping session history load to an iframe, r=peterv

Comment 53

[Pascal Chevrel:pascalc]

Too late for 96 and we shipped our last beta for 97 today, Smaug could we make sure that it makes 98? Thanks

Comment 54

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

The patch is on queue to be land to autoland

Comment 55

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e15925b76a27
allow stopping session history load to an iframe, r=peterv

Comment 56

[Iulian Moraru]

Backed out for causing mochitest failures on test_bug1745638.html.
Affected platforms Android 7.0 x86-64 Lite WebRender debug, Android 7.0 x86-64 WebRender debug Mochitests with AAB and Android 7.0 x86-64 WebRender debug Mochitests with software webrender enabled

Push with failures

Failure log for mochitest plain
Failure log for mochitest plain with AAB
Failure log for mochitest plain swr

Backout link

This also caused some wpt failures. So far the wpt failures are only on Windows 10 x64 2004 WebRender debug.
Failure log for wpt swr-fis
Failure log for wpt fis

Comment 57

[Daniel Holbert [:dholbert]]

For reference/convenience:

• The android test-failure has this 1 assertion, during the added test (you have to go into logcat to see the actual assertion-text):

01-28 19:07:54.414 3678 3696 I Gecko : [Child 3678, Main Thread] ###!!! ASSERTION: Adding a child where we already have a child? This may misbehave: 'aUseRemoteSubframes', file /builds/worker/checkouts/gecko/docshell/shistory/nsSHEntry.cpp:672

https://firefoxci.taskcluster-artifacts.net/JRR7XKjDRmex_gmvjBfHbQ/0/public/test_info/logcat-emulator-5554.log

• On Windows, it looks like the WPT assertion-failures are in resource-timing/nested-context-navigations-iframe.html; we get two copies of this pair of assertions:

[Child 3136, Main Thread] ###!!! ASSERTION: Overwriting an existing document channel!: '(loadFlags & nsIChannel::LOAD_REPLACE) || !(mDocumentRequest.get())', file /builds/worker/checkouts/gecko/uriloader/base/nsDocLoader.cpp:469

[Parent 1116, Main Thread] ###!!! ASSERTION: Adding a child where we already have a child? This may misbehave: 'aUseRemoteSubframes', file /builds/worker/checkouts/gecko/docshell/shistory/SessionHistoryEntry.cpp:1219

https://treeherder.mozilla.org/logviewer?job_id=365951885&repo=autoland&lineNumber=1866

Comment 58

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2c40cadf59ff
allow stopping session history load to an iframe, r=peterv

Comment 59

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/2c40cadf59ff