Massive issues since most recent Firefox update.

It does install and run! It was slow at first, […] Now, there was an alert that appeared under my address bar that says I have 12 unsent crash reports, and in going to that page I see that there are also 2 sent crash reports that start with bp-, as was mentioned by someone else earlier in this thread. Not sure if they’ll help as they were both before I began having this problem

The first launch can be slow as it's a new profile, new setup etc. so it pulls everything anew. It's also expected it eagerly autoupdates itself, being Nightly — I wanted to check exactly this anyway, the difference between 152 and 155 — and this sounds like you can confirm it breaks with version updates and when you install the older again it works again?

The two crashes you sent are unfortunately not v153 crashes so there's nothing to look at. If you can run any version that would allow you to go to the crash reporter and submit the unsent / recent ones, please do, and paste here as much of them as you can get from the past week.

Also, when I had Nightly open it closed itself (why, I’m not sure) and automatically updated itself, and when I reopened it I believe it said it was on v155, and the same issue persisted so I re-downloaded it to v152 and the issue is still not there while using this version.

If that's an actual change between revisions mozregression would be able to pinpoint what bug triggers it for you. I can write up some notes if you wanted to take it for a spin.

So I'm looking into similarly described issues ending up logged even in shutdown hangs/crashes e.g. crash-stats.mozilla.org/report/index/1d73fad7-275f-4acf-968f-70d820260725

There's something stuck in networking. For one report I found DuckDuckGo search suggestion hanging but that itself wouldn't halt all of the line; however you can still try to change the search engine and disable typeahead search suggestion if you're on DDG.

Looking for what's common between these systems… what's you setting for

  privacy.trackingprotection.defer_annotation.enabled

and does it help if you disable it? This should however be fixed in v154 so if you see it still in Nightly that's not the culprit.

I'm scanning for any v152→v153 regressions reported but all I see have been fixed in v154 already. 🤷

My Firefox crashes almost as soon as it is open. These are my top five crash reports: bp-9b746df7-6172-4a53-9a64-667d80260725 7/25/26, 6:29 AM View bp-822f2291-147b-4009-849d-43f5e0260725 7/25/26, 5:45 AM View bp-b2177c7d-25c7-438a-999e-3f9f60260725 7/25/26, 5:34 AM View bp-29bad069-4200-44ef-86a3-bf1770260725 7/25/26, 5:32 AM View bp-6052a51a-bd78-454d-bcc1-42d1d0260724 7/24/26, 5:08 PM

So I'm looking into similarly described issues ending up logged even in shutdown hangs/crashes e.g. crash-stats.mozilla.org/report/index/1d73fad7-275f-4acf-968f-70d820260725 There's something stuck in networking. For one report I found DuckDuckGo search suggestion hanging but that itself wouldn't halt all of the line; however you can still try to change the search engine and disable typeahead search suggestion if you're on DDG. Looking for what's common between these systems… what's you setting for privacy.trackingprotection.defer_annotation.enabled and does it help if you disable it? This should however be fixed in v154 so if you see it still in Nightly that's not the culprit. I'm scanning for any v152→v153 regressions reported but all I see have been fixed in v154 already. 🤷

Dunno about the OP, but I use google as my typeahead search engine. And the value for that key for me is "false". Also, this doesn't just happen when I search for things. Many times it will hang just by clicking a link on an open page. A few times (though more rarely) it will even open that way, so that I have to close it again immediately.

Is there a way to create some dump info when the issue is happening, so it might help you? Since it doesn't actually crash it doesn't create a crash dump.

The impact of the typeahead was basically that every single letter of every single keyword entered into the box made whole new cache busting connection under tracking protection scope and as these add up, and if some got blocked/stalled, they started blocking other ("visible"/user/tab) connections too. Thanks for checking, yeah that pref wouldn't exhibit the same on the Nightly so that was to rule it out completely for now.

Those "hanging" tabs, whether during browsing, or right after startup — there's no change if you refresh them or punch another URL in these? If you close a hanging one and open a separate one, that one exhibits the same? Flipping VPN and DoH both ways did nothing right? Do you rely on any network appliance to connect out? (Like, in browser Settings, if you go to Proxy options, flipping through default/none/system etc. no difference?)

There absolutely is both logging and profiling available, however I'd recommend opening a bug in that case, so the engineer taking a look will give you the right params/verbosity for what they need to see (esp. if you're stuck hanging, they might have tricks how to reach the logs even in that case etc.)

