1764272 - Site shows only blank page in Firefox 91.8.0esr, works in previous versions

Status: RESOLVED FIXED

(Core :: DOM: Navigation, defect)

Description

[mit]

Steps to reproduce:

https://bugzilla.mozilla.org/show_bug.cgi?id=1758664 just in the ESR branch on 91.8.0esr x64 deDE

Actual results:

i assume a bug in the general release branch made it into esr while already having been fixed in the general branch

Expected results:

if esr gets the bugs, it should get the fixes as well :D

Comment 1

[Steven DeTar [:sdetar]]

Moving to DOM:Navigation as bug referred to in bug description is owned by that component.

Comment 2

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

(In reply to mit from comment #0)

Steps to reproduce:

https://bugzilla.mozilla.org/show_bug.cgi?id=1758664 just in the ESR branch on 91.8.0esr x64 deDE

Actual results:

i assume a bug in the general release branch made it into esr while already having been fixed in the general branch

Expected results:

if esr gets the bugs, it should get the fixes as well :D

Dear Reporter,
Thank you for reporting this issue, however I am not sure if I followed your comment.

Were you saying that you have seen a new regression in esr91.8? And which sites did you see only blank pages then? Specific URLs would be huge help here.

Patches in bug 1758664 were not uplifted to ESR and that bug was marked as esr91-unaffected, so I think the new issue you're seeing should be different from bug 1758664.

Comment 3

[mit]

Heyho,

phew... classic closed(customer only)-documentation app, intranet only.
So, aside from me managing the app in terms of updating via vendor source.... there's not much of a test site I can give you.

While it might be a different bug, I can give the following input:
Userprofile installs aren't yet locked down and one guy went and installed FF general release into his profile, while we already ship ESR machine-wide (users never check -_-).
He calls, app site doesn't open. Completely blank. Only him affected, not ESR, no other browsers.
So, perfectly fits this bug.
This gets fixed in GR branch, it works again (tested in FF portable 99.0.1 x64, and also uninstalled GR for the user of course...).
Then a bit later (didn't track the time window of course) the exact same thing happens in ESR now.

To add insult to injury:
Having cached data with FF GR portable, FF ESR can then bring up the site just as usual :)
Ctrl F5ing breaks it again.

The console logs "Uncaught DOMException: Permission denied to access property "document" on cross-origin object" but that's already from app-JS that tries to add some event listeners.
Aside from an initial page, png and favicon nothing is loaded in the network tab.

Let me know if I shall send you a mem snapshot or other stuff or if this already helped you enough :)

Oliver

Comment 4

[p.lambert1]

I can confirm the error. Since 91.8 an internal time booking website does only show a blank page, while having the same Permission denied error in the console.

Comment 5

[mit]

Atoss? 😛

Comment 6

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

(In reply to mit from comment #3)

Heyho,

phew... classic closed(customer only)-documentation app, intranet only.
So, aside from me managing the app in terms of updating via vendor source.... there's not much of a test site I can give you.

While it might be a different bug, I can give the following input:
Userprofile installs aren't yet locked down and one guy went and installed FF general release into his profile, while we already ship ESR machine-wide (users never check -_-).
He calls, app site doesn't open. Completely blank. Only him affected, not ESR, no other browsers.
So, perfectly fits this bug.
This gets fixed in GR branch, it works again (tested in FF portable 99.0.1 x64, and also uninstalled GR for the user of course...).
Then a bit later (didn't track the time window of course) the exact same thing happens in ESR now.

To add insult to injury:
Having cached data with FF GR portable, FF ESR can then bring up the site just as usual :)
Ctrl F5ing breaks it again.

The console logs "Uncaught DOMException: Permission denied to access property "document" on cross-origin object" but that's already from app-JS that tries to add some event listeners.
Aside from an initial page, png and favicon nothing is loaded in the network tab.

Let me know if I shall send you a mem snapshot or other stuff or if this already helped you enough :)

Oliver

Thank you for the details. However, they are not helpful enough for us to make this issue actionable. A simplified test case is needed here. Or, if you could offer a test account of your internal website for us (please also feel free to share the information to us via my email), we're happy to investigate.

Comment 7

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

We uplifted https://bugzilla.mozilla.org/show_bug.cgi?id=1736570, which touched about:blank code, to ESR 91.8. However, it's not clear to us what we've fixed since ESR to make the problem go away in non-ESR. Hopefully we will hear more from comment 6.

