Closed Bug 1758664 Opened 3 months ago Closed 3 months ago

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

Categories

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

Firefox 98
defect

Tracking

()

RESOLVED FIXED
100 Branch
Tracking Status
firefox-esr91 --- unaffected
firefox98 --- fixed
firefox99 --- fixed
firefox100 --- fixed

People

(Reporter: abruening, Assigned: smaug)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression)

Attachments

(3 files)

Attached file 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.

Attached image test.png

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

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.

Component: Untriaged → Widget: Gtk
Product: Firefox → Core

Could this be related to bug #1744352 ?

Component: Widget: Gtk → JavaScript Engine
Has Regression Range: --- → yes
Has STR: --- → yes
Component: JavaScript Engine → DOM: Navigation
Keywords: regression
Regressed by: 1745638

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

Flags: needinfo?(bugs)
Assignee: nobody → bugs
Flags: needinfo?(bugs)

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

Severity: -- → S3
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P2
Pushed by opettay@mozilla.com:
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
Status: NEW → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → 100 Branch

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
Attachment #9267097 - Flags: approval-mozilla-release?
Attachment #9267097 - Flags: approval-mozilla-beta?

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.

Flags: needinfo?(abruening)
Flags: in-testsuite+

(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.

Flags: needinfo?(abruening)

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.

Attachment #9267097 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

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.

Attachment #9267097 - Flags: approval-mozilla-release? → approval-mozilla-release+

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....

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

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?

Flags: needinfo?(bugs)

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.

Flags: needinfo?(bugs) → needinfo?(hsivonen)

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

Flags: needinfo?(hsivonen)

well, has anyone tried to find a regression range?

Flags: needinfo?(hsivonen)

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).

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

well, has anyone tried to find a regression range?

I'll try to bisect.

Flags: needinfo?(hsivonen) → needinfo?(htsai)
Blocks: 1764272
Flags: needinfo?(htsai)
You need to log in before you can comment on or make changes to this bug.