Same issue here since Firefox 57, currently running mac OS 10.14.2

Firefox 65.01 and MacOS 10.14.2 (18C54) - Still happening. Annoying that this hasn't been fixed in so long.

Same problem here. This seems to depend on the time duration I am using the other user. E.g. if I have Firefox open as user A, switch to user B for only 10 seconds and back to a, usually nothing happens. If I do this for 2-5 minutes, I can revive the first firefox of user A by right-clicking on the icon in the task bar several times. For longer periods, Firefox A is hopelessly lost, but maybe could be revived if I just waited long enough. It seems to me that there is some kind of queue, which is filled up regularily, but can only be processed when the User of this Firefox is in the foreground.

And, additional info, this can be prevented if I minimize firefox before switching to user B. Firefox 65.01 on Mojave.

I can confirm with FF 65.0.1 (64-bit) \ macOS 10.14.4 Beta (18E194d).

I can also confirm that minimizing Firefox before locking my screen appears to work around the hang.

I can confirm this bug as well with FF 65.01/macOS 10.14.3
I use also the old FF ESR 52.9.0 because I need Google Hangout Plugin. Both FFs are affected. Interesting thing is that the old FF ESR 52.9.0 is the same version which I have used before the upgrade from macOS El Capitan and on the previous OS switching account didn't affect FF at all.

I can also confirm that the bug occurence is somehow dependent from the time how long I use the another OS account. The longer time I spend as user 2 the bigger change that FF on user 1 will be frozen after switching over account and back to user 1.

I cannot bring back FF to work by minimalizing windows, opening/closing new windows, creating new cards - the only way is to stop/kill FF and run it again.

Since this appears to be a regression, it would be great to get a regression range using mozregression[1] from someone who can reproduce reliably. To install and run mozregression, simply type the following three commands in a Terminal window:

sudo easy_install pip
sudo pip2 install -U mozregression --ignore-installed
mozregression

A number of Firefox versions will open in succession to narrow down when this started occurring. Simply type "good" or "bad" in Terminal based on whether or not a build reproduces the bug.

[1] https://mozilla.github.io/mozregression/

I tested it with mozregression already, see the results in my comment above.

