1772470 - Firefox doesn't attempt to load pages in Windows 7 compatibility mode under Windows 10

Status: RESOLVED DUPLICATE of bug 1769845

(Core :: Security: Process Sandboxing, defect, P1)

Description

[[e-mail]]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.5005.63 Safari/537.36 Edg/102.0.1245.30

Steps to reproduce:

After update to Firefox 101 none of the existing tabs loaded up after firefox restart.

Websites are accessible thru other web browser.

The reload button is disabled. Typing in an address doesn't work. Firefox doesn't look like it is even making and attempt on loading. "about:config" doesn't bring up the config page.

No error message is ever displayed.

Addresses from bookmarks don't get passed to the address bar.

Refreshing the install didn't fix the issue.

Turned off hardware acceleration manually. This didn't fix the issue.

Updated the graphics driver to the latest. This didn't fix the issue.

When closed firefox process hangs around a 5+ seconds so attempting to start a new instance of Firefox after closing the previous one trigger "Firefox is already running, but is not responding." error.

about:config/network.http.http3.enable set to false. This didn't fix the issue.

Firefox works as expected (pages load fine) in safe mode.

Same issue was experiences by another colleague. He downgraded to the previous version.

Hardware: i7-4770 with 32Gb, Windows 10 Pro, Nvidia Quadro K2200 graphics card.

Actual results:

None of the web pages loaded.

Expected results:

All of the webpages loads fine.

Comment 1

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

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

Comment 2

[Kershaw Chang [:kershaw]]

If about:config page doesn't work as well, I think this is not a networking issue.
Olli, do you recall any recent changes regarding docShell that could cause this issue?
Thanks.

Comment 3

[[e-mail]]

Further development:
Due to compatibility issues with Solidworks we are running Firefox and Thunderbird in Windows 7 compatibility mode. So the issue happened while Firefox was set to run in Win7 mode. Running off this setting resolved the issue. Pages load as expected.

Comment 4

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

Sounds rather unexpected problem.

Reporter, could you possibly try to find regression range for this
https://mozilla.github.io/mozregression/

Comment 5

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

Bob, could this be about some sanboxing related change?

Comment 6

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

(locally running Nightly using Windows 7 compat mode works fine)

Comment 7

[Bob Owen (:bobowen)]

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

Bob, could this be about some sanboxing related change?

Quite possibly.
Safe mode currently turns off win32k lockdown.
The fact this has happened in Fx101 though makes me wonder if the changes that caused bug 1769845 are also causing these problems.
I can see how win 7 compat mode might affect things, maybe it requires a combination of things.

I'm actually going to back those changes out, as it seems the issues are worse than the ones that it was an attempt to fix.

kadircan: I created a build without those changes, would you mind testing.
You might want to choose a custom install and use a different path:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/GFy8ruUqQ5WSsP38cw6bNg/runs/0/artifacts/public/build/install/sea/target.installer.exe
(Here's a zipped version if you prefer:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/GFy8ruUqQ5WSsP38cw6bNg/runs/0/artifacts/public/build/target.zip)

Comment 8

[Bob Owen (:bobowen)]

I can reproduce.
It is hitting this release assertion.
Presumably compat mode disables the ability to lock down win32k and our (or the chromium sandbox) version detection doesn't pick this up.

Comment 9

[Bob Owen (:bobowen)]

This should get fixed by bug 1769845, where I'm just going to remove this release assertion, because we clearly can't guarantee it.

I'm not going to dup this over though, because we should fix that fact that we are trying to turn on win32k lockdown at all when running in a mode that doesn't support it.

Comment 10

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

Redirect a needinfo that is pending on an inactive user to the triage owner.
:gcp, since the bug has high priority, could you have a look please?

For more information, please visit BugBot documentation.

Comment 11

[Bob Owen (:bobowen)]

(In reply to Bob Owen (:bobowen) from comment #9)

This should get fixed by bug 1769845, where I'm just going to remove this release assertion, because we clearly can't guarantee it.

I'm not going to dup this over though, because we should fix that fact that we are trying to turn on win32k lockdown at all when running in a mode that doesn't support it.

I think this was fixed by bug 1769845, I can no longer reproduce.
We still need to look at how we deal with compatibility mode, but I think trying to use this bug for that would probably lead to more confusion.