1415923 - macOS: Firefox unresponsive/freezes after locking screen, hangs with 100% CPU usage

Status: VERIFIED FIXED

(Core :: XPCOM, defect, P1)

Description

[Sebastian Kaspari (:sebastian; :pocmo)]

MacOS X 10.12.6 (16G1036) - MacBookPro

Firefox becomes unresponsive / laggy after the screen was locked for some time. The UI responds with a multiple second delay until the browser is restarted. At first I though this was somehow related to my specific device. But now after switching to a new device I have the same problem again.

STR:

* Lock the screen - I usually execute "Lock" via the Alfred3 prompt). Note that it's "Lock" and not "Sleep".

* Wait some time - Usually I notice the behavior after longer breaks. It needs to be at least long enough so that macOS askes for the password again.


Not sure if it's important, but some details about my setup:
* Two external displays
* Two Firefox windows - One on an external screen and another one on the MacBook
* Some pages that are always open: GMail, Google Calendar, IRCCloud, Slack, Hangouts, GitHub, Bugzilla

Comment 1

[Sebastian Kaspari (:sebastian; :pocmo)]

I think I observed this first with ~Firefox 55/56? But I'm not 100% sure.

Comment 2

[Riley Watkins]

I've experienced this too during my use of Firefox 57.0beta on macOS 10.12.6. My steps to reproduce are the same (I even lock my computer the same way with Alfred 3). And it only happens after being locked for a while (I want to say at least 15-20 minutes).

After unlocking my computer, when Firefox is focused, it appears entirely unresponsive. However, when I Cmd+Tab to a different application, then Firefox registers my action. For example, if I click on another tab to switch to it, nothing happens. When I Cmd+Tab to another app, then Firefox switches to the tab I clicked on. I have to restart the browser to get it back to a working state.

Comment 3

[Jeff Held]

Experiencing the same issue on Firefox 58.0b13 on MacOS 10.12.6, and also use Alfred 3's lock command.

Comment 4

[a_waal]

I have started experiencing exactly the same issue as described above, Firefox 61.0.2 on MacOs 10.12.6.
After locking the screen for a longer period(15-20 minuts seems rights), with Firefox as the application in focus, Firefox is unresponsible when unlocking. Only way to resolve it is to restart the application.

I lock the screen the ordinary way, not using Alfred3.

Comment 5

[Andreas Tolfsen ❲:ato❳]

I can also reproduce this when switching users on macOS.  Same
experience as a_waal that leaving Firefox in focus for 15-20 minutes
reproduces it.

To me this looks like a graphics related bug because the browser
itself responds to interaction.

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Could someone please use the profiler and create a session? This might give us the necessary information where all the CPU time is being spent.

Steps:

1) Install the profiler addon: https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler#Getting_the_Gecko_Profiler_Add-on

2) Starting the profiler

3) Locking the screen for the necessary time to reproduce the problem

4) Unlock the screen and wait some seconds before capturing the profile (https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem#Capturing_and_sharing_a_profile)

If you can please share the profile with us, that would be great.

Comment 7

[Brandon]

I have had this problem for about a year or so on a 2011 iMac. The problem seems worse on a new iMac Pro.

1) Use Firefox in one Mac user account
2) Login to a new user account (without logging out of the first)
3) Use Firefox in 2nd user account
4) Fast switch back to 1st user account
5) Firefox appears unresponsive. Technically, it actually is responsive. For example, if I left a Youtube page up, I can click where the video would be and I can hear it start playing, but visually you do not see anything. Likewise, I can cmd+T a new tab and start typing a URL, and even hit enter. Nothing will appear to happen. However, if I quit Firefox and restore the previous session, that new tab and website that I entered will load. So it's functioning, but there is just some kind of UI freeze going on.
6) Functionality can be immediately restored if I switch back to 2nd user account and immediately switch back to 1st user account (in other words, if I switch to the 1st user account twice).
7) Switching back to 2nd user account after Firefox functionality has been restored to 1st user account renders 2nd user account Firefox unresponsive.

I installed the Gecko Profiler and captured the above. But 10 minutes after clicking "Capture Profile" it says "We were unable to connect to the Gecko profiler add-on within thirty seconds. This might be because the profile is big or your machine is slower than usual. Still waiting..." Tried it a second time and same result.

Comment 8

[bor]

Same problem on iMac (27-inch, Late 2012) running Mojave (all recent versions as released).

Easy to reproduce and doesn't seem related to sleep/locking the computer.

1. Use Firefox in one Mac user account
2. Allow computer to sleep ===> All normal on wakeup
3. Lock screen (^Command-Q) ===> All normal on unlock
4. Switch to a new user account
5. Switch back to original account
6. Firefox unresponsive. Cannot use Gecko Profiler.

Wondering if this is a different bug to the one originally raised and if so, should a new bug be raised?

Comment 9

[patrick]

I can confirm that this bug is replicable by switching users in Mojave.

Comment 10

[patrick]

Sorry, hit save too soon. 2018 MacBook Pro 15", Mojave with latest updates, Firefox Quantum 65.0. The lack of responsiveness happens every time I use fast switch between users.

Comment 11

[Andreas Tolfsen ❲:ato❳]

I should note that this bug doesn’t reproduce when WebRender is
enabled (flip gfx.webrender.all in about:config to true and restart
Firefox).

Comment 12

[Brandon]

