iframe content disappears right after it is displayed
Categories
(Core :: DOM: Navigation, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr91 | --- | fix-optional |
firefox94 | --- | wontfix |
firefox95 | --- | wontfix |
firefox96 | --- | wontfix |
firefox97 | --- | wontfix |
firefox98 | --- | fix-optional |
People
(Reporter: alice0775, Unassigned)
References
(Depends on 1 open bug, Regression, )
Details
(Keywords: nightly-community, parity-chrome, regression)
Attachments
(1 file)
139.82 KB,
image/png
|
Details |
Steps to reproduce:
- https://code-kitchen.dev/html/button/
- optional , reload (F5)
Actual results:
The iframe content disappears right after it is displayed.
Expected results:
The iframe content should not disappear.
Chrome works as expected.
Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=26510fca112eff4a2f8a714f4c2a6079103fc6a7&tochange=e763b6e09a4914247ab86b3600acac8562e6c1d1
Reporter | ||
Updated•3 years ago
|
Reporter | ||
Comment 1•3 years ago
|
||
Comment 2•3 years ago
|
||
Initial observation - I can't reproduce this on mac for Firefox 96.0a1 (2021-11-15) with or without fission. I should check if this can be reproduced on linux.
Comment 3•3 years ago
|
||
needinfo'ing kmag because he said he would investigate.
Reporter | ||
Comment 4•3 years ago
|
||
I can also reproduce the issue in Nightly96.0a1(20211115215316) Ubuntu20.04.
Updated•2 years ago
|
Updated•2 years ago
|
Comment 5•2 years ago
|
||
This doesn't reproduce for me on the current nightly on OSX unless I have the devtools open, and even then only intermittently. That implies there's a timing/race issue here, which superficially sounds a lot like bug 1736570.. And digging in deeper, it does seem to be triggered the same way as bug 1736570:
- The iframe is in the source markup to begin with:
<iframe class="browser__content iframe-tag" data-v-5cf017ac></iframe>
- As one of the page's JS component mounts, they set the still-empty iframe's innerHTML:
mounted: function () {
var html = this.$el.querySelector('#slot-html code').innerText,
style = '';
this.$slots.css && (style = this.getStyleTag());
var iframe = this.$el.querySelector('.iframe-tag'),
t = iframe.contentDocument || iframe.contentWindow.document;
t.getElementsByTagName('body') [0].innerHTML = this.unescapeHtml('<div id="main-content">'.concat(html, '</div>').concat(style).concat('<style>img { max-width: 100%; } body { font-family: UI Gothic, Meiryo, sans-serif; }</style>')),
this.height ? iframe.style.height = ''.concat(this.height, 'px') : setTimeout((function () {
var e = t.getElementById('main-content').clientHeight;
iframe.style.height = ''.concat(e + 50, 'px')
}), 1000)
},
- Somehow the document for that iframe becomes blank after this point (it has no body innerHTML).
Even when I add a breakpoint on the line immediately after the one which sets the frame's innerHTML, the problem still intermittently reproduces, so it seems like the page itself isn't triggering this behavior.
Indeed, if I log the value of the iframe's document's readyState (t.readyState
in that function above), it's uninitialized
when the iframe is broken, and complete
when it is not. Also, when I similarly log the value of t
, both it and its body
element are no longer attached by the time I inspect them, when the iframe is broken (otherwise the devtools take me to the expected point in the inspector when it's working).
So it seems that this is the same issue we're seeing in bug 1736570.
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Reporter | ||
Comment 6•2 years ago
|
||
I can still reproduce the problem in Nightly98.0a1(20220202093701) Ubuntu20.04.
And I confirmed that the try build of Bug 1736570 Comment#76 solved this problem too.
Comment 7•2 years ago
|
||
Now that bug 1736570 was landed, I cannot reproduce this problem.
Would you please help verify? Thank you!
Comment 8•2 years ago
•
|
||
(In reply to Hsin-Yi Tsai [:hsinyi] from comment #7)
Now that bug 1736570 was landed, I cannot reproduce this problem.
Would you please help verify? Thank you!
Oh, NO ... it's getting harder to reproduce. But if I reload the page more times, I still encounter this issue.
Reporter | ||
Comment 9•2 years ago
|
||
And I found a more reliable STR for the latest Nightly 99.0a1.
STR:
- Open https://code-kitchen.dev/html/button/ in first tab
- Open new tab
- Close the first tab
- Reopen closed tab
Actual results:
The iframe content disappears right after it is displayed.
Comment 10•2 years ago
|
||
Hmm, "Reopen closed tab" smells like session (re)store.
Reporter | ||
Comment 11•2 years ago
|
||
FYI, On the good build(i.e, before Bug 1589102), it works as expected with STR of comment#9.
Comment 12•2 years ago
|
||
It seems to be much easier for me to reproduce, if I open https://code-kitchen.dev/html/button/ in the first tab. (How would the position of the tab matters? Is it just a coincidence?) Then press F5 to reload. Repeat pressing F5 several times (about 5 times). The issue is reproduced.
Updated•2 years ago
|
Comment 13•2 years ago
|
||
Changing the severity to S3 as the situation has been mitigated after bug 1736570. Please let me know if you see this differently.
Reporter | ||
Comment 15•6 months ago
|
||
WFM on 115esr as well as 121.0a1.
Description
•