Firefox will not load pages after latest update
Several Machines have been Updated to Firefox 58.0 (32 bit) and now web pages will not open. Ive tried starting Firefox with no add-ons, but when Firefox attempts to restart, nothing happens. I can see the process still running in the background, which I then have to kill in orderto get Firefox to start again.
I can navigate the Firefox Menus and everything else, its just that webpages will not load.
Several of our clients across different systems are re[porting the same problem
Chosen solution
could you test if the current 59.0 beta build addresses the problem for you: https://www.mozilla.org/firefox/beta/all/
Read this answer in context 👍 1All Replies (17)
hi, what security software /policies are in use on the affected systems?
philipp said
hi, what security software /policies are in use on the affected systems?
Varies across clients. the one constant is Webroot, which doesn't look as though it is blocking anything related to Firefox.
...Looks like this is a known problem:
I just re downloaded Firefox and everything appears to be working now
would you be able to identify a particular configuration in webroot that could affect the issue? (i'm not able to reproduce it by just downloading the secureanywhere trial from their homepage)
Not sure. Like I said, Webroot isnt showing any indication that it is blocking anything, and I do not see any previous overrides/exceptions for Firefox in place for any of our clients.
I was able to reinstall on my system by uninstalling, rebooting and reinstalling from Website. I just tried the same thing on another system, but issues still persist.
Modified by Tyrell0711
Can you find anything in the Windows Event Logs related to Firefox around the time this happens? As you know, after the first firefox.exe process (user interface) is loaded, Firefox will start to spin up additional firefox.exe content processes. It would be helpful to know if Windows has recorded anything about whether or why those processes are blocked or killed.
jscher2000 said
Can you find anything in the Windows Event Logs related to Firefox around the time this happens? As you know, after the first firefox.exe process (user interface) is loaded, Firefox will start to spin up additional firefox.exe content processes. It would be helpful to know if Windows has recorded anything about whether or why those processes are blocked or killed.
I am not getting any specific events from the Event log from either my PC or the User. When I used Fiddler on my PC, when ever I opened Firefox, the only address that was being tagged was getpocket.cdn.mozilla.net:443. Not sure if that means anything. We have nothing blocking that address. It works now on my 64bit machine after reinstall, but on users 32bit workstation, the problem persists.
Chosen Solution
could you test if the current 59.0 beta build addresses the problem for you: https://www.mozilla.org/firefox/beta/all/
philipp said
could you test if the current 59.0 beta build addresses the problem for you: https://www.mozilla.org/firefox/beta/all/
Works
Any possible ETA on when this will go from Beta to Public Release?
the patch has been approved to go into a dot-release for firefox 58, but i don't know the timing for this... if i had to guess, sometime next week (or weeks).
The Sooner the Better... Didn't realize how many of our clients actually rely on Firefox until today. They've been redirected to use Chrome. Better hurry before people have a new favorite browser LOL
Can this beta Be deployed via script, in a silent manner?
an update to 58.0.1 will be released in the coming hours ;-)
Not Sure if this will require a separate thread, but one of the Beta installs is now having an issue with Printing. No Matter the printer or Driver, Firefox just crashes and nothing gets printed. This even happens when trying to print to PDF. I sent in Several crash reports, with the email tyrell@ezmsp.com.
Please let me know if you need me to do anything to further troubleshoot
Hi Tyrell0711, could you start a new question about the print crashes, and include the crash report IDs? (Support volunteers cannot look up reports by email address because that information is hidden on the public interface.)