Comment 8

[mit]

Followup:
After having loaded the iframe-target directly, the site with the iframe actually starts working (until you ctrl-f5).
JS-disabled/safe mode don't change the behavior.
Investigation ongoing :)

Comment 9

[DoTan]

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #6)

(In reply to mit from comment #3)

Heyho,

phew... classic closed(customer only)-documentation app, intranet only.
So, aside from me managing the app in terms of updating via vendor source.... there's not much of a test site I can give you.

While it might be a different bug, I can give the following input:
Userprofile installs aren't yet locked down and one guy went and installed FF general release into his profile, while we already ship ESR machine-wide (users never check -_-).
He calls, app site doesn't open. Completely blank. Only him affected, not ESR, no other browsers.
So, perfectly fits this bug.
This gets fixed in GR branch, it works again (tested in FF portable 99.0.1 x64, and also uninstalled GR for the user of course...).
Then a bit later (didn't track the time window of course) the exact same thing happens in ESR now.

To add insult to injury:
Having cached data with FF GR portable, FF ESR can then bring up the site just as usual :)
Ctrl F5ing breaks it again.

The console logs "Uncaught DOMException: Permission denied to access property "document" on cross-origin object" but that's already from app-JS that tries to add some event listeners.
Aside from an initial page, png and favicon nothing is loaded in the network tab.

Let me know if I shall send you a mem snapshot or other stuff or if this already helped you enough :)

Oliver

Thank you for the details. However, they are not helpful enough for us to make this issue actionable. A simplified test case is needed here. Or, if you could offer a test account of your internal website for us (please also feel free to share the information to us via my email), we're happy to investigate.

Can't you use the test.html from https://bugzilla.mozilla.org/show_bug.cgi?id=1758664 ? Because this also replicates the issue in 91.8.0 ESR.

Comment 10

[DoTan]

Any news yet? Even with the rollout of Firefox 91.9.0 ESR the bug still persists. To replicate, consider following the steps mentioned here: https://bugzilla.mozilla.org/show_bug.cgi?id=1758664

Comment 11

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