What genuinely would help the most if you have time and the bandwidth would be to grab a copy of mozregression (it has a Windows GUI app) and just tell it "good" release vs. "bad" release time frame and have it serve you build after build to try and see when it actually got broken. I'll post some links to previous notes to follow.

Also if you just need v152 for now to have a usable browser you can grab a copy from ftp.mozilla.org/pub/firefox/releases/152.0.6/ (possibly /win64 and /en-US or any other folder), make sure to back up your profile folder!!! since you're downgrading, and look here in the support threads for how to a) remove compatibility restriction on the profile to use it with older version, b) set a policy to disable updates. Or, I can post a link to a very early v153 nightly that can be close to the v152 code, won't complain about profile compatibility, and you can probably just clone your existing profile folder into it without having to touch your existing release one.

I previously described how to run the mozregression GUI e.g. in this thread: support.mozilla.org/en-US/questions/1591147#answer-1830544 linking to support.mozilla.org/en-US/questions/1589917#answer-1829099 where I posted some screens what to expect.

You just tell it:

 Last known good build:  152  release 
 First known bad build:  153  release

on the last screen and run. Try a build, quit it, and back in the tool click "good" vs. "bad" button and repeat when it pulls the next build.

Those "hanging" tabs, whether during browsing, or right after startup — there's no change if you refresh them or punch another URL in these? If you close a hanging one and open a separate one, that one exhibits the same? Flipping VPN and DoH both ways did nothing right? Do you rely on any network appliance to connect out? (Like, in browser Settings, if you go to Proxy options, flipping through default/none/system etc. no difference?)

When FF starts "hanging" it will then to that for any tab. What happens is that a new tab will simply load all white, the tab will have the preloader icon for a while and after some time it just stops. The tab shows the url of what I'm trying to load, but no site icon. There is no indication on the page of any error, it's just all white. If I then hit enter on the URL, hit F5, CTRL+F5 or close the tab and try to open a new one, same thing will happen. At this point, any navigation will do the same thing, whether it's a new tab or just navigating on an already open one, with the only difference being that an already open one keeps the tab icon and name.

The only way to go back to normal is to close FF. I then see that about 5-7 threads remain open for about 15-20s. If I try to open FF during that time I'll get a warning that FF is already open and whether I want to close it. If I simply wait until the threads do close properly, then it opens just fine and is working for some time.

Do you think me checking the regression links would me more helpful or should I just open a bug instead so I can submit a dump file?

Hey,

DJSamhein, regarding your question about capturing dump/log info since there is no crash report, you can check the browser's internal console logs in real-time when the blank page occurs.

Next time a tab freezes or loads completely blank: 1. Press F12 to open Developer Tools. 2. Go to the Console tab. 3. Look for any red Content-Security-Policy (CSP) violation blocks.

Hey, DJSamhein, regarding your question about capturing dump/log info since there is no crash report, you can check the browser's internal console logs in real-time when the blank page occurs. Next time a tab freezes or loads completely blank: 1. Press F12 to open Developer Tools. 2. Go to the Console tab. 3. Look for any red Content-Security-Policy (CSP) violation blocks.

Oh yeah, I have a bunch of those (I'm a programmer so I actually do use the console a lot, which means I've tried doing that already). Without FF hanging yet (at least so far), this site has a bunch of those. Basically 4 almost identical errors with: "Content-Security-Policy: The page’s settings blocked an inline style (style-src-attr) from being applied because it violates the following directive: “style-src 'self' https://*.webservices.mozgcp.net 'nonce-He978A5/W9Q/HmP13N8O6A=='”. Consider using a hash ('sha256-0EZqoz+oBhx7gF4nvY2bSqoGyy4zLjNF+SDQXGp/ZrY=', requires 'unsafe-hashes' for style attributes) or a nonce. Source: display:none;"

Other tabs I keep perma-open don't have that error except for gmail and facebook.

Last time I tried to open the console after a tab hang up, it wouldn't open. I then tried opening the console on an already open one and tried navigating there, but I don't remember the result. Next time it happens I'll try again.

Hey, DJSamhein, regarding your question about capturing dump/log info since there is no crash report, you can check the browser's internal console logs in real-time when the blank page occurs. Next time a tab freezes or loads completely blank: 1. Press F12 to open Developer Tools. 2. Go to the Console tab. 3. Look for any red Content-Security-Policy (CSP) violation blocks.