(In reply to Andrey Fedoseev from comment #41)

I tested it with mozregression already, see the results in my comment above.

I didn't mean to dismiss those results. I was hoping to get a more precise regression range than ~2014-06-01 - 2016-07-12 if someone can run builds in that range.

I just tried mozregession, too. Unfortunately with the same result, anything between 2014-06-01 and 2016-07-12 takes 100% CPU and does not open any window but takes 99% CPU instead. Since I used Firefox during that time on my very same Macbook, I think that these versions might have a problem with Mojave. Unfortunately I don't have any older Boot images to test with Sierra or so. Are you interested in stack dumps of theres non-working versions or similar? Maybe it's easy to fix?

Hi, the versions in question hang here:
(lldb) thread b all

• thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  • #0: 0x00007fff72c5baee in __mprotect + 10
    #1: 0x00007fff72cd1abe in malloc_zone_register_while_locked + 372
    #2: 0x00007fff72cdbfec in malloc_zone_register + 58
    #3: 0x0000000100010668 in register_zone + 360
    #4: 0x0000000105a8bcc8 in ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 518
    #5: 0x0000000105a8bec6 in ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 40
    #6: 0x0000000105a870da in ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 358
    #7: 0x0000000105a8706d in ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 249
    #8: 0x0000000105a86254 in ImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 134
    #9: 0x0000000105a862e8 in ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) + 74
    #10: 0x0000000105a75774 in dyld::initializeMainExecutable() + 199
    #11: 0x0000000105a7a78f in dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) + 6237
    #12: 0x0000000105a744f6 in dyldbootstrap::start(macho_header const*, int, char const**, long, macho_header const*, unsigned long*) + 1154
    #13: 0x0000000105a74036 in _dyld_start + 54

Does that ring any bell?

Another thing, I could reproduce the same bug with Thunderbird, so it's probably with some shared code. Maybe I get more luck trying to run mozregression for thunderbird?

same with --app=thunderbird :-(

I found an old bootable disk with MacOS Mavericks on it and here I can start mozregression versions between 2014-06-01 to 2016-07-12. But unfortunately there the problem does not exist here at all, even the newest Mozilla works fine.
I had another image with Sierra, and here it is the same as with Mojave.
I tried on another machine, which has El Capitan on it, and it seems there all versions work fine, too, although I have only VNC access there.
So it looks like the problem somehow came with Sierra support. 2016-07-12 the development versions were already out, so
probably someone fixed something for Sierra then, so that firefox worked at all. Unfortunately this means, that
we cannot find the bug with mozregression, only if one would backport the fix to older versions and recompile. Don't know if that's easily possible.

I have noticed this happening reliably, more than half of the time, on macOS Mojave 10.14.4 with Firefox Release 66.0.3. Can I help to move this bug forward? Are there any logs that would be helpful?

(In reply to subscribe from comment #37)

And, additional info, this can be prevented if I minimize firefox before switching to user B. Firefox 65.01 on Mojave.

This does not prevent the bug, but it definitely does reduce the occurrence of it.

-- Adding my additional observations since I still deal with this on a regular basis, though less so now that I know minimizing firefox reduces the occurrence of this issue greatly

• Length of time spent on the opposite user directly correlates with the likelihood of the bug occurring.
  • User A is the active user
  • User B is the inactive user - this user's firefox will bug out eventually for the longer period of time User A is active.
• Minimizing firefox on the inactive user results in requiring the active user to be logged in longer prior to the bug occurring.
  • User A is active user
  • User B is the inactive user with firefox minimized - User A must be logged in significantly longer prior to bug occurrence.

Bugbug thinks this bug is a regression, but please revert this change in case of error.

The situation seems to have improved under Mac OS X Catalina (10.15). Are you still able to reproduce the bug with the latest Mac OS X version ?

(In reply to Matthieu Beaumel from comment #51)

The situation seems to have improved under Mac OS X Catalina (10.15). Are you still able to reproduce the bug with the latest Mac OS X version ?

I'm still on 10.14, but also haven't had it in a while now.

I'm on MacOS 10.14.6, Firefox 70.0.1 and don't appear to be having the issue anymore.

It seems to be still present but very rare now. I've only seen it happen once in the last month.

reproducing 100%
Firefox 71.0 stable channel, MacOS 10.13.6.
using firefox in separate work & personal accounts - very annoying bug.

Extremely reliable when switching between users with Firefox 71 and OS X 10.14.6. Only one of the users is running Firefox.

Still an issue on 10.15.3 Catalina and FF 73.

Can run some tests to help.

Would it be useful for someone to collect more info from one of these hung processes using activity monitor's "sample process" or a similar tool? What other steps could we try to get this bug into a more actionable state?

It would be interesting to see if the Firefox Profiler can shed any light on what's going on here:

https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler#Profiling_a_hung_process

On OSX, you can also get a stack trace with the Activity Monitor. Click on the process of interest, then click on the gear and choose "Sample Process".

New to this thread, been having this problem since version 66. I have two local users, only one of which uses Firefox. In terms of re-producing the problem, it seems more prone to happen when I am switched to the non-Firefox user profile for a significant period of times (several hours). When I switch back to my macOS user with Firefox, Firefox will be extremely sluggish to all input - even checking for updates in the "About" window. Like everyone else, only quitting Firefox and re-launching brings it back to life. Neither safe mode nor 'cleaning' Firefox changes the reported behavior.

I haven't create a stack trace, but will do so next time it happens. For the sake of provided information, I've attached the contents of my "about:support" page.

I was able to reproduce this, but haven't uncovered anything so far. I didn't see any suspicious stacks in Activity Monitor and the parent process CPU utilization was low. One content process was running with spiking CPU load, but I didn't see anything in Activity Monitor. The build was a Release build which wasn't debuggable (due to Notarization/hardened runtime). I'll try to reproduce this with a developer Nightly build.

I have found that the hang can be recovered from by using the new window keyboard shortcut. A new window will then open and the original window(s) will become responsive again.

I attached an Activity Monitor sample from while in the hung state and after the "fix". Both samples are in the same file.

Thank you for Activity Monitor logs. I'm going through those, but don't see anything concrete yet.

One observation: this might be a "red herring", but in the samples provided and in my own logs, in the hang case, there is always a single CVDisplayLink thread where all the samples are from the following stack. For the non-hang case, there is a CVDisplayLink thread with at least one sample doing something else.

    1224 Thread_1102533: CVDisplayLink
    + 1224 thread_start  (in libsystem_pthread.dylib) + 13  [0x7fffde11f08d]
    +   1224 _pthread_start  (in libsystem_pthread.dylib) + 286  [0x7fffde11f887]
    +     1224 _pthread_body  (in libsystem_pthread.dylib) + 180  [0x7fffde11f93b]
    +       1224 CVDisplayLink::runIOThread()  (in CoreVideo) + 520  [0x7fffc9dbf762]
    +         1224 CVDisplayLink::waitUntil(unsigned long long)  (in CoreVideo) + 233  [0x7fffc9dbf977]
    +           1224 _pthread_cond_wait  (in libsystem_pthread.dylib) + 769  [0x7fffde120833]
    +             1224 __psynch_cvwait  (in libsystem_kernel.dylib) + 10  [0x7fffde034bf2]

Additionally, there are some docs online for Fast User Switching. From https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPMultipleUsers/Concepts/FastUserSwitching.html

Processes in a switched-out login session continue running as before. They can continue processing data, communicating with the system, and drawing to the screen buffer as before. However, because they are switched out, they do not receive input from the keyboard and mouse. Similarly, if they were to check, the monitor would appear to be in sleep mode. As a result, it may benefit some applications to adjust their behavior while in a switched-out state to avoid wasting system resources.

Here's a profile I collected on Nightly. https://perfht.ml/2Xp896m

I started Nightly with a new profile. I had 1 window open with 4 JS-heavy tabs. I switched to another user and then switched back (after less than one minute). The browser was not responding to track pad scrolling. I hit Cmd-shift-1 to start the profiler which resulted in no user-visible feedback. After some number of seconds I hit Cmd-shift-2 to stop the profiler. Eventually the profiler window appeared at the browser was responsive again.

One possible clue here is the content process compositor thread recording a CONTENT_FRAME_TIME for ~15 seconds.

See comment 68 about the monitor appearing to be in sleep mode when a login session is switched out.

Edit: jrmuizel looked at the profile and commented that a long CONTENT_FRAME_TIME indicates we're taking a long time waiting for a paint to show up at the GPU.

More debugging needed.

I don't think I can take this any further without more graphics compositing expertise.

What I suspect is happening is that when we enter user switching, access to the GPU is shutdown in some way leaving our compositing code waiting for an update. In profile https://perfht.ml/2Xp896m the first 9 seconds are during the hung period and the graphics hang coincides with the long CONTENT_FRAME_TIME marker. Keyboard events are handled during the graphics hang allowing me to start the profiler, create new windows, etc.

The online documentation for CVDisplayLinkStop states that in macOS 10.4 and later, the display link thread is automatically stopped if the user employs Fast User Switching. The display link is restarted when switching back to the original user.

I'm attaching a patch that registers for the faster user switching notifications in case that is useful for testing the fix. I tried calling GPUProcessManager::SimulateDeviceReset() on these notifications (both switch out and switch back), but could still reproduce the problem.

Re-triage needed.

I don't think this has been mentioned before, but it might be useful. I've been seeing this quite a bit recently.

On one of my accounts I have both Firefox (nightly) and Thunderbird (68esr). When I switch back and hit this, I've only ever seen it be one of them that has frozen, and I'm pretty sure it is always the one that was in the foreground. I'm not quite sure if having another application in the foreground when switching away prevents it or not, but will try and monitor.

I can confirm that bug has been present since I updated to Mojave (now 10.14.6) from Sierra, both for Firefox (stable) and Thunderbird (still running 60.9.1). It only applies when the application is in the foreground when switching to a different user, and can be circumvented by putting a non-affected program in the foreground before switching users.

Markus, would you be able to help here, or direct to someone who could? See comment 70.

Just chiming in to say that this bug happens to me on macOS 10.14.6 and Firefox 84.0, which severely impacts my use-case.

I've got it 100% reproducible now with Firefox 84 on Big Sur mac mini (ARM):

1. Open Firefox
2. Hibernate (Apple -> Sleep)
3. Wake mac up
4. Try to interact with Firefox (e.g. click different tab in header)
5. No visual feedback
6. Tab switch to different app
7. Tab switch back to FF
8. Suddenly the other tab is active and rendered
9. Go back to step 4 and loop

See comment 70

I'm commenting as the submitter of Bug 1684322. I can reliably reproduce the above comment 81 on my setup (Big Sur 11.1, Macbook Pro 13" M1 2020, Firefox 84.0.1, Pro Display XDR).

Some notes:

1. I can ONLY reproduce it when connected to my Pro Display XDR. I have tried several times to reproduce it with just my laptop screen and have been unable to do so.
2. I'm not sure of the mechanics of Apple's sleep, but the bug only reliably happens when the laptop has been asleep for awhile. If I put it to sleep (Apple -> Sleep) and then wake it up within a minute or two, everything works fine. But if it's been asleep for some amount of time, this bug behavior is reliably reproduced.
3. I do not have additional users on this laptop, so I'm not sure if this is a different manifestation of the same bug, or a different bug altogether.
4. Even though step #8 ("Suddenly the other tab is active and rendered") happens, the tab is non-responsive (no scrolling, text input, etc). Firefox must still be restarted.

Markus, can you try the steps to reproduce?

This is 100% reproducible with comment 81 instructions on mac mini Big Sur 11.1 (M1) using latest nightly 86.0a1 (2021-01-13) (64-bit). Fresh install, fresh profile.

I have same comment 81 issue in my Mac mini (M1, 2020).
This issue occurs when Rosetta is turned off.
Then I turn on Rosetta, this issue does not occur, and no problem.

I haven't been able to reproduce this yet, but I'll try some more on Monday.

I have been able to reproduce the unresponsiveness after sleep, which I will investigate in bug 1682713.
I have not yet been able to reproduce the unresponsiveness after user switching.

I have been able to reproduce this bug, and I have found a fix. I will make test builds soon.

bug wkae from sleep or bug when switching user?

Wake from sleep is bug 1682713, but might be fixed by the same fix.

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

Wake from sleep is bug 1682713, but might be fixed by the same fix.

Nice i hope a fix very soon ;) thanks

This fixes a problem where the callback just wouldn't be called for the duration
of about a minute after fast user switching. I'm hoping it'll also help with a
similar problem after screen lock and after sleep (bug 1682713).

The documentation for CVDisplayLinkStop says the following:

In macOS 10.4 and later, the display link thread is automatically stopped if
the user employs Fast User Switching. The display link is restarted when
switching back to the original user.

This probably works for display links that were created before fast user
switching. However, we sometimes create a new CVDisplayLink while our user is
"in the background", and this new display link happily keeps running while we're
in the background. Then, when switching back to the original user, that's when
the display link is stopped. And then it eventually starts again. I'm not sure
what causes it to re-start.
Creating a CVDisplayLink while the machine is fast user switched to a different
user is probably not a well-exercised codepath. Things might work more reliably
if we keep reusing the same CVDisplayLink instance and just stop and start it
as needed. But that's a more risky change that I don't want to uplift.
Also, starting to listen for vsync while a different user is the "current" user
is probably a mistake anyway. We should find out if there's a way to suspend
compositing and drawing in that state. However, it seems that the window doesn't
enter the occluded state during this time, because in that case we would
de-activate the content docshell and not run requestAnimationFrame callbacks.
But the profiler clearly shows rAF running during the switched-away time.

I'm seeing the following display reconfiguration callbacks during fast user
switching, 2077750265 being the display link's current display:

[1] DisplayReconfiguration for 2077750265: BeginConfiguration
[2] DisplayReconfiguration for 1104977158: BeginConfiguration
[3] DisplayReconfiguration for 2077750265: Remove Disabled
[4] DisplayReconfiguration for 1104977158: Moved SetMain SetMode Add Enabled

[5] DisplayReconfiguration for 1104977158: BeginConfiguration
[6] DisplayReconfiguration for 2077750265: BeginConfiguration
[7] DisplayReconfiguration for 1104977158: Remove Disabled DesktopShapeChanged
[8] DisplayReconfiguration for 2077750265: Moved SetMain SetMode Add Enabled DesktopShapeChanged

With this patch, we restart the display link at notification 4 and 8.

In the future, we should switch to per-monitor (or per-window) vsync rather than
global vsync, and clean this whole situation up a little.

Test build with fix: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/NgT_yiiXRy2UnlByOWzF8w/runs/0/artifacts/public/build/target.dmg

hi, we can't open it "it seems to be be damaged"...

Oh, shoot. That's probably because Apple Silicon has stricter requirements for signed apps. Let me ask around.

of course it's sure ;)

(In reply to tonerre26 from comment #99)

hi, we can't open it "it seems to be be damaged"...

Here's a workaround you can use. Apple Silicon devices are more strict in that they require all executables to be signed. In the developer target.dmg, some files are not signed and this appears to be tripping it up. You can self-sign the build to get around this (codesign -s -). These steps worked for me. After copying Firefox Nightly from target.dmg to the Desktop:

$ cd ~/Desktop
$ find Firefox\ Nightly.app/ -type f -exec codesign -f -s - {} \;
$ codesign -f -s - Firefox\ Nightly.app
$ open ~/Desktop

2. Right-click on Firefox Nightly and select Open (this will not work the first time - click OK)
3. Right-click on Firefox Nightly and select Open and then click Open again in the dialog.

(In reply to Haik Aftandilian [:haik] from comment #102)

(In reply to tonerre26 from comment #99)

hi, we can't open it "it seems to be be damaged"...

Here's a workaround you can use. Apple Silicon devices are more strict in that they require all executables to be signed. In the developer target.dmg, some files are not signed and this appears to be tripping it up. You can self-sign the build to get around this (codesign -s -). These steps worked for me. After copying Firefox Nightly from target.dmg to the Desktop:

$ cd ~/Desktop
$ find Firefox\ Nightly.app/ -type f -exec codesign -f -s - {} \;
$ codesign -f -s - Firefox\ Nightly.app
$ open ~/Desktop

2. Right-click on Firefox Nightly and select Open (this will not work the first time - click OK)
3. Right-click on Firefox Nightly and select Open and then click Open again in the dialog.

i'll wait about a fix in a future release...soon?

https://hg.mozilla.org/mozilla-central/rev/c27aac8c84b7

Markus, would it make sense to request uplift for the patch so it might be available in the 87 release? We are just about to start the new cycle, and it seems to be important enough.

Oh, please drop. The merge didn't happen yet so it already landed for 87.

Comment on attachment 9204410 [details]
Bug 1422855 - Tickle the CVDisplayLink after display reconfigurations, to help it get unstuck. r=jrmuizel,mattwoodrow

Beta/Release Uplift Approval Request

• User impact if declined: Needed if we want to uplift bug 1682713 to 86.
  On its own, this patch fixes a freeze on Intel machines after user switching. Combined with bug 1682713, it fixes a much more severe freeze on M1 machines after system sleep (and also after user switching).
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce: (QE testing should happen in bug 1682713)
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Very tightly-scoped fix.
• String changes made/needed: none

This issue was verified on bug 1682713. Please see comment 111 and comment 114 for more information. Based on those and comment 108, I'm going to close this as verified.

Comment on attachment 9204410 [details]
Bug 1422855 - Tickle the CVDisplayLink after display reconfigurations, to help it get unstuck. r=jrmuizel,mattwoodrow

Approved for 86.0.1, thanks.

https://hg.mozilla.org/releases/mozilla-release/rev/9919920c4844

Hello! The issue is no longer reproducible with Firefox 86.0.1 (20210310152336) by the following bug 1682713 steps. Tried several times on M1 mac mini 11.2.3 when switching users with fast switch and Firefox is working as expected.