1758664 - Site shows only blank page in Firefox 98, works in previous versions. Javascript/iframe-Related?

Status: RESOLVED FIXED

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

Description

[abruening]

Attachment: test.html

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:98.0) Gecko/20100101 Firefox/98.0

Steps to reproduce:

I'm trying to access our internal time tracking website (Bosch ATOSS) with the latest Firefox version, 98.0.

I have attached a modified version of the system's start page that tries to load itself. I'll try to attach a screenshot as well.

Actual results:

This results in a blank page, even on a new profile. The issue happens with the Linux and Windows version.

Expected results:

The page works fine in previous versions of Firefox and also in Edge/Chrome.

The attached test site shows "Hi!" once in Firefox 98, multiple times in the current ESR version and Chromium. Seems to indicate that something broke when it comes to Javascript and iframes.

Comment 1

[abruening]

Attachment: test.png

Screenshot of Firefox ESR 91.6.1, Chromium 99.0 and Firefox 98.0 displaying the test site.

Comment 2

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

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

Comment 3

[abruening]

Could this be related to bug #1744352 ?

Comment 4

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=4a674ef88a015482cab02be767c258a2d9a41f10&tochange=2c40cadf59fff8b18afd87e06e202c3da7914c48

Comment 5

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

:smaug, since you are the author of the regressor, bug 1745638, could you take a look?
For more information, please visit auto_nag documentation.

Comment 6

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

Attachment: Bug 1758664, don't try to recheck possible session history entry in the parent process if we're doing such check already, r=peterv

The code which this patch removes was clearly an oversight in the regressing patch.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/966d676908b3
don't try to recheck possible session history entry in the parent process if we're doing such check already, r=peterv

Comment 8

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/966d676908b3

Comment 9

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

Comment on attachment 9267097 [details]
Bug 1758664, don't try to recheck possible session history entry in the parent process if we're doing such check already, r=peterv

Beta/Release Uplift Approval Request

• User impact if declined: iframes loaded from session history even though the page expects different load.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This should be quite low risk, since it is removing a small oversight done in bug 1745638.
  Also, this whole case is very unusual, but it is still something that web pages can obviously do.
• String changes made/needed: NA

Comment 10

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

abruening, could you try Nightly https://www.mozilla.org/en-US/firefox/channel/desktop/#nightly to see if this is now fixed on your site.
I think one may need to wait still a bit though, possibly until tomorrow, before the fix is in the Nightly builds.

Comment 11

[abruening]

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

abruening, could you try Nightly https://www.mozilla.org/en-US/firefox/channel/desktop/#nightly to see if this is now fixed on your site.
I think one may need to wait still a bit though, possibly until tomorrow, before the fix is in the Nightly builds.

The site works as expected again with the nightly version 100.0a1 (2022-03-10).

Can we expect this fix to be in a point release of Firefox 98? I'm sure we aren't the only ones using this or similarly odd systems with Fx. At the moment I have to tell our users to fall back to MS Edge.

Comment 12

[Donal Meehan [:dmeehan]]

Comment on attachment 9267097 [details]
Bug 1758664, don't try to recheck possible session history entry in the parent process if we're doing such check already, r=peterv

Approved for 99.0b3. Thanks.

Comment 13

[Donal Meehan [:dmeehan]]

https://hg.mozilla.org/releases/mozilla-beta/rev/59379d5752dc

Comment 14

[Pascal Chevrel:pascalc (PTO until April 26)]

Comment on attachment 9267097 [details]
Bug 1758664, don't try to recheck possible session history entry in the parent process if we're doing such check already, r=peterv

No regression reported on beta since the uplift, approved for 98.0.2, thanks.

Comment 15

[Pascal Chevrel:pascalc (PTO until April 26)]

https://hg.mozilla.org/releases/mozilla-release/rev/4ee6736c3af4

Comment 16

[mit]

This bug has made it into 91.8.0esr 64 bit deDE (and probably the other langs as well), but not the fix....like...ugh....please check....

Comment 17

[mit]

didn't find any "reopen" button or something of that kind, so https://bugzilla.mozilla.org/show_bug.cgi?id=1764272

Comment 18

[Henri Sivonen (:hsivonen)]

smaug, regarding comment 16 and bug 1764272:

It seems to me that the line that the fix here removed (or the entire mCheckingSessionHistory field, for that matter) doesn't exist in ESR in the first place.

Do you have ideas of how the same user-visible problem could be fixed in ESR?

Comment 19

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

But this was a Fission bug. What caused bug 1764272 on ESR?
The patch here and bug 1745638 is all about SHIP, which is enabled with Fission only.

Comment 20

[Henri Sivonen (:hsivonen)]

I don't know what caused the problem on ESR: just that it's the same intranet app and the same symptom.

Comment 21

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

well, has anyone tried to find a regression range?

Comment 22

[mit]

Given I am a regular user of the application as well...
combined with https://wiki.mozilla.org/Release_Management/Calendar
-> I assume it was introduced in specifically 91.8.0.

Excerpts from my communication with Henri:

The app was last touched on March 14th when we updated from v14 to v15. It worked flawlessly then. *

• Context: I am using and updating FF regularly, so I was on 91.7.0 then (always shutting down over the weekend so

A few days later 91.8.0 Firefox ESR April 5, 2022 rolls around and bam 😊

Aside from that….I already gave them hell for not contacting you themselves.
It sounded like they just leaned back (I guess you see that happen often…), they only said it was fixed with 98.0.2, where the changelog site led me to this bug.
The other mentioned bugs didn’t find in my mind https://www.mozilla.org/en-US/firefox/98.0.2/releasenotes/

Additional info:

I tested something else right now…the landing page is the same for both, using some kind of funny iframing… the actual target page DOES load.
https://atoss.company.local/SES/html
= broken

        https://atoss.company.local/SES/uuid12456789/html
        = works

If a remote session is helpful to you, we will make time (Teamviewer).

Comment 23

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

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

well, has anyone tried to find a regression range?

I'll try to bisect.

Comment 24

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

See https://bugzilla.mozilla.org/show_bug.cgi?id=1764272#c23 for the regression range.