Oh yeah, I have a bunch of those (I'm a programmer so I actually do use the console a lot, which means I've tried doing that already). Without FF hanging yet (at least so far), this site has a bunch of those. Basically 4 almost identical errors with: "Content-Security-Policy: The page’s settings blocked an inline style (style-src-attr) from being applied because it violates the following directive: “style-src 'self' https://*.webservices.mozgcp.net 'nonce-He978A5/W9Q/HmP13N8O6A=='”. Consider using a hash ('sha256-0EZqoz+oBhx7gF4nvY2bSqoGyy4zLjNF+SDQXGp/ZrY=', requires 'unsafe-hashes' for style attributes) or a nonce. Source: display:none;"

Other tabs I keep perma-open don't have that error except for gmail and facebook.

Last time I tried to open the console after a tab hang up, it wouldn't open. I then tried opening the console on an already open one and tried navigating there, but I don't remember the result. Next time it happens I'll try again.

Same problem! refresh failed. froze again. atempted install froze again. used crome (which I despise) went to firefox, installed again. finished install. on firefox now, no problem yet. Oddly, when froze before, it keep reporting microsoft instead of to mozilla?

Yes, reinstalling / replacing corrupted app helps with this kind of a problem for most folks, however the question author already did that and ended up getting the same results using a separate installation which points at yet another problem than just a borked install location.

FWIW some older HW/OS users reported trying to disable some features helped them:

gfx.webrender.all → set to false
layers.acceleration.disabled → set to true
media.hardware-video-decoding.enabled → set to false

As for developer tools, I don't believe it's a site issue given no amount of changing locations in that tab seems to make a difference, but checking the Network pane might at least show if and how the initial request is done and if/why it fails. But I'm more leaning towards it just hanging. Not developer tools but "Browser Console" (a slightly different toolkit, in "More Tools" menu) might show something "internal" blowing up.

But in general it's either about:logging (set the default networking profile), or trying to get some useful results out of profiler.firefox.com but you might have trouble stopping the capture when everything goes wrong (engineers on a bug might give you terminal tips how to capture even failing processes).

Do you think me checking the regression links would me more helpful or should I just open a bug instead so I can submit a dump file?

Once you reproduce even on Nightly, it's definitely a bug territory. However it will take a few days of back and forth on a bug.

If you ARE able to actually pinpoint the changeset affecting your system with the bisection mentioned earlier, there might be either workarounds already available, the same issue already tracked over that regressor, or just having a report with a bisection at hand speeds up things by summoning the right people who work in that area of code.

So the mozregression run would be most helpful in the meantime. From anyone affected. Thanks.

It does install and run! It was slow at first, […] Now, there was an alert that appeared under my address bar that says I have 12 unsent crash reports, and in going to that page I see that there are also 2 sent crash reports that start with bp-, as was mentioned by someone else earlier in this thread. Not sure if they’ll help as they were both before I began having this problem

The first launch can be slow as it's a new profile, new setup etc. so it pulls everything anew. It's also expected it eagerly autoupdates itself, being Nightly — I wanted to check exactly this anyway, the difference between 152 and 155 — and this sounds like you can confirm it breaks with version updates and when you install the older again it works again?

The two crashes you sent are unfortunately not v153 crashes so there's nothing to look at. If you can run any version that would allow you to go to the crash reporter and submit the unsent / recent ones, please do, and paste here as much of them as you can get from the past week.

Also, when I had Nightly open it closed itself (why, I’m not sure) and automatically updated itself, and when I reopened it I believe it said it was on v155, and the same issue persisted so I re-downloaded it to v152 and the issue is still not there while using this version.

If that's an actual change between revisions mozregression would be able to pinpoint what bug triggers it for you. I can write up some notes if you wanted to take it for a spin.

When I run nightly, I can reach my crash log perfectly fine, and these are the ones dating back to July 18th:

9d14f18f-3397-460f-9bce-fafd50ec49c5 8fb29dec-9a7d-4530-9c81-14cb50a75765 ac3a7b49-d062-4f65-82d1-8e79fc61d775 8a27b271-dc99-42d5-9e71-651606031e00 bc37afda-6d63-457f-8ab2-c7a54da61036 58b3dc74-48ee-4e90-a60d-d0c318093c08

I'm not sure much help they'll be as I don't believe any of them are from v153; the first one is from last night when I was using Nightly, though I don't remember it crashing, and the two under it are from just before v153 installed. Before v153 installed my Firefox crashed and when I hit restart Firefox, it installed the new update. The next instance of me trying to open the browser is when I noticed the problem; the page loaded, froze, became non responsive, and had to be forced closed. (I've submitted all the crashes on my about:crashes page, but for some reason the crash reports from the 18th and 25th say they've failed.)