(In reply to DoTan from comment #10)

Any news yet? Even with the rollout of Firefox 91.9.0 ESR the bug still persists. To replicate, consider following the steps mentioned here: https://bugzilla.mozilla.org/show_bug.cgi?id=1758664

(In reply to DoTan from comment #9)

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #6)

(In reply to mit from comment #3)

Heyho,

phew... classic closed(customer only)-documentation app, intranet only.
So, aside from me managing the app in terms of updating via vendor source.... there's not much of a test site I can give you.

While it might be a different bug, I can give the following input:
Userprofile installs aren't yet locked down and one guy went and installed FF general release into his profile, while we already ship ESR machine-wide (users never check -_-).
He calls, app site doesn't open. Completely blank. Only him affected, not ESR, no other browsers.
So, perfectly fits this bug.
This gets fixed in GR branch, it works again (tested in FF portable 99.0.1 x64, and also uninstalled GR for the user of course...).
Then a bit later (didn't track the time window of course) the exact same thing happens in ESR now.

To add insult to injury:
Having cached data with FF GR portable, FF ESR can then bring up the site just as usual :)
Ctrl F5ing breaks it again.

The console logs "Uncaught DOMException: Permission denied to access property "document" on cross-origin object" but that's already from app-JS that tries to add some event listeners.
Aside from an initial page, png and favicon nothing is loaded in the network tab.

Let me know if I shall send you a mem snapshot or other stuff or if this already helped you enough :)

Oliver

Thank you for the details. However, they are not helpful enough for us to make this issue actionable. A simplified test case is needed here. Or, if you could offer a test account of your internal website for us (please also feel free to share the information to us via my email), we're happy to investigate.

Can't you use the test.html from https://bugzilla.mozilla.org/show_bug.cgi?id=1758664 ? Because this also replicates the issue in 91.8.0 ESR.

Hi, can you kindly help me understand the expected result from the test.html https://bugzilla.mozilla.org/show_bug.cgi?id=1758664#c0 ? I am confused here.

The actual results I am seeing are the same on Firefox nightly102, Firefox release 100, Firefox ESR 91.07, Firefox ESR 91.08, Firefox ESR 91.09, or even Chrome 101, on Win11.
They are all showing the only one "Hi!" on top of the page. I haven't been able to manage to see "a blank page" on any of these versions.

However, there seems to be a small difference on ESR 91.08 and ESR 91.09. On these two versions, "Hi!" is the only content displayed. However, there is this console error Uncaught DOMException: Permission denied to access property "document" on cross-origin object attachment.cgi:14

On other versions, in addition to "Hi!", there is an extra error message saying "refused to connect (on Chrome) or can't open this page (on Firefox)." No uncaught DOMException message in console, but there is Content Security Policy: The page’s settings observed the loading of a resource at https://bugzilla.mozilla.org/test.html?rlc=1 (“frame-src”). A CSP report is being sent.

Comment 12

[DoTan]

Attachment: ChromeLatest.png

Comment 13

[DoTan]

Attachment: EdgeLatest.png

Comment 14

[DoTan]

Attachment: Firefox91.7.1esr.png

Comment 15

[DoTan]

Attachment: Firefox91.9.0esr.png

Comment 16

[DoTan]

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #11)

(In reply to DoTan from comment #10)

Any news yet? Even with the rollout of Firefox 91.9.0 ESR the bug still persists. To replicate, consider following the steps mentioned here: https://bugzilla.mozilla.org/show_bug.cgi?id=1758664

(In reply to DoTan from comment #9)

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #6)

(In reply to mit from comment #3)

Heyho,

phew... classic closed(customer only)-documentation app, intranet only.
So, aside from me managing the app in terms of updating via vendor source.... there's not much of a test site I can give you.

While it might be a different bug, I can give the following input:
Userprofile installs aren't yet locked down and one guy went and installed FF general release into his profile, while we already ship ESR machine-wide (users never check -_-).
He calls, app site doesn't open. Completely blank. Only him affected, not ESR, no other browsers.
So, perfectly fits this bug.
This gets fixed in GR branch, it works again (tested in FF portable 99.0.1 x64, and also uninstalled GR for the user of course...).
Then a bit later (didn't track the time window of course) the exact same thing happens in ESR now.

To add insult to injury:
Having cached data with FF GR portable, FF ESR can then bring up the site just as usual :)
Ctrl F5ing breaks it again.

The console logs "Uncaught DOMException: Permission denied to access property "document" on cross-origin object" but that's already from app-JS that tries to add some event listeners.
Aside from an initial page, png and favicon nothing is loaded in the network tab.

Let me know if I shall send you a mem snapshot or other stuff or if this already helped you enough :)

Oliver

Thank you for the details. However, they are not helpful enough for us to make this issue actionable. A simplified test case is needed here. Or, if you could offer a test account of your internal website for us (please also feel free to share the information to us via my email), we're happy to investigate.

Can't you use the test.html from https://bugzilla.mozilla.org/show_bug.cgi?id=1758664 ? Because this also replicates the issue in 91.8.0 ESR.

Hi, can you kindly help me understand the expected result from the test.html https://bugzilla.mozilla.org/show_bug.cgi?id=1758664#c0 ? I am confused here.

The actual results I am seeing are the same on Firefox nightly102, Firefox release 100, Firefox ESR 91.07, Firefox ESR 91.08, Firefox ESR 91.09, or even Chrome 101, on Win11.
They are all showing the only one "Hi!" on top of the page. I haven't been able to manage to see "a blank page" on any of these versions.

However, there seems to be a small difference on ESR 91.08 and ESR 91.09. On these two versions, "Hi!" is the only content displayed. However, there is this console error Uncaught DOMException: Permission denied to access property "document" on cross-origin object attachment.cgi:14

On other versions, in addition to "Hi!", there is an extra error message saying "refused to connect (on Chrome) or can't open this page (on Firefox)." No uncaught DOMException message in console, but there is Content Security Policy: The page’s settings observed the loading of a resource at https://bugzilla.mozilla.org/test.html?rlc=1 (“frame-src”). A CSP report is being sent.

Hi There
As far as I know, the test file is supposed to show "Hi!" multiple times when working correctly and just once when not.
I've opened the test.html with the latest Version of Chrome, Edge and with Firefox 91.7.1esr and Firefox 91.9.0esr.
The test.html was working as expected on Chrome, Edge and Firefox 91.7.1 but not on 91.9.0esr.
On Firefox 91.9.0esr I also get the DOMException.

Please see the screenshots attached.

Comment 17

[mit]

Attachment: test-20220516-main.html

Comment 18

[mit]

Attachment: test-20220516-target.html

Comment 19

[mit]

Attachment: 20220516_105324.png

Comment 20

[mit]

Save both html files locally and you get the exact scenario.

The result can be seen for ESR, GR and Chrome in the attached screenshot.

This is exactly the vendor app file (landing page), just removed the UUID (exchanged for test-20220516-target.html) and added the before/after p's.

Comment 21

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

(In reply to mit from comment #20)

Save both html files locally and you get the exact scenario.

The result can be seen for ESR, GR and Chrome in the attached screenshot.

This is exactly the vendor app file (landing page), just removed the UUID (exchanged for test-20220516-target.html) and added the before/after p's.

Thanks. I finally can reproduce this issue following comment 20, and confirm this is valid in both esr 91.8 and esr 91.9, but not exsiting in esr 91.7.

Note that https://bugzilla.mozilla.org/show_bug.cgi?id=1758664#c0 is still not working for me to detect the problem. That is, even on Chrome or esr 91.7, it's always ONE "Hi!".

Hi Brindusa, can we have QA help to get a esr 91.8 regression commit for this issue? Thank you.

Comment 22

[DoTan]

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #21)

(In reply to mit from comment #20)

Save both html files locally and you get the exact scenario.

The result can be seen for ESR, GR and Chrome in the attached screenshot.

This is exactly the vendor app file (landing page), just removed the UUID (exchanged for test-20220516-target.html) and added the before/after p's.

Thanks. I finally can reproduce this issue following comment 20, and confirm this is valid in both esr 91.8 and esr 91.9, but not exsiting in esr 91.7.

Note that https://bugzilla.mozilla.org/show_bug.cgi?id=1758664#c0 is still not working for me to detect the problem. That is, even on Chrome or esr 91.7, it's always ONE "Hi!".

Hi Brindusa, can we have QA help to get a esr 91.8 regression commit for this issue? Thank you.

Strange but ok! I'm glad to finally see some movement going on after one month of reporting. Good luck

Comment 23

[Alice0775 White]

I can reproduce this in esr91.8 Windows10.

Regression window:
https://hg.mozilla.org/releases/mozilla-esr91/pushloghtml?fromchange=4254211850f6d5cae52bbee6f3353ec305d088d9&tochange=d6b476cadd24b6e845de7853a19e71ba62c8a58d

Suspect: Bug 1736570

Interestingly,
The problem does not happens if Windows Narrator or any other a11y tools(ATOK Insight Japanese IME) is activated. (Restart Browser is necessary)

And fixed range of mozilla-central / autoland channel:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=2155ccd6f6b47558e80983803d684687dbbc2ddc&tochange=966d676908b33872a19cc58ca3737443e09985bf

So I think we need to port Bug 1758664 to esr91.

Comment 24

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

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

Comment 25

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

Set release status flags based on info from the regressing bug 1736570

Comment 26

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

(In reply to Release mgmt bot [:suhaib / :marco/ :calixte] from comment #25)

Set release status flags based on info from the regressing bug 1736570

Status is not right - this is ESR only.

Comment 27

[mit]

So...is this being worked on, or stuck in some kind of WaitingForX status?...

If I read it correctly

Needinfo requested from [e-mail].
27 days ago...

Comment 28

[thomas.deisenhammer]

any movement in that case?
It's now 23 days since last update!

Comment 29

[mit]

(In reply to thomas.deisenhammer from comment #28)

any movement in that case?
It's now 23 days since last update!
The last Mozilla update was 20220603, so quite a few more days actually 🤔🙄

Comment 30

[mit]

102.0esr (64-Bit)
issue not present.

Comment 31

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

(In reply to mit from comment #30)

102.0esr (64-Bit)
issue not present.

Thank you for confirming the status on the latest 102esr. Given this issue is resolved on the latest esr and not valid on the main trunk, I suggest we can close this issue.

Comment 32

[mit]

Yup.

Still, I highly suggest to improve upon everything this procedure involved.

And finally work on a MUI for corp envs before going for 20 different color schemes.
Otherwise I can stand 100% behind your dwindling market share.

Not looking forward to Chrome becoming Netscape 3, but that's what we're headed for currently -_-