(In reply to Andreas Tolfsen ⦗:ato⦘ from comment #11)

I should note that this bug doesn’t reproduce when WebRender is
enabled (flip gfx.webrender.all in about:config to true and restart
Firefox).

Thanks, does that require Nightly? Not listed in config for 65.0.1

Comment 13

[roman.shevtsov]

Reproducible for me even with gfx.webrender.all enabled. Firefox cpu usage is >100% for a couple of minutes after waking up the Mac.

Comment 14

[xracoonx]

I experience the unresponsiveness after locking as well (MacOS Mojave 10.14.5, Firefox 67.0.4 but also with earlier versions). Nothing in Firefox reacts to clicks including the menu (except for the "Firefox" menu). Might be interesting to know that I have the same problem exists in Thunderbird 60. But I have not witnessed this in any other application.

Comment 15

[Wayne Mery (:wsmwk)]

(In reply to Brandon from comment #7)

II installed the Gecko Profiler and captured the above. But 10 minutes after clicking "Capture Profile" it says "We were unable to connect to the Gecko
profiler add-on within thirty seconds. This might be because the profile is big or your machine is slower than usual. Still waiting..." Tried it a
second time and same result.

(reference comment 6)

Before starting the profiler, change the profile interval from 1ms to something like 20 or 30 (don't forget to hit apply)

Comment 16

[Wayne Mery (:wsmwk)]

Attachment: profiler settings.png

Comment 17

[abepark01]

Using MacOS Mojave 10.14.6 and Firefox 68.01.

I had a good number of tabs open in Firefox; my computer went to sleep when it became idle.
When I logged in, none of the tabs and address bar was responding.

My workaround has been to just shut down and re-open Firefox again.

Comment 18

[xracoonx]

Just another curiosity about this bug, or at least how it manifest on my system (macOS latest updates):

It seems that Firefox responds to clicks but does not refresh the UI. For example, if I click on a tab, Firefox does now show the newly selected tab. However, if I drag the address bar, it shows the newly selected address transparent under the cursor. So, it seems that Firefox still responds but does not refresh the main window.

Comment 19

[xracoonx]

None of the additional circumstances note in the report, i.e.

• Two external displays
• Two Firefox windows - One on an external screen and another one on the MacBook
• Some pages that are always open: GMail, Google Calendar, IRCCloud, Slack, Hangouts, GitHub, Bugzilla

is relevant to reproduce the problem on my side. Though for me it is not just a multiple second delay but the UI is not refreshed at all.

Comment 20

[xracoonx]

Some more strangeness: I can actually get Firefox to update its UI by focusing another application's window and switching back to Firefox. For example, if I click on non-active tab on Firefox, press Alt-Tab to focus the next application, press Alt-Tab again to focus Firefox again, then Firefox shows the content of that tab. It's still non-functional in that it does not update on clicks though. Updates will only happen after focusing another application.

Comment 21

[[e-mail]]

Just chiming in to report I've experienced this as well, across multiple Mac machines, OS versions and Firefox versions. The steps to reproduce and setup is more or less identical to OP.

While this bug thread isn't exactly blowing up with popular demand, this issue appears to be affecting a non-trivial share of Firefox users on Mac, see eg

https://old.reddit.com/r/programming/comments/doib7b/firefox_70/f5on6tb

My guess is that Mac users who experience this when trying out Firefox simply conclude Firefox is a dud and go right back to Chrome without commenting on this thread. Who knows how large a share of potential userbase gets lost as a result?

Really hope a fix for this gets released soon!

Comment 22

[nick]

Chiming in to note that I just switched over to FF from Chrome on Mac, and the issue is happening here as well when switching between user accounts. FF appears to accept clicks and shows menu actions (e.g., confirmation if Cmd-Q is invoked), but the main window is blank and does not update at all. Quitting and restarting after changing user accounts is required here.

Comment 23

[dankan]

My problem is pretty much exactly the same as Brandon's (Comment 7). I am using Firefox 75.0 (but have been having the same problem for awhile now, so certainly going back a bunch of versions), and I am on Mac OS X 10.11.6 (El Capitan), on a Mac mini mid-2011. Not sure this is relevant, but I have a lot of tabs open on one user, fewer on the second user, various Firefox extensions on both. I don't think that matters, because it happens when switching in both directions (user 1 to 2, or user 2 to 1).

I cope by fast switching from user 1 to user 2 (Firefox unresponsive), then switching back to user 1, then back to user 2 (Firefox responds normally).

It's annoying...

Comment 24

[fdurieux]

I am still experiencing the problem of my FF browser freezing.
-> MacBook Pro ; macOS Catalina (10.15.4) ; Firefox 76.0.1 (64-bit)
-> Connected to external monitor only (i.e. the MacBook lid is closed)
-> 2 active users, both with FF browser opened
-> logged in FF with the same user account (synchronising account info)
-> using the LastPass plugin and the Facebook container.
Note: I have also experienced the 'freezing' without being logged in to my FF account and without any of the plugins activated.

Observed behaviour:
My FF browser keeps freezing when unlocking and/or switching accounts; I believe that the problem mainly (only?) occurs after a certain period of inactivity.
Alternatively clicking on the desktop and the FF browser allows me to close FF tabs or perform one single action (at the time) in the selected tab.
I need to close FF completely and restart, which is extremely annoying as very often I am in a remote session.

Does a workaround/fix exist for this problem?

I am really surprised that Mozilla seems to completely fail (or ignores?) to fix the root cause of this problem. Until then I will go back to some other shitty browser.

It's more than annoying, it sh*t!

/F

Comment 25

[fdurieux]

(In reply to [e-mail] from comment #21)

Just chiming in to report I've experienced this as well, across multiple Mac machines, OS versions and Firefox versions. The steps to reproduce and setup is more or less identical to OP.

While this bug thread isn't exactly blowing up with popular demand, this issue appears to be affecting a non-trivial share of Firefox users on Mac, see eg

https://old.reddit.com/r/programming/comments/doib7b/firefox_70/f5on6tb

My guess is that Mac users who experience this when trying out Firefox simply conclude Firefox is a dud and go right back to Chrome without commenting on this thread. Who knows how large a share of potential userbase gets lost as a result?

Really hope a fix for this gets released soon!

This problem has been around for years; it's classified as a P2. Wondering if anyone actually does something about them or if they just wait until the issues goes away by itself...

Comment 26

[Henrik Skupin [:whimboo][⌚️UTC+1]]

It would still be great to get a profile when Firefox is under such a situation. Documentation and step-by-step assistance can be found at https://profiler.firefox.com/. Please share such a profile with us. Thanks.

Comment 27

[Vincent H]

I have the same problem on 76.0.1 macOS catalina 10.15.4
Firefox is alive but the display is frozen.
I can make a new tab, but the screen does not refresh.
I can make a new window and the window works ok

Comment 28

[Zak]

Hi there,

New member and long-time user of Firefox.

I've been having this issue for a while now. I always thought it was to do with my 9-year-old MacBook Air, but I have a new MacBook Pro 2020 model which I got this week and have had the exact same thing happen today:

I've been using Firefox for maybe 20 minutes. I have about 4 tabs open. I put the computer to sleep and come back it in a bit. Firefox window is frozen (I can still see the current tab but when I click on another tab, nothing happens. I can minimise the app and maximise it again, but that's it. I keep trying a tab and nothing happens. After a few minutes, it changes to another tab but then stays stuck on that one. Usually on my old MacBook Air, it'd start working again, but today on the MB Pro, it wouldn't, so I had to quit the app completely.

I saw another bug thread about this, which I found via a Google search...but that thread was closed. I think that thread was blaming PowerNap in Max OSX, but I don't have PowerNap enabled at all. Unlike the user in the post above, I can't even make a new tab whilst it's frozen, I just can't do anything except minimising the app to the dock and then clicking on it again. There wasn't a crash as such, so I don't even have a crash report.

I'm on Mac OSX Catalina 10.15.6. Has anyone got to the bottom of the problem, at all? I really like Firefox but if this is going to keep on happening, I may have to switch to Safari or Chrome.

Thanks,

-Zak

Comment 29

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Zak, would you mind to attach a sample from the Firefox parent process through the Activity Monitor to that bug while Firefox is in such a state? That might already give us an idea what's going wrong. Thanks a lot.

Comment 30

[Zak]

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] from comment #29)

Zak, would you mind to attach a sample from the Firefox parent process through the Activity Monitor to that bug while Firefox is in such a state? That might already give us an idea what's going wrong. Thanks a lot.

Hi Henrik,

Thank you for responding.

Can you please advise how I can get a sample from the Firefox parent process? This is my first time on this forum, and reporting a Firefox bug at that. Also, can I only get the sample when the issue occurs? The issue occurred again the other day, but I could only minimise the app to dock and then bring it back up again. Occasionally it'd switch to one tab very slowly but then it'd get stuck on that one. This is in Catalina. On my old MBA 11" which is on High Sierra, after a few minutes it'd become useable again. Not in Catalina, though - I have to quit the app and reopen it.

Best,

-Zak

Comment 31

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Sure, I can do. Yes, the issue has to happen in Firefox when you want to sample the process. So here the steps:

1. Open the Activity Monitor and set a filter (search term) for Firefox
2. Try to get Firefox into the freeze state
3. Select the Firefox process in the Activity Monitor that doesn't contain Web Content
4. Click the gear icon in the toolbar and select Sample Process
5. A new window opens. Wait until the sampling is done, and click Save...
6. Upload the created file as attachment to this bug

Comment 32

[Zak]

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] from comment #31)

Sure, I can do. Yes, the issue has to happen in Firefox when you want to sample the process. So here the steps:

1. Open the Activity Monitor and set a filter (search term) for Firefox
2. Try to get Firefox into the freeze state
3. Select the Firefox process in the Activity Monitor that doesn't contain Web Content
4. Click the gear icon in the toolbar and select Sample Process
5. A new window opens. Wait until the sampling is done, and click Save...
6. Upload the created file as attachment to this bug

Thanks Henrik. Just a few questions:

1. Should I have Activity Monitor open all the time whilst I'm waiting for the bug to happen, or can I open it after the issue occurs?
2. On point 3 above which asks me to select the Firefox process in the Activity monitor which doesn't contain 'web content', when the problem occurs, are you expecting there to be just one process which doesn't contain 'Web Content'? I ask because whilst I type this and look at activity monitor, I see a number of 'web content' processes, one for 'webextensions', one for 'priveleged content' and one process which is just 'Firefox' which has the Firefox logo next to it. Is it the latter you're referring to, or should I be looking for a process which appears when it's broken?

Best,

-Zak

Comment 33

[Henrik Skupin [:whimboo][⌚️UTC+1]]

It doesn't matter when you open it. So feel free to do so whenever you want. And regarding the correct Firefox process you are correct that there are more then just only web content processes. So indeed you have to record the samples for the plain Firefox process. For verification it should usually also have the lowest PID given that it spawns all the other ones.

Comment 34

[Zak]

Attachment: Sample of Firefox.txt - Zak

Provided for Henrik.

Comment 35

[Zak]

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] from comment #33)

It doesn't matter when you open it. So feel free to do so whenever you want. And regarding the correct Firefox process you are correct that there are more then just only web content processes. So indeed you have to record the samples for the plain Firefox process. For verification it should usually also have the lowest PID given that it spawns all the other ones.

Hi Henrik,

So Firefox froze a short moment ago, my system had only been on the login screen for a few minutes and when I'd returned, it was stuck. However, I think by the time I saved the process, it had started working again. In any case, I've attached it to this thread. Please let me know if this is okay, or if I need to try to save a process again when it's frozen.

Thanks,

-Zak

Comment 36

[daniel]

I see the same problem with 80.0.1 on Mojave. It usually happens when switching back to my user account, where a Firefox session was open some time. I'm attaching a screenshot of the profiler, which is somewhat difficult to obtain, because Firefox is unresponsive, I press shift-control-1, try to switch tabs, then press shift-control-2, then minimize and un-minimize again, after repeating a couple of times, I get to see what's in the screenshot. Also the sample from Activity Monitor.

Comment 37

[daniel]

Attachment: Screenshot 2020-09-13 at 18.53.44.png

Screenshot of profiler.

Comment 38

[daniel]

Attachment: Sample of Firefox.txt

Sample from Activity Monitor.

Comment 39

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to Zak from comment #35)

So Firefox froze a short moment ago, my system had only been on the login screen for a few minutes and when I'd returned, it was stuck. However, I think by the time I saved the process, it had started working again. In any case, I've attached it to this thread. Please let me know if this is okay, or if I need to try to save a process again when it's frozen.

So you clearly have to get Firefox into that hang state and only sample then. Otherwise the expected information will not be found in the output. Also what I forgot, can you both please save the output after having selected "Per cent of parent" in the drop down?

Comment 40

[daniel]

It might be related to the screen saver. When I lower the screen saver timeout to 1 minute, open Firefox, switch to another user, then wait 2 minutes, then switch back, I can reliably reproduce the freeze.

When I start the profiler before switching, I can't reproduce the freeze. Somehow, the running profiler prevents the freeze.

Starting the profiler after the freeze also seems to get the freeze "unstuck".

I'm attaching a new set of sample and profiler screenshot.

Comment 41

[daniel]

Attachment: Sample of Firefox 3.txt

Comment 42

[daniel]

Attachment: Screenshot 2020-09-14 at 22.17.10.png

Comment 43

[daniel]

Display: Per Cent of Parent doesn't seem to affect the saved file, only the display on screen. Attaching a screenshot, too.

Comment 44

[daniel]

Attachment: Screenshot 2020-09-14 at 22.30.08.png

Comment 45

[Zak]

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] from comment #39)

(In reply to Zak from comment #35)

So Firefox froze a short moment ago, my system had only been on the login screen for a few minutes and when I'd returned, it was stuck. However, I think by the time I saved the process, it had started working again. In any case, I've attached it to this thread. Please let me know if this is okay, or if I need to try to save a process again when it's frozen.

So you clearly have to get Firefox into that hang state and only sample then. Otherwise the expected information will not be found in the output. Also what I forgot, can you both please save the output after having selected "Per cent of parent" in the drop down?

Thanks, Henrik. I'll aim to do this next time, and can hopefully save in time before it fixes itself.

Comment 46

[Zak]

(In reply to daniel from comment #40)

It might be related to the screen saver. When I lower the screen saver timeout to 1 minute, open Firefox, switch to another user, then wait 2 minutes, then switch back, I can reliably reproduce the freeze.

When I start the profiler before switching, I can't reproduce the freeze. Somehow, the running profiler prevents the freeze.

Starting the profiler after the freeze also seems to get the freeze "unstuck".

I'm attaching a new set of sample and profiler screenshot.

Interesting, thanks for the feedback. If the Activity Monitor app fixes the issue, that is rather weird. When you refer to screensaver here, are you responding to an actual screensaver? I have screensaver turned off, but my monitor light goes off after a minute or two.

Comment 47

[daniel]

(In reply to Zak from comment #46)

Interesting, thanks for the feedback. If the Activity Monitor app fixes the issue, that is rather weird. When you refer to screensaver here, are you responding to an actual screensaver? I have screensaver turned off, but my monitor light goes off after a minute or two.

Not the activity monitor app, but the Firefox profiler. When it's enabled and gathering data (with shift-ctrl-1) before switching users, it seems to prevent the freeze.

In System Preferences / Desktop & Screen Saver / Screen Saver tab, I have "Flurry" selected, Start after: 1 Minute, ( ) Show with clock, ( ) Use random screen saver. This is on the user account that runs firefox, not the user account I'm switching to. After switching users, I keep interacting (like opening Activity Monitor, draging around its window), the screen saver never gets visible. I would assume the screen saver of the background user should not trigger at all, but for some reason, it seems to help reproduce the problem.

Comment 48

[Zak]

(In reply to daniel from comment #47)

(In reply to Zak from comment #46)

Interesting, thanks for the feedback. If the Activity Monitor app fixes the issue, that is rather weird. When you refer to screensaver here, are you responding to an actual screensaver? I have screensaver turned off, but my monitor light goes off after a minute or two.

Not the activity monitor app, but the Firefox profiler. When it's enabled and gathering data (with shift-ctrl-1) before switching users, it seems to prevent the freeze.

In System Preferences / Desktop & Screen Saver / Screen Saver tab, I have "Flurry" selected, Start after: 1 Minute, ( ) Show with clock, ( ) Use random screen saver. This is on the user account that runs firefox, not the user account I'm switching to. After switching users, I keep interacting (like opening Activity Monitor, draging around its window), the screen saver never gets visible. I would assume the screen saver of the background user should not trigger at all, but for some reason, it seems to help reproduce the problem.

Thanks for explaining.

Comment 49

[Zak]

Attachment: Activity monitor parent process

FAO Henrik

Comment 50

[Zak]

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] from comment #39)

(In reply to Zak from comment #35)

So Firefox froze a short moment ago, my system had only been on the login screen for a few minutes and when I'd returned, it was stuck. However, I think by the time I saved the process, it had started working again. In any case, I've attached it to this thread. Please let me know if this is okay, or if I need to try to save a process again when it's frozen.

So you clearly have to get Firefox into that hang state and only sample then. Otherwise the expected information will not be found in the output. Also what I forgot, can you both please save the output after having selected "Per cent of parent" in the drop down?

Hi Henrik,

I just had the hanging issue now, and thankfully opening Activity Monitor didn't cure it, so I was able to save the process and selected 'per cent of parent' in the dropdown. Please see my latest attachment.

I'm hoping this helps in finding a solution to this problem.

Best,

-Zak

Comment 51

[daniel]

Here's how I can reproduce the freeze reliably with 81.0 on Mojave, with all add-ons disabled:

1. I have two user accounts ("mine" and "other").
2. My account has a 1 minute screen saver timeout (as described above).
3. Starting on my account, I close all Firefox instances, and start a fresh one.
4. First I open https://bugzilla.mozilla.org/show_bug.cgi?id=1415923
5. Then I open http://old.reddit.com/ in a second tab, so this is the visible tab
6. I switch to the other account
7. I wait 2 minutes, doing nothing
8. I switch back to my account
9. I still see the open tab, but when I try to click on the first one, nothing happens. Stuck. When I focus another application, Firefox processes some events, but still doesn't react to further clicks. It looks like it's processing one event when it looses focus, nothing else.

This is a Mac mini (Late 2014) with an Intel Iris graphics card, the Activity Monitor Sample Process output shows Intel related gl* in the stack of the Compositor thread, after step 5), in case that matters.

Comment 52

[Chris More [:cmore]]

After updating Mac OS 10.15.7, I am having this problem multiple times a day

Comment 53

[lgfa29]

I've been hitting this issue for a few months now, but it doesn't happen everyday. Today I was able to start collecting profile metrics while Firefox was in this unresponsive state after waking up my Mac. I also learned that after a few minutes Firefox starts working normally again.

Looking at the profile data (https://share.firefox.dev/36lcrQx) I noticed a lot of network activity coming from Twitter (api.twitter.com is <Page #58> in the profile I linked). The requests keep happening all night long (the first request took 16h to timeout). My guess is that Twitter has some kind of setInterval to check the API for updates, and, for some reason, the callbacks accumulate while the computer is sleeping?

Since I don't always have a Twitter tab open, this would explain why I wasn't hitting this every day.

I've disabled "Wake for Wi-Fi network access" in the "Energy Saver" setting . Let's see if that helps.

Comment 54

[Zak]

(In reply to lgfa29 from comment #53)

I've been hitting this issue for a few months now, but it doesn't happen everyday. Today I was able to start collecting profile metrics while Firefox was in this unresponsive state after waking up my Mac. I also learned that after a few minutes Firefox starts working normally again.

Looking at the profile data (https://share.firefox.dev/36lcrQx) I noticed a lot of network activity coming from Twitter (api.twitter.com is <Page #58> in the profile I linked). The requests keep happening all night long (the first request took 16h to timeout). My guess is that Twitter has some kind of setInterval to check the API for updates, and, for some reason, the callbacks accumulate while the computer is sleeping?

Since I don't always have a Twitter tab open, this would explain why I wasn't hitting this every day.

I've disabled "Wake for Wi-Fi network access" in the "Energy Saver" setting . Let's see if that helps.

Thanks for sharing this. I don't tend to have Twitter open or logged into on my Mac, and this Firefox freezing issue has been affecting me on both my MBA and MBP. Like you said, it sorts itself out after a few minutes though (or I just force close and re-open it), but it's very annoying. I don't want to switch to Chrome or Safari but if this continues, I may very well do so.

Comment 55

[[e-mail]]

I never have Twitter open anywhere, ever, and I still see this problem intermittently. It might be other open tabs of mine doing similar things to Twitter but def isn't only Twitter. My open tabs are usually exclusively work related things like Slack, Outlook, Gmail, Splunk, Grafana etc.

Comment 56

[lgfa29]

Yes, Twitter was just an example. Fetching data in the background periodically using JavaScript is a common pattern used by websites that display updates in real-time, so other sites could cause a similar problem.

Comment 57

[dankan]

I never have Twitter open, ever, and I still have the freeze problem intermittently - though it seems to be occurring less frequently than it used to. (Now using Catalina 10.15.7, Firefox 83.0.) I have lots(!) of tabs open. Very, very rarely, these might include Slack or Facebook, but never Outlook, Gmail, Splunk, Grafana. I think the only tabs that might be updating content would be my two webmail tabs (Fastmail).

Comment 58

[lgfa29]

(In reply to dankan from comment #57)

I never have Twitter open, ever, and I still have the freeze problem intermittently - though it seems to be occurring less frequently than it used to. (Now using Catalina 10.15.7, Firefox 83.0.) I have lots(!) of tabs open. Very, very rarely, these might include Slack or Facebook, but never Outlook, Gmail, Splunk, Grafana. I think the only tabs that might be updating content would be my two webmail tabs (Fastmail).

Yup, I am sorry for the confusion caused by my first message. I didn't mean Twitter was the problem, but rather the network requests that, for some reason, accumulate in the background while the computer is sleeping. When the computer wakes up Firefox tries to process all the enqueued requests, causing performance issues.

Comment 59

[[e-mail]]

(In reply to lgfa29 from comment #58)

... the network requests that, for some reason, accumulate in the background while the computer is sleeping. When the computer wakes up Firefox tries to process all the enqueued requests, causing performance issues.

Agreed! It seems obvious haha but you're kind of a genius for pointing that out! Wouldn't be surprised at all if indeed this is the problem! Such accumulated requests should either be canned (since they're old and probably irrelevant now), or, rather than processing them all out once or whatever the case may be, be executed in a way that doesn't result in performance issues.

Comment 60

[dankan]

But if an accumulation of background network requests is causing this issue, then wouldn't it always self-correct within a few minutes? My impression is that this does not happen - ie, that it does NOT self-correct. I will have to test it, next time it occurs.

Comment 61

[lgfa29]

(In reply to dankan from comment #60)

But if an accumulation of background network requests is causing this issue, then wouldn't it always self-correct within a few minutes? My impression is that this does not happen - ie, that it does NOT self-correct. I will have to test it, next time it occurs.

For me it did self-corrected, it just took a while (around 1m20s based on the metrics I collected). Give it a try next time it happens. Leave it be for a minute or two and see if it start working again.

(In reply to [e-mail] from comment #59)

(In reply to lgfa29 from comment #58)

... the network requests that, for some reason, accumulate in the background while the computer is sleeping. When the computer wakes up Firefox tries to process all the enqueued requests, causing performance issues.

Agreed! It seems obvious haha but you're kind of a genius for pointing that out! Wouldn't be surprised at all if indeed this is the problem! Such accumulated requests should either be canned (since they're old and probably irrelevant now), or, rather than processing them all out once or whatever the case may be, be executed in a way that doesn't result in performance issues.

I will have more time next week to debug it further and try to come up with a faster way to reproduce it. Waiting for hours is not a great way to test it....

Comment 62

[dankan]

Ok, maybe I will have the patience to wait a couple of minutes to see if it sorts itself out - but maybe I won't, since the faster way to resolve it is just to switch back and forth between users again. Switch from user 1 to user 2 - Firefox frozen - switch back to user 1, and then back again to user 2 - Firefox is fine again.

Comment 63

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I wonder if anyone of you have Power Nap (AppNap) enabled in the Energy settings. Does disabling it help to get around this problem?

Comment 64

[lgfa29]

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] from comment #63)

I wonder if anyone of you have Power Nap (AppNap) enabled in the Energy settings. Does disabling it help to get around this problem?

How did I miss that...it's right under the "Wake for Wi-Fi network access" checkbox (which didn't help).

I have disabled "Power Nap" now. I will report back if it helps with this problem.

Comment 65

[Zak]

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] from comment #63)

I wonder if anyone of you have Power Nap (AppNap) enabled in the Energy settings. Does disabling it help to get around this problem?

I have Power Nap turned off, and I still experience the issue, I'm afraid. I think someone may have brought this earlier in the thread or maybe I read it somewhere else.

I never have Twitter open anywhere, ever, and I still see this problem intermittently. It might be other open tabs of mine doing similar things to Twitter but def isn't only Twitter. My open tabs are usually exclusively work related things like Slack, Outlook, Gmail, Splunk, Grafana etc.

I always have a Gmail tab open, so I wonder if this may be contributing to it. I used to use the Mail app exclusively but found out it was sometimes creating something like 40+ drafts on one message, so I stopped using it and started using the web interface.

Comment 66

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Zak, I assume the Gmail tab is pinned? As such it wouldn't be throttled when in background. If that is the case maybe you can unpin it for a couple of days and check if that makes a difference for you?

Comment 67

[Zak]

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] from comment #66)

Zak, I assume the Gmail tab is pinned? As such it wouldn't be throttled when in background. If that is the case maybe you can unpin it for a couple of days and check if that makes a difference for you?

Hi Henrik,

No, the Gmail tab isn't pinned. It's just the first website I manually go to when I start up Firefox. Based on this, is there anything you think I should try?

Thanks.

Comment 68

[lgfa29]

Another round of tests:

• Disabling "Power Nap" didn't help. From their help page it also seems to only apply to Apple's applications.
• I was interpreting the previous profile I sent wrong...I didn't notice it was only showing a sub-process, that's why api.twitter.com was the only website listed as flooding the network request queue. I generated a new profile today (https://share.firefox.dev/2I1Ol3L) and looking at the parent process I can see all kinds of website having the same behaviour (Twitter, GMail, Google Calendar, Google Docs, and a Discuss forum were the top hitters).
• It didn't seem to mater if the tab was in the foreground, background or pinned, they were all attempting network requests while the computer was asleep, but I will have to make more tests to confirm.
• I left a Firefox window as the active window before putting the computer to sleep. I might try minimizing all windows and see if it has any impact.

I will try to get a more controlled test environment and some kind of test matrix.

Henrik,

let me know if you have any ideas on what kinds of tests would be helpful.

Comment 69

[Patrik Thunström]

I think your findings are starting to circle it down, lgfa29.
They reflect what I'm seeing as well.

Basically, leaving my computer to sleep from one evening to the next (rarely use the computer day time during week days) I experience about 30-45 seconds of Firefox "trying to catch up" (very rough description), while if it only sleeps over night, like today during the weekends, I at most experience 5-10 seconds, short enough to not really consider it an issue.

The real problems comes whenever I don't use my desktop computer for multiple days, as that can definitely lead to 2-3 minutes, sometimes even more, before Firefox is responsive again.

Similar to other reports here I have quite a few tabs open that likely tries to do background tasks, mainly Gmail, FB and LinkedIn, but likely also some of the forums.

One thing that I thought made a little difference initially, but maybe that was just placebo, was enabling WebRender as someone suggested earlier. The initial experience is that it reduced the sluggishness.

Comment 70

[Stephen A Pohl [:spohl]]

Comments seem to point at queued network requests. Tentatively sending to Core:Networking for further triage.

Comment 72

[lgfa29]

Hi everyone,

I've been investigating this further for the past days. Here is a summary of what I found:

1. MacOS has multiple sleep levels (sleep, hibernate, safe sleep, standby), that are triggered at different times, and apps behave differently in each of them.
2. Firefox only fully stops when MacOS enters standby mode, but this is true for other browsers as well (Chrome and Safari).
3. Some add-ons prevent Firefox from completing network requests while the OS is in any sleep mode.

So I believe the bug is that last point: add-ons are affecting how Firefox behaves when the computer is sleeping.

I also don't think this is related to any specific add-on since I flagged 3 of the ones I use as causing this problem (namely: NoScript Security Suite, HTTPS Everywhere, and Privacy Badger), and I suspect more could cause this as well.

Next I will go into some more details on the tests I performed.

How I tested it

I create a simple webserver (source, Docker image) that serves a page that, once every second, makes an HTTP request back to the server and a simple DOM update.

I also left the Developer Tools opened to prevent caching so I could monitor request activity from the server logs during short test sessions. But even with cache enabled I observed Firefox freezing in longer test runs.

My environment is as follows:

• 2019 MacBook Pro with MacOS Catalina (10.15.7)
• Firefox 84.0
• Single window and tab opened with my test app

The test itself was simple:

1. Start the webserver in a second computer
2. Open the test page
3. Close the laptop or click  > Sleep
4. Wait a few seconds
5. Open laptop or wake up computer

I also repeated these steps but with a longer wait time (overnight) just to confirm that Firefox would freeze. I wasn't able to create a test where this behaviour happened with a short wait time (even with 10ms between requests it would take a few hours)

Results

As I mentioned in my summary there are many factors that influenced the results of the tests, so I will describe what I observed in each variation, but first a side note on MacOS sleep modes.

MacOS Sleep Modes

All my tests were done on a 2019 MacBook Pro running MacOS Catalina (10.15.7). When you close the lid of a Mac laptop, it enters the safe sleep mode, where the video is turned off and memory content is dumped to disk, but RAM and CPU are still powered, albeit at lower levels.

In this mode Firefox is still operational, DOM updates still happen and, without add-ons, network requests are also made as evidenced by server-side activity.

If the laptop is not plugged in into a power source, after a certain time threshold (which depends on your battery level), MacOS will enter standby mode, which completely shuts down everything, including RAM and CPU. At this point no activity is logged in the server anymore and DOM updates stop happening. When the computer wakes back up, the output messages have a time gap, and Firefox resumes as if nothing happened.

For my tests I reduced the threshold to trigger standby mode to 0.

Test 1: Firefox in "Safe Mode", AC power.

• Firefox profiler
• Server logs

Everything worked and requests and DOM updates kept happening even when the laptop lid was closed. You can see in this image the the page was being updated and, from the profiler, requests were also being completed at the same regular interval.

Test 2: Firefox in "Safe Mode", Battery power.

• Firefox profiler
• Server logs

Things start just like before and some requests and DOM updates still happen for a few seconds before the computer enters standby mode (I have artificially lowered the standby threshold to 0 trigger it more quickly).

The page output shows the same result as before for a while, but then, in the highlighted area, the messages stops, which is when standby starts. The server logs also show no activity for this period. Once the lid is opened, the messages start showing again.

The profile tracing shows a similar pattern, but also an interesting result, which is that calls to detectportal.firefox.com/success.txt also present the "catching up" network behaviour that we we'll see when add-ons are enabled.

Test 3: Firefox with add-ons, AC power.

• Firefox profiler
• Server logs

This is the normal operation tests, where add-ons are enabled and the computer is plugged-in to power. The requests cease as soon as the lid is closed, but, as we can see in the page screenshot, DOM updates still happen.

When the computer wakes up again, this is when trouble happens. All of the requests that didn't complete while the lid was closed are executed at once, as evidenced by the profiler.

Most of the requests are stuck in "Waiting for socket thread", so maybe a fix would be to set a timeout on this?

Test 4: Firefox with add-ons, Battery power.

• Firefox profiler
• Server logs

As expected, this is a combination of the previous two tests: requests are halted as soon and the lid closes, but DOM updates continue for a bit until standby mode kicks in around the highlighted region here. The lid is then re-opened and all the pending requests are unblocked at once.

TL;DR

In some situations Firefox is not able to complete network requests (which get stuck in "Waiting for socket thread") while MacOS is in safe sleep mode (CPU and RAM still active). Some add-ons seem to be triggering this, but there might be other causes as well since detectportal.firefox.com/success.txt also shows a similar behaviour.

For now, if you have a laptop, a (not great) workaround might be to unplug it from power before leaving it closed for a longer period of time (some hours).

I am sorry for the long message, but I hope that it helps getting this fixed. I am out of ideas now, so if there's anything else anyone would like met to test, just let me know.

Comment 73

[Zak]

(In reply to lgfa29 from comment #72)

Hi everyone,

I've been investigating this further for the past days. Here is a summary of what I found:

1. MacOS has multiple sleep levels (sleep, hibernate, safe sleep, standby), that are triggered at different times, and apps behave differently in each of them.
2. Firefox only fully stops when MacOS enters standby mode, but this is true for other browsers as well (Chrome and Safari).
3. Some add-ons prevent Firefox from completing network requests while the OS is in any sleep mode.

So I believe the bug is that last point: add-ons are affecting how Firefox behaves when the computer is sleeping.

I also don't think this is related to any specific add-on since I flagged 3 of the ones I use as causing this problem (namely: NoScript Security Suite, HTTPS Everywhere, and Privacy Badger), and I suspect more could cause this as well.

Next I will go into some more details on the tests I performed.

How I tested it

I create a simple webserver (source, Docker image) that serves a page that, once every second, makes an HTTP request back to the server and a simple DOM update.

I also left the Developer Tools opened to prevent caching so I could monitor request activity from the server logs during short test sessions. But even with cache enabled I observed Firefox freezing in longer test runs.

My environment is as follows:

• 2019 MacBook Pro with MacOS Catalina (10.15.7)
• Firefox 84.0
• Single window and tab opened with my test app

The test itself was simple:

1. Start the webserver in a second computer
2. Open the test page
3. Close the laptop or click  > Sleep
4. Wait a few seconds
5. Open laptop or wake up computer

I also repeated these steps but with a longer wait time (overnight) just to confirm that Firefox would freeze. I wasn't able to create a test where this behaviour happened with a short wait time (even with 10ms between requests it would take a few hours)

Results

As I mentioned in my summary there are many factors that influenced the results of the tests, so I will describe what I observed in each variation, but first a side note on MacOS sleep modes.

MacOS Sleep Modes

All my tests were done on a 2019 MacBook Pro running MacOS Catalina (10.15.7). When you close the lid of a Mac laptop, it enters the safe sleep mode, where the video is turned off and memory content is dumped to disk, but RAM and CPU are still powered, albeit at lower levels.

In this mode Firefox is still operational, DOM updates still happen and, without add-ons, network requests are also made as evidenced by server-side activity.

If the laptop is not plugged in into a power source, after a certain time threshold (which depends on your battery level), MacOS will enter standby mode, which completely shuts down everything, including RAM and CPU. At this point no activity is logged in the server anymore and DOM updates stop happening. When the computer wakes back up, the output messages have a time gap, and Firefox resumes as if nothing happened.

For my tests I reduced the threshold to trigger standby mode to 0.

Test 1: Firefox in "Safe Mode", AC power.

• Firefox profiler
• Server logs

Everything worked and requests and DOM updates kept happening even when the laptop lid was closed. You can see in this image the the page was being updated and, from the profiler, requests were also being completed at the same regular interval.

Test 2: Firefox in "Safe Mode", Battery power.

• Firefox profiler
• Server logs

Things start just like before and some requests and DOM updates still happen for a few seconds before the computer enters standby mode (I have artificially lowered the standby threshold to 0 trigger it more quickly).

The page output shows the same result as before for a while, but then, in the highlighted area, the messages stops, which is when standby starts. The server logs also show no activity for this period. Once the lid is opened, the messages start showing again.

The profile tracing shows a similar pattern, but also an interesting result, which is that calls to detectportal.firefox.com/success.txt also present the "catching up" network behaviour that we we'll see when add-ons are enabled.

Test 3: Firefox with add-ons, AC power.

• Firefox profiler
• Server logs

This is the normal operation tests, where add-ons are enabled and the computer is plugged-in to power. The requests cease as soon as the lid is closed, but, as we can see in the page screenshot, DOM updates still happen.

When the computer wakes up again, this is when trouble happens. All of the requests that didn't complete while the lid was closed are executed at once, as evidenced by the profiler.

Most of the requests are stuck in "Waiting for socket thread", so maybe a fix would be to set a timeout on this?

Test 4: Firefox with add-ons, Battery power.

• Firefox profiler
• Server logs

As expected, this is a combination of the previous two tests: requests are halted as soon and the lid closes, but DOM updates continue for a bit until standby mode kicks in around the highlighted region here. The lid is then re-opened and all the pending requests are unblocked at once.

TL;DR

In some situations Firefox is not able to complete network requests (which get stuck in "Waiting for socket thread") while MacOS is in safe sleep mode (CPU and RAM still active). Some add-ons seem to be triggering this, but there might be other causes as well since detectportal.firefox.com/success.txt also shows a similar behaviour.

For now, if you have a laptop, a (not great) workaround might be to unplug it from power before leaving it closed for a longer period of time (some hours).

I am sorry for the long message, but I hope that it helps getting this fixed. I am out of ideas now, so if there's anything else anyone would like met to test, just let me know.

Thanks a lot for your effort and such a detailed post! Really useful to know. I didn't think I have any add-ons on my Firefox - just checked it and nope, zero add-ons! This is on a MBP I bought a couple of months ago though, so I haven't really had a need or gotten around to it. Thjat said, I've still had this freezing issue.

I think someone else mentioned in this thread that when it freezes, if you go to the Mac OS login screen and switch back in, it should resolve it. It has worked for me twice so far. I'd prefer a proper fix for this though!

Comment 74

[Will]

The Firefox bug described in this thread describes the issue I'm seeing with Firefox on MacOS Catalina extremely well, even with the newest edition of Firefox (84.0.2). I think I captured the offending behavior in a profiler recording, but I'm not entirely sure. I tried using the profiler link above to upload it, but I'm not sure what to do with it now. Here's a direct link to it if that helps:
https://share.firefox.dev/3oPUfVM

Comment 75

[leosole]

I'm experiencing the same issue on Big Sur, with Firefox 85.0b9.
In my case, apparently if the window is minimized Firefox won't freeze.

Comment 76

[gabriel]

I have the same issue on Big Sur with FF 84.0.2 (64 bits)

Comment 77

[Val]

Any ideas how to fix this? It freezes after locking on my M1 Mac mini. FF 84.0.2 and MacOS 11.1 (20C69). Other apps are working fine. Have to use Chrome now, which I don't like :-(

Comment 79

[Gian-Carlo Pascutto [:gcp]]

I'm going to raise the severity here as the number of reports we're getting has noticeably increased. It might be much easier to trigger on Big Sur and/or the M1.

Jens, can you re-triage this?

Comment 80

[Zak]

Thanks for this, Gian-Carlo.

For the recent comments about M1s - this has also been affecting Intel Macs for a while. My MBA 11" had this issue on Sierra and High Sierra, and now my Intel MBP on Catalina has the issue too.

Someone did share a way to get the browser to work again after the lock: just go to the fast user switching screen and log back in. This has worked for me. Whenever it locks, I go back to the login screen and log back in. Obviously this doesn't stop it locking up in the first place, but it's better than nothing, right?

Comment 81

[lgfa29]

I was able to get another Profile report today. I hope it helps: https://share.firefox.dev/2KOXQVu

Comment 82

[Kershaw Chang [:kershaw]]

Attachment: bug1415923.log

Thanks a lot for the detailed steps and report provided by llgfa29.
I've tried to reproduce this as the steps in comment #72 and I found one possible reason of this bug.
From the attached log, it looks like when NS_WIDGET_SLEEP_OBSERVER_TOPIC event is observed (at line 2729), http requests are still created but are suspended by web extension code here. After a while, when the system is awake, NS_WIDGET_WAKE_OBSERVER_TOPIC event is sent and all the http requests suspended before are resumed (see line 3791 to 3878). I think this causes a flood of events being posted to socket thread and makes socket thread frozen.

I am not really sure the root cause of this behavior. It seems to me this is caused by stopping the timer thread when OS is in sleep. In normal case, the suspended requests should be resumed in a short time.

So, I created a test build at here.
@lgfa29, could you use this build to see if you can still reproduce this problem?

Thanks!

p.s. The test build is created by this try push.

Comment 83

[lgfa29]

(In reply to Kershaw Chang [:kershaw] from comment #82)

Created attachment 9199125 [details]
bug1415923.log

Thanks a lot for the detailed steps and report provided by llgfa29.
I've tried to reproduce this as the steps in comment #72 and I found one possible reason of this bug.
From the attached log, it looks like when NS_WIDGET_SLEEP_OBSERVER_TOPIC event is observed (at line 2729), http requests are still created but are suspended by web extension code here. After a while, when the system is awake, NS_WIDGET_WAKE_OBSERVER_TOPIC event is sent and all the http requests suspended before are resumed (see line 3791 to 3878). I think this causes a flood of events being posted to socket thread and makes socket thread frozen.

I am not really sure the root cause of this behavior. It seems to me this is caused by stopping the timer thread when OS is in sleep. In normal case, the suspended requests should be resumed in a short time.

So, I created a test build at here.
@lgfa29, could you use this build to see if you can still reproduce this problem?

Thanks!

p.s. The test build is created by this try push.

Thanks Kershaw, I have this build running and also 84.0.2 as a control. Initial results look promising:

• Custom build: https://share.firefox.dev/2KMwpeQ
• 84.0.2: https://share.firefox.dev/3omJ99M

I had only my test page running for this test, but I will leave both open overnight with some common pages I usually have open and see if what happens when I get back in the morning.

Comment 84

[lgfa29]

Overnight results are good as well :)

• Custom build: https://share.firefox.dev/2M52kb6
• 84.0.2: https://share.firefox.dev/3ojQDuf

I had the same tabs open in both, so presumably the types and amount of requests were similar. From an user perspective I didn't notice any sluggishness in the custom build, while 84.0.2 froze for a few seconds and was extremely slow to respond for a few minutes.

I am curious to see how it goes for others in this thread.

I will be using the custom build as my main browser for the week and see if I notice any issues.

Thanks again Kershaw!

Comment 85

[Kershaw Chang [:kershaw]]

Thanks for testing this!

So, my theory of this bug is that the timer thread doesn't process timers when OS is in sleep, but other parts of Firefox are working as normal. When OS is awake, a flood of timer events are posted to socket thread and make it unresponsive. This unresponsiveness is more noticeable when addons are installed as described in comment #82. In the case that there is no addon installed, this also affects socket thread, since there are some periodically jobs are triggered by timer thread.

Not sure if this only happens on macOS, it seems we don't have the similar bug on other platforms. Anyway, I'll create a patch to make timer thread ignores sleep/wake notifications on macOS first and see what other xpcom experts think about this.

Comment 86

[Kershaw Chang [:kershaw]]

@padenot, I've heard that you've been working on timer code, so I'd like to ask your thought on this. It seems the root cause of this bug is that a flood of events created by timer thread when OS is awake, so my plan is to ignore sleep and wake notifications on macOS. I believe the initial reason introduced this code is probably no longer valid now and it's probably safe to let timer thread still be able to process timers when OS is in sleep.
What do you think?

Comment 87

[Glyn Normington]

Just confirming the custom build seems to fix the problem for me on an M1 machine running macOS 11.1 (Big Sur). Nice work so far...

Comment 88

[Paul Adenot (:padenot)]

(In reply to Kershaw Chang [:kershaw] from comment #86)

@padenot, I've heard that you've been working on timer code, so I'd like to ask your thought on this. It seems the root cause of this bug is that a flood of events created by timer thread when OS is awake, so my plan is to ignore sleep and wake notifications on macOS. I believe the initial reason introduced this code is probably no longer valid now and it's probably safe to let timer thread still be able to process timers when OS is in sleep.
What do you think?

Our timestamp on macOS code doesn't know there was any sleep, it simply doesn't tick when the machine is sleeping.

it's using mach_absolute_time: https://developer.apple.com/documentation/kernel/1462446-mach_absolute_time

I think that you're right, and that what this code is doing doesn't apply (and is now problematic).

Comment 89

[Kershaw Chang [:kershaw]]

Attachment: Bug 1415923 - Ignore sleep and wake notifications on OSX

Comment 90

[Markus Stange [:mstange]]

I believe this patch will only fix the case where the process is unresponsive because of the built-up work. The initial Activity Monitor samples show ~0% CPU on the main thread, so I think those were a different issue. We can work on the 0% CPU issue in bug 1682713 (if it happens after sleep) and in bug 1422855 (if it happens after user switch).

Comment 91

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/81bccec978de
Ignore sleep and wake notifications on OSX r=xpcom-reviewers,KrisWright

Comment 92

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/81bccec978de

Comment 93

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Could everyone who faced this problem before maybe run a check with one of the most recent Firefox Nightly builds? It would be good to know if things have been improved for you. Thanks.

Comment 94

[lgfa29]

I've been running Kershaw's custom build for the past 2 weeks without any problems. I am now running the latest Nightly build (87.0a1 (2021-02-08)) and will report if I find any issue.

Comment 95

[Glyn Normington]

I upgraded my Nightly build from 86.x (which seemed to have solved my problem) to 87.0a1 and the unresponsiveness recurred.

Comment 96

[olemathias.aa.heggem]

Testing with 87.0a1 (2021-02-09) and have seen unresponsiveness again. Mac Mini M1 macOS 11.2
Will try to reproduce the issue.

Comment 97

[Q]

Likewise, I'm testing with 87.0a1 (2021-02-09) (64-bit), and I find it unresponsive on occasion. Macbook Pro M1 macOS 11.2 with external Pro Display XDR.

Comment 98

[Kershaw Chang [:kershaw]]

Reopen this bug since the problem is not completely fixed.
I'll keep working on this bug.

Comment 99

[Glyn Normington]

(In reply to Glyn Normington from comment #95)

I upgraded my Nightly build from 86.x (which seemed to have solved my problem) to 87.0a1 and the unresponsiveness recurred.

I am running macOS 11.2 on a Macbook Air M1.

Comment 100

[travismcendree]

This happens to me on my Mac Mini M1. It is very annoying, and I hope its fixed soon. I love Firefox but the smoothness of the monopolistic blink browsers is slowly getting to me.

Comment 103

[Glyn Normington]

I haven't hit the unresponsiveness again on 87.0a1 after 5 days of use. That's certainly better than stable Firefox.

Comment 104

[Mathew Hodson]

(In reply to Kershaw Chang [:kershaw] from comment #98)

Reopen this bug since the problem is not completely fixed.
I'll keep working on this bug.

It would probably be easier to track if there was a new bug for follow up work. The new bug can depend on this one.

Comment 105

[[e-mail]]

(In reply to Mathew Hodson from comment #104)

(In reply to Kershaw Chang [:kershaw] from comment #98)

Reopen this bug since the problem is not completely fixed.
I'll keep working on this bug.

It would probably be easier to track if there was a new bug for follow up work. The new bug can depend on this one.

@Matt Please don't create a new ticket. I can see your point but all the other bugs have been marked as duplicated of this one, this is the main channel through which people are keeping an eye on this bug and probably most people who are following this one will be lost if a new one is created. (and it's not just those of us commenting - lots of lurkers following this one no doubt)

Really appreciate it's finally getting the attention it deserves - who knows how many Mac users have tried Firefox only to conclude that it's a dud because of this bug. (without ever joining in on reporting it)

Comment 107

[Andy Fink]

Hallo, I didn't even pay attention to the thread because it was so old, and I thought it couldn't be the same problem. I suspect the error occurs primarily with Apple MacBook Pro and Mac Mini when an external monitor is connected. The error cannot be replicated (for me) if the MacBook is woken up without an external monitor (in my case an LG monitor connected via USB Type C). Maybe this helps.

Comment 108

[[e-mail]]

(In reply to Andy Fink from comment #107)

Hallo, I didn't even pay attention to the thread because it was so old, and I thought it couldn't be the same problem. I suspect the error occurs primarily with Apple MacBook Pro and Mac Mini when an external monitor is connected. The error cannot be replicated (for me) if the MacBook is woken up without an external monitor (in my case an LG monitor connected via USB Type C). Maybe this helps.

That's useful info, but for me and I dare say probably most other reporters it's happening irrespective of external monitors connected or not.

Comment 109

[Glyn Normington]

This bug used to reproduce for me without an external monitor connected. I haven't tried it with an external monitor.

Comment 110

[Kershaw Chang [:kershaw]]

I can reproduce the unresponsiveness with the steps in #comment 51. Although the steps in #comment 51 is about switching user account, not sleep/wake, the samples I got from Activity Monitor are quite similar. So, I think the reason that Firefox becomes frozen after system wakes up or after account switch might be the same.
I also tried to crash firefox deliberately when it frrezes and got some crash report below.

• 05d14308-ce73-4610-879d-f69c10210218
• 0ff672bd-8764-4745-9458-c58770210218

Unfortunately, I can't figure out the root cause the crash reports and samples.
Haik, could you take a look when you have time? Do you have any suggestion?
Thanks.

Comment 111

[Kershaw Chang [:kershaw]]

Attachment: Firefox_Sampling_process_9142.txt

Comment 112

[Kershaw Chang [:kershaw]]

Attachment: Firefox_Sampling_process_28566.txt

Comment 113

[Markus Stange [:mstange]]

Okay, so this remaining issue has very different characteristics to the one that was fixed in this bug:

• There's no 100% CPU use during the hang.
• Firefox never recovers from the hang.
• Resizing the window and changing focus window probably forces a repaint. (Is that right?)

Comment 114

[Kershaw Chang [:kershaw]]

(In reply to Markus Stange [:mstange] from comment #113)

Okay, so this remaining issue has very different characteristics to the one that was fixed in this bug:

• There's no 100% CPU use during the hang.

The CPU usage I've seen is quite low (< 10%).

• Firefox never recovers from the hang.

In my test, Firefox did recover after a couple of minutes.

• Resizing the window and changing focus window probably forces a repaint. (Is that right?)

Not sure. I can still switch tabs and click links in the page, but it's really slow.

Comment 115

[Markus Stange [:mstange]]

I see! Can you get a profile of the slowness, and another one once Firefox has recovered? Also, is there any slowness in the parent process? For example, do tab hover effects appear instantly? Also, in the tooltip of the selected tab, does it say [A]?

Comment 116

[Kershaw Chang [:kershaw]]

(In reply to Markus Stange [:mstange] from comment #115)

I see! Can you get a profile of the slowness, and another one once Firefox has recovered? Also, is there any slowness in the parent process? For example, do tab hover effects appear instantly? Also, in the tooltip of the selected tab, does it say [A]?

• Profile captured during the slowness.
  The profiler was started after the unresponsiveness happened. Not sure if this one has any useful information.

• Profiler started before the slowness and stopped after firefox is recovered
  Here is the details of this profile.

  1. Start the profiler with two tabs opened (wiki.com and old.reddit.com). The foreground tab is old.reddit.com.
  2. Do nothing for 10s.
  3. Switch to another user account.
  4. Do nothing for 60s.
  5. Switch the user account back.
  6. The unresponsiveness happens for about 70s. During this period, I only tried to click the tab menu for switching the foreground tab to wiki one. I think the slowness is happened in parent process, since there is no tooltip shown and no tab hover affects.
  7. When firefox is recovered (the foreground tab is wiki.com), I stopped the profiler after 10s.

• Profile captured with the same steps above, but without slowness

Comment 117

[Markus Stange [:mstange]]

With these steps to reproduce, I can finally reproduce it on my Intel Macbook Pro. Thanks!!

I'm pretty sure that this is a problem with vsync notifications.

Comment 118

[Stephen A Pohl [:spohl]]

I didn't have a chance to look at the logs, but the reference to vsync made me think of bug 1602842 and the hangs reported there. Thought I'd mention it in case it ends up being relevant here.

Comment 119

[Kershaw Chang [:kershaw]]

(In reply to Markus Stange [:mstange] from comment #117)

With these steps to reproduce, I can finally reproduce it on my Intel Macbook Pro. Thanks!!

I'm pretty sure that this is a problem with vsync notifications.

Thanks for taking a look.
I'd like to unassign myself and switch this bug to the proper component.

Comment 120

[u680235]

I have bought a M1 Mac Mini a month ago and from day one had issues with Firefox. Every time the Mini turns off the display as an Energy Saver I get back to an unresponsive Firefox.

I have bookmarked this page, followed the development and thought the issue might get resolved very soon. From what I can see it is just going in the wrong direction. That’s when I decided to make a Bugzilla account.

There should be a new ticket with bigger priority and severity levels. This being slapped on some old bug is a problem and it drags the resolve in the wrong direction. Trying to reproduce this issue on an Intel Mac is also an issue. The bug is clearly connected to the M1 processor. When I open Firefox with Rosetta 2 translation it is working normally and no trace of the bug can be seen. Only the Zilla eating all my RAM.

I have been a long time Firefox user, I have donated before and even signed up for the VPN service Mozilla is offering. To see how this issue is being handled is quite disappointing. I have switched many of my friends and family to using the privacy friendly Firefox, but I am the one that has been lately thinking of switching to another browser. Imagine all the non-tech savvy people who just bought the newest Mac hardware and realise that this browser at this point is a dud, as someone put it in the comments above.

Mozilla had the new M1 processors in advance and could port Firefox and iron out the issues. Seeing this being dragged 4 months after the release of Big Sur and still no clue of what is even causing the bug is as I’ve said very disappointing and at this point I am questioning whether I should trust the company with all my data with the Firefox Sync or VPN service when they cannot handle this kind of bug.

Comment 121

[petruconduraru]

I feel exact the same way, and I think many users will just give up, or they might have done that already.

Comment 122

[u680235]

And now we're even being cencored and have our comments hidden by slapping the "advocacy" tag. How is my comment even advocacy? I cannot see any other comments being hidden in this bug report, except the ones questioning the approach. Really Mozilla?!

Comment 123

[Mark Banner (:standard8)]

(In reply to skopjanecot from comment #122)

And now we're even being cencored and have our comments hidden by slapping the "advocacy" tag. How is my comment even advocacy? I cannot see any other comments being hidden in this bug report, except the ones questioning the approach. Really Mozilla?!

I'm sorry you feel this way. I would like to remind everyone that all comments in Bugzilla are subject to the Etiquette and Contributor guidelines as per the link at the bottom of the comment box.

I felt that your comment did not add anything new nor useful. In particular you were advocating with your comments about being a long time user, and switching your family and friends. It was also not constructive, especially of accusing developers of going in the wrong direction without definition - this is obviously a complex bug, and wrong directions are entirely possible and valid. Comments like that are demoralising and not welcome here.

Whilst there are a lot of "me too" style comments on this bug - this problem is a particularly complex one, and so the data there has likely been more useful than it might have been on other bugs where we wouldn't tolerate it in the same way.

Comment 124

[Andy Fink]

It's unbelievable that comments that don't suit someone are censored! I've been a Firefox user since day one! Slowly annoys me that the error has been ignored for months. Can understand that users switch to Chrome or Opera :-(

Comment 125

[Zak]

Whilst we're waiting for this to be fixed, there's a quick workaround for when the browser hangs (if you can't wait the minute or two for it to start working again). I can't take credit for it, as I'm sure someone in this thread mentioned it before:

If you have fast user switching turned on, when the browser hangs, simply go to the login screen of your Mac (don't log out) and then log in again. I find that the browser works again after this.

Obviously not the best solution but at least it's something whilst we await a fix.

Comment 126

[u680235]

(In reply to Mark Banner (:standard8) from comment #123)

I felt that your comment did not add anything new nor useful. In particular you were advocating with your comments about being a long time user, and switching your family and friends. It was also not constructive, especially of accusing developers of going in the wrong direction without definition - this is obviously a complex bug, and wrong directions are entirely possible and valid. Comments like that are demoralising and not welcome here.

My comment did add something new. Following this bug and seeing that people that work on it try to reproduce it on an Intel Mac and try to connect it to switching users when probably less than 1% of Firefox users switch accounts ever. I point out that it is clear that a sleep/wake is the issue. Also, for the first time ever in this bug report I mention that the issue does not come up when the browser is opened through Rosetta 2, which again implies that it is M1 only related issue.

Instead of the developers appreciating this new info I provided and taking my time to open an account and report, I get censored and slapped with an "advocacy" tag because I point out the incapability to solve a lingering issue, which as I also say in the original comment is probably not even related to the original bug that was filed.

We expect to have more resources devoted to this issue. Mozilla is not run by volunteers who build it in their free time. If the employed developers get so demoralised by such civilised comments like mine and censor them immediately, then that might be a serious problem.

Comment 127

[Zak]

Hi @ skopjanecot,

This isn't just an M1 issue. I've been experiencing this issue for a couple of years now, I think. I have an 11" MBA (2011 model) and an MBP 2020 (Intel model).

Comment 129

[Markus Stange [:mstange]]

I think I have found the problem, and I am working on a fix in bug 1422855 and bug 1682713.

Since this bug already has a patch that landed, I am going to close this bug again so that regression and uplift tracking is easier. I'm also going to tweak the bug title to describe the aspect of the bug that was fixed by the patch that landed in this bug: This bug fixed the 100% CPU case but not the low-CPU case.

Please follow bug 1682713 for the rest of the issue.

Comment 130

[Ibrahim Cihan DİKMEN]

Firefox application in the applications folder;
Right click> Get info> select "open using rosetta"

Firefox no longer freezes.

Mac mini m1
Mac OS 11.2.1 (20D74)
Firefox 85.0.2 (64 bit)

Comment 131

[Markus Stange [:mstange]]

For everyone who sees the freeze after sleep on an M1 machine, please download the latest Firefox Nightly and check if it fixes this bug, and then report your findings in bug 1682713.

Comment 132

[Ibrahim Cihan DİKMEN]

(In reply to Markus Stange [:mstange] from comment #131)

For everyone who sees the freeze after sleep on an M1 machine, please download the latest Firefox Nightly and check if it fixes this bug, and then report your findings in bug 1682713.

Firefox Nightly looks good. This is not yet frozen.
-> 88.0a1 (2021-02-24) (64 bit)
-> Mac mini m1
-> Mac OS 11.2.1 (20D74)

Comment 135

[Fabrizio Salvatore]

Sorry to resurrect ths thread. I've just found this Bug report by googling for a problem I'm seeing at the moment with Firefox, which seems identical to what I see here. I have a MacBook Pro (13-inch, M1, 2020), running Big Sur 11.2.2. I am connected to an external monitor via USB-C cable (which was a BIG issue since I moved to Big Sur and I just managed to resolve it over the weekend !) and I noticed since I use the external monitor that every time the laptop goes in 'Screen Save' mode Firefox is frozen. I can switch between the different tabs that are already opened, but there is nothing I can do on thise tabs. If I click on the '+' to open a new tab, the tab gets opened but I cannot write anything on the URL bar. I can see the Firefox commands on the command bar, and if I click on 'Quit' I can quit Firefox without any problem, and when I reopen it, I have all its functionalities back.
I'm running Firefox 86.0 (64-bit). If you have any suggestions, please let me know. Also, if this comment does not belong here, please accept my apologies and let me know if there is anywhere else I can post it.

Thanks !

Fab

Comment 136

[Jens Stutte [:jstutte]]

(In reply to Fabrizio Salvatore from comment #135)

I'm running Firefox 86.0 (64-bit). If you have any suggestions, please let me know. Also, if this comment does not belong here, please accept my apologies and let me know if there is anywhere else I can post it.

Dear Fabrizio, please see comment 131 how to proceed:

(In reply to Markus Stange [:mstange] from comment #131)

For everyone who sees the freeze after sleep on an M1 machine, please download the latest Firefox Nightly and check if it fixes this bug, and then report your findings in bug 1682713.

This means also, until FF 88 stable is released, you should use Nightly 88 to see some improvements.
Thank you for your support!

Comment 137

[Fabrizio Salvatore]

(In reply to Jens Stutte [:jstutte] from comment #136)

(In reply to Fabrizio Salvatore from comment #135)

I'm running Firefox 86.0 (64-bit). If you have any suggestions, please let me know. Also, if this comment does not belong here, please accept my apologies and let me know if there is anywhere else I can post it.

Dear Fabrizio, please see comment 131 how to proceed:

(In reply to Markus Stange [:mstange] from comment #131)

For everyone who sees the freeze after sleep on an M1 machine, please download the latest Firefox Nightly and check if it fixes this bug, and then report your findings in bug 1682713.

This means also, until FF 88 stable is released, you should use Nightly 88 to see some improvements.
Thank you for your support!

Thanks a lot! I have downloaded the Disk Image firefox-88.0a1.en-GB.mac.dmg and will install it and let you know.

Comment 138

[dankan]

Running Firefox 86 on Catalina 10.15.7 on 2018 mac mini with 3 GHz 6-Core Intel Core i5 processor and Intel graphics card, no VPN. We have the freeze problem. Yes, switching back to other user and back again fixes the problem (no log out needed). Not planning to update machine to M1 any time soon - only recently acquired this 2018 Apple refurbished mac mini (had no M1 choice at the time). I hope Intel machines won't be left in the dust, but fear they will be.

Will wait for FF 88 stable, I am not tech-y enough to deal with anything else. Hope that will contain a fix.

Comment 139

[Markus Stange [:mstange]]

Firefox 87 (currently on Beta) already includes the fix for Intel machines. The next 87 Beta will also include the fix for M1 machines.

Comment 140

[Zak]

This is great news that it's been fixed for Intel machines. I'm on version 86, and will update once 87 is out of Beta. Fingers crossed it's resolved once and for all! Thanks a lot.

Comment 141

[dankan]

Ditto!

Comment 142

[Catalin Sasca, Desktop QA [:csasca]]

I was able to reproduce the issue on macOS 11.2.3 with Firefox 86.0 by following the steps in Comment 100 from Bug 1682713 with Scenario A, but not with B on an Intel macbook pro system.

The issue was verified as fixed on Firefox 87.0 and 88.0a1 (2021-03-17) with both scenarios. Tests were ran on macOS 11.2.3.

Comment 143

[joe]

I am on High Sierra 10.13.6 and FF 95.0.2 and I have had this issue for the last 6 months. If I close my computer while FF is open, when I;m back on it, the app is unresponsive. I ahve to force quit the app. Then when I try to reopen, it says there is a copy already running. I have to force quit again. But alas, the only way to get FF working again is a complete restart of my macbook pro 2018. How do I fix this? I prefer FF over chrome but because of this issue I find myself using chrome more. Thanks

Comment 144

[Zak]

(In reply to joe from comment #143)

I am on High Sierra 10.13.6 and FF 95.0.2 and I have had this issue for the last 6 months. If I close my computer while FF is open, when I;m back on it, the app is unresponsive. I ahve to force quit the app. Then when I try to reopen, it says there is a copy already running. I have to force quit again. But alas, the only way to get FF working again is a complete restart of my macbook pro 2018. How do I fix this? I prefer FF over chrome but because of this issue I find myself using chrome more. Thanks

Hello. I'm sorry to say I can't help but I feel like this issue was resolved a while back, but maybe not for High Sierra? I was on Catalina for a while and had this issue, but somewhere along the line one of the updates stopped this issue happening for me. I can't remember though, if it was before or after I upgraded to Big Sur.