Also, yes, I can confirm that v152 works perfectly fine (I've been using it since last night with no issues) but v155 has the same issue of opening, freezing, and becoming non-responsive. I'm not sure how to find if I have that privacy setting enabled or not, so if you could tell me how I'd do my best to see if my old Firefox will load long enough for me to check.

Correct, release 153 is from Jul 20+ so while you can submit them, they probably won't hint at the current more significant issue you're seeing.

The various preferences listed are meant to be checked or changed using Configuration Editor for Firefox (appropriate warnings included on that page)

Since you can go from clearly "bad" to clearly "good" just changing versions, would you be willing to run the mozregression tool mentioned earlier? While it may look intimidating at first, the results might just be crystal clear and immensely helpful. Thanks!

I have changed the keys you mentioned above (the first one was already false). I'm waiting to see if that fixes it (I can sometimes go a few hours without FF hanging, because I'm not a heavy browser user, especially on the weekend). If it does, I'll report back and then I'll try to revert them and replicate the issue again and check console, profiler and regression.

Being a programmer myself I know the importance of having good data to fix things and that workarounds like these aren't satisfying, as they're bound to repeat the issue later on due to not being fixed. So I'll keep you posted, but most likely only tomorrow.

The caveats are mostly in terms of these pref flips being an experiment to compare, and if not successful, please create a reminder to flip them back after a while — as if they're not solving things, they actually might have negative performance impact.

I do however think that every reporter is facing a separate issue, as OP pretty much sees the regression impact right away, without any prolonged browsing necessary IIUC, it's not intermittent, but is immediately noticeable between "good" vs. "bad", barely making it into the internal settings pages, if ever.

Correct, release 153 is from Jul 20+ so while you can submit them, they probably won't hint at the current more significant issue you're seeing. The various preferences listed are meant to be checked or changed using Configuration Editor for Firefox (appropriate warnings included on that page) Since you can go from clearly "bad" to clearly "good" just changing versions, would you be willing to run the mozregression tool mentioned earlier? While it may look intimidating at first, the results might just be crystal clear and immensely helpful. Thanks!

I went through and changed the things you mentioned in about:config (in Nightly, so I don't think they'll have anything to do with the regular Firefox I'm having an issue with), but in doing so I noticed that privacy.trackingprotection.defer_annotation.enabled isn't there for me? Again, I'm in Nightly so maybe that isn't something 'present' in Nightly (I'm really out of my area of knowing how things work at this point), but I figured it was important to say I didn't find it. And I would be willing to downgrade back to v152, but I've searched around myself and seen that it creates a new profile for you. In doing so, does it delete the main one used, or just create a new one and leave the old one alone?

The privacy pref might have been set remotely for release; on nightlies it's added directly in code but only starting v153 (you should be able to just add it manually in advance /it's type "boolean"/ and then with the other prefs let that nightly update to latest — to see if those prefs have any effect for your system. If it doesn't work, you now know how to reset the nightly back to older version again;)…)

As for downgrading a profile, there's a way around it, see https://support.mozilla.org/en-US/kb/dedicated-profiles-firefox-installation#w_what-happens-to-my-profile-if-i-downgrade-to-a-previous-version-of-firefox but please do BACKUP!! the profile folder first. Ideally to three different places.

The privacy pref might have been set remotely for release; on nightlies it's added directly in code but only starting v153 (you should be able to just add it manually in advance /it's type "boolean"/ and then with the other prefs let that nightly update to latest — to see if those prefs have any effect for your system. If it doesn't work, you now know how to reset the nightly back to older version again;)…) As for downgrading a profile, there's a way around it, see https://support.mozilla.org/en-US/kb/dedicated-profiles-firefox-installation#w_what-happens-to-my-profile-if-i-downgrade-to-a-previous-version-of-firefox but please do BACKUP!! the profile folder first. Ideally to three different places.

I'll restart my Nightly first with these new privacy preferences & update it to see if it does anything different, and then try the new profile because I'm thinking if these work with Nightly, maybe I could go in and try the same changes to my regular Firefox and see if that's a potential fix...? I'll have to see if it changes anything in Nightly first, of course, and then see if I could even get my Firefox to work long enough to change those settings. And by backing up the profile folder, you mean the actual folder on my computer, correct?