1980865 - Firefox blocked by macOS firewall after upgrading to macOS 15 Sequoia with firewall enabled—still not resolved

Status: RESOLVED DUPLICATE of bug 1979124

(Core :: Networking, defect, P1)

Description

[michael sorens]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36

Steps to reproduce:

Since https://bugzilla.mozilla.org/show_bug.cgi?id=1919173 was closed, this sounds like the identical issue, but I can report the issue has not been resolved. I upgraded to 141 on macOS Sequoia (15.5) and Firefox no longer attempts any network activity at all, exactly as described in that earlier bug. I realize from that bug report that this sounds like an Apple issue, but I think it would be useful for Firefox users to be tracking it here in Bugzilla.

Actual results:

Upgrade to 141.
Launch firefox.
Attempt to browse to any URL.
Nothing happens.

Some additional details not in the original issue.

1. Attempting to close firefox then activity monitor reports "firefox-not responding" and eventually opens the firefox crash reporter.
2. If I create a new profile (/Applications/Firefox.app/Contents/MacOS/firefox -P) the initial session that opens for that profile works fine. It is not until I close Firefox and relaunch it that the problem surfaces.

Expected results:

Should be able to browse to any URL.

Comment 1

[BugBot [:suhaib / :marco]]

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

Comment 2

[Stephen A Pohl]

Are you able to interact with the browser, or does it not respond to clicks? Are you able to load about:preferences, about:config or similar?

Comment 3

[michael sorens]

Yes, the browser is working fine responding to clicks, and loading about:support, about:preferences, etc. works fine. Just no network activity initiated at all when I click links or type in URLs.

Comment 4

[Stephen A Pohl]

Is this a permanent state? Or does something eventually "fix" it? Such as a browser restart, or system reboot? I'm going to send this over to networking. Could someone advise Michael on how to collect a networking log (or similar) for further investigation? I initially thought that this might be a duplicate of bug 1980171, but it appears that the browser session had to be running for a while before the problem started to occur there.

Comment 5

[michael sorens]

This is a permanent state. I have found no workaround to get past it.

Comment 6

[Valentin Gosu [:valentin]]

Can you capture some logs using these instructions? https://firefox-source-docs.mozilla.org/networking/http/logging.html
Use logging to a file if no pages work, and send the logs to [e-mail]

Thanks!

Comment 7

[michael sorens]

Sent log file as requested.

Steps:

1. Opened firefox.
2. Started logging.
3. In a new tab, attempted to open a random website (wikipedia).
4. Let it sit for 15 or 20 seconds while nothing happened.
5. Stopped logging.

Comment 8

[Valentin Gosu [:valentin]]

Thank you for the logs.
It does seem like the Socket Thread is completely stuck - as there is absolutely nothing in the log happening on the socket thread.
I have a few questions that would be really helpful:

1. Does disabling the firewall make Firefox work?
2. Would it be possible for you to record HTTP logs using the terminal? See these instructions https://firefox-source-docs.mozilla.org/networking/http/logging.html#macos - the reason it would be useful is so we can figure out which call on the socket thread is stuck.

Comment 9

[Valentin Gosu [:valentin]]

(In reply to Valentin Gosu [:valentin] (he/him) {{ AFK in July }} from comment #8)

Thank you for the logs.
It does seem like the Socket Thread is completely stuck - as there is absolutely nothing in the log happening on the socket thread.
I have a few questions that would be really helpful:

1. Does disabling the firewall make Firefox work?
2. Would it be possible for you to record HTTP logs using the terminal? See these instructions https://firefox-source-docs.mozilla.org/networking/http/logging.html#macos - the reason it would be useful is so we can figure out which call on the socket thread is stuck.

Comment 10

[Kershaw Chang [:kershaw]]

Hi Reporter,

When capturing the log, could you also add pipnss:5 to MOZ_LOG environment variable?
So, the first command would be like: export MOZ_LOG=timestamp,rotate:200,nsHttp:5,cache2:5,nsSocketTransport:5,nsHostResolver:5,pipnss:5.

Thanks.

Comment 11

[Valentin Gosu [:valentin]]

Also, can you check if the problem goes away if you set network.trr.mode to 5 in about:config ?

Comment 12

[michael sorens]

1. I first tried changing network.trr.mode from 0 to 5 in about:config. I then tried to load a website and nothing happened. So I reset network.trr.mode back to 0.

2. I then set up for logging with the MOZ_LOG and MOZ_LOG_FILE env vars, cd'ed to the app directory and launched... and everything worked normally! Now I had seen that first launch after creating a new profile things worked normally, too, but here I had NOT just created a new profile, so I was optimistic. I closed firefox and relaunched... and it still worked! Did it again, even rebooted, and it still was working. Finally I logged in to sync all my bookmarks and such... and still working. Yay!

Any thoughts on why it miraculously started working for me? I am dreading the next update where it might occur once more.

Comment 13

[Valentin Gosu [:valentin]]

(In reply to michael sorens from comment #12)

1. I first tried changing network.trr.mode from 0 to 5 in about:config. I then tried to load a website and nothing happened. So I reset network.trr.mode back to 0.

2. I then set up for logging with the MOZ_LOG and MOZ_LOG_FILE env vars, cd'ed to the app directory and launched... and everything worked normally! Now I had seen that first launch after creating a new profile things worked normally, too, but here I had NOT just created a new profile, so I was optimistic. I closed firefox and relaunched... and it still worked! Did it again, even rebooted, and it still was working. Finally I logged in to sync all my bookmarks and such... and still working. Yay!

Any thoughts on why it miraculously started working for me? I am dreading the next update where it might occur once more.

It's likely the change of network.trr.mode to 5, caused the issue to be fixed, but it required a browser restart.
You can check if that's the case by checking about:config to see if there is a doh-rollout.disable-heuristics pref.

Comment 14

[michael sorens]

Yes, there is a doh-rollout.disable-heuristics setting and it shows true.

So could you provide more details over what the issue was and what the fix did? Ultimately, would like to know if that is how I would fix it if it happens again. Thanks!

Comment 15

[Valentin Gosu [:valentin]]

This is a duplicate of bug 1979124.

With Default Protection, Firefox will try to check if it can use DoH and run some heuristics that look at the certificate store to see if there are any custom ones. But it seems this check triggers a bug that makes it lock up.
We'll fix it in bug 1979124, probably by removing that check.

Comment 16

[Kershaw Chang [:kershaw]]

Hi Mike,

We are considering to remove the Third-party Root Certificates check since that check may cause socket thread blocked.
However, we’re not certain whether removing it could cause problems for enterprise users. Do you have any insights?

For context, about 2% of users currently have DoH disabled because of this check.

Comment 17

[Mike Kaply [:mkaply]]

I can't picture a world where someone has a third party root cert for enterprise, but no other things related to policy.

Worst case, they could disable DoH if they needed to.