Firefox Community Forum

I just started up my new MacBook Pro, M5 pro machine and Firefox will not work. Tahoe 26.3 is OS.

Dale Howard Jonesboro, GA

PS--Safari and DuckDuck Go browsers are working normally.

While browsing on my desktop , I am unable to open E Shram Card blog. it appears like there is an error in connection , but despite of good connection, cannot open it.

Almost every internet site that I go to using Firefox I get this message, "Hmm. We’re having trouble finding that site.". When I use Google Chrome or Microsoft Edge, I can get to the site? I really like using Firefox, but if it does not work?

all the sights I've used for years will not open and will not work I can't even use them any more they work fine in other browsers don't know what you did but it is almost unusable

i want to access www.fintreeindia.com i pursue professional courses that's my class website and also i could not access youtube also my exam are nearly

Hmm. We’re having trouble finding that site.

We can’t connect to the server at healthy.kaiserpermanente.orghttps.

If you entered the right address, you can:

   Try again later
   Check your network connection
   Check that Firefox has permission to access the web (you might be connected but behind a firewall)

What does this mean and how do we fix it?

I literally cannot access any website at all. It was working just fine and dandy and suddenly, boom. It just stops working. I dunno if this is something that has been a problem for anyone else, but I do not want to switch back to chrome as it eats up my memory like a starving cow.

Any help would be wonderful.

Hi; I've signed up for the vpn, several times, but nothing appears. I don't see any box on the top right of any bar. I don't even know the symbol, but have checked all that are there. How do I turn it on? I found something about "privacy windows" but that just leads back to the signup page. I know it'll be simple, but I'm missing it totally.

Hello everyone,

We are currently investigating an issue where browsers are sending HTTP requests with Connection: close in the header during integrated Windows authentication (NTLM authentication) via SAML Service Provider (SP), leading to premature termination of the TCP connection.

This behavior occurs in the middle of the authentication process, preventing the NTLM authentication from completing and subsequently prompting for re-authentication.

We have observed the following browser behaviors:

Chrome and Edge: These browsers function without issues, communicating with Connection: keep-alive. Safari (macOS): Older versions of macOS with Safari exhibit the Connection: close behavior, leading to authentication failure. Newer versions of macOS with Safari work correctly with Connection: keep-alive. Firefox (macOS): Even on the latest versions of macOS, Firefox continues to attach Connection: close, resulting in authentication failure. Upon reviewing logs, we've identified that various browsers attach the Connection: close header during the NTLMSSP_NEGOTIATE request in the NTLM authentication sequence. Although this happens in an environment with a load balancer, we have confirmed that the load balancer is not modifying the header; rather, the client (browser) is adding it.

We would appreciate your insights into the conditions under which Firefox attaches Connection: close to HTTP requests, especially considering the differences across macOS versions and other browsers, addressing the following points:

Are there any known conditions or past cases where Firefox outputs Connection: close in an NTLM authentication environment via SAML SP? Given that older Safari versions show similar behavior, we are also considering if there's a common factor depending on NTLM authentication and browser version. What are the general heuristics, logic, or triggers for a browser to decide to "close" a connection or to attach Connection: close? We are particularly interested in cases that occur mid-authentication process. Could specific configurations (e.g., the combination of SAML and NTLM authentication, or the presence of an intermediate proxy/load balancer) potentially influence Firefox's Connection: close behavior? Are there any additional logs or debugging information we should collect from the Firefox client side to further pinpoint this issue? Any guidance or suggestions you could provide to help us resolve this problem would be greatly appreciated.

Thank you.