1969346 - Firefox freezes and crashes if alt-tabbing to or from it while also having a full-screen game on Windows 11

Status: RESOLVED DUPLICATE of bug 1969253

(Core :: Graphics, defect)

Description

[andrei.brebenel]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:139.0) Gecko/20100101 Firefox/139.0

Steps to reproduce:

Have Firefox open with a YouTube video and an assortment of other tabs, and also have a game open, in fullscreen mode. Alt-tabbing to or from Firefox and the game creates the issue.

Actual results:

The browser freezes, and remains stuck, repeatedly clicking on it will eventually will eventually cause it to turn white and for the classic Windows message of "this program has stopped working" to appear, at which point I can either close the program, or if I click on wait for the program to respond, it eventually responds and seemingly reloads my tabs and everything in the browser as if I had opened it for the first time.

Expected results:

The browser shouldn't have frozen, I should have been able to alt-tab to and from it without any issues.

Comment 1

[andrei.brebenel]

Attachment: OK

I wasn't sure where to put this within the initial bug form, but I have an about:crashes report [here](https://crash-stats.mozilla.org/report/index/de10116e-02e6-489b-8f30-bfa000250529). I can reproduce it in a new profile also, and the about:support information for my main profile is here:
``

Comment 2

[andrei.brebenel]

Attachment: about:support

I wasn't sure where to put this within the initial bug form, but I have an about:crashes report [here](https://crash-stats.mozilla.org/report/index/de10116e-02e6-489b-8f30-bfa000250529). I can reproduce it in a new profile also, and the about:support information for my main profile is here:
``

Comment 3

[Ryan VanderMeulen [:RyanVM]]

Seeing multiple reports of this on Reddit. A regression range would be extremely helpful here.

Comment 4

[andrei.brebenel]

I’ve only started noticing it since this morning, which was also when I believe that my Firefox was updated to version 139. I initially assumed that it was connected to the Nvidia graphical corruption bug which was announced but the actual issue is different, and it has persisted even after updating to 139.0.1.

Comment 5

[Andrew McCreight [:mccr8]]

I downloaded the minidump for the browser process for the crash report in comment 1. Here's the top of the stack for the main thread:

 5  mozilla::gfx::GPUProcessHost::KillHard(bool) [GPUProcessHost.cpp : 218 + 0x4]
 6  mozilla::layers::CompositorManagerChild::ShouldContinueFromReplyTimeout() [CompositorManagerChild.cpp : 263 + 0x6]
 7  mozilla::ipc::MessageChannel::ShouldContinueFromTimeout() [MessageChannel.cpp : 1854 + 0x10]
 8  mozilla::ipc::MessageChannel::Send(mozilla::UniquePtr<IPC::Message,mozilla::DefaultDelete<IPC::Message> >, mozilla::UniquePtr<IPC::Message,mozilla::DefaultDelete<IPC::Message> >*) [MessageChannel.cpp : 1359]
 9  mozilla::ipc::IProtocol::ChannelSend(mozilla::UniquePtr<IPC::Message,mozilla::DefaultDelete<IPC::Message> >, mozilla::UniquePtr<IPC::Message,mozilla::DefaultDelete<IPC::Message> >*) [ProtocolUtils.cpp : 534 + 0xb97]
10  mozilla::layers::PCompositorBridgeChild::SendFlushRendering(mozilla::wr::RenderReasons const&) [PCompositorBridgeChild.cpp: : 1031 + 0xe]
11  mozilla::layers::CompositorBridgeChild::SendFlushRendering(mozilla::wr::RenderReasons const&) [CompositorBridgeChild.cpp : 355]
12  mozilla::layers::WebRenderLayerManager::FlushRendering(mozilla::wr::RenderReasons) [WebRenderLayerManager.cpp : 716 + 0x15]
13  nsViewManager::Refresh(nsView*, mozilla::gfx::IntRegionTyped<mozilla::LayoutDevicePixel> const&) [nsViewManager.cpp : 274 + 0x14]
14  nsViewManager::PaintWindow(nsIWidget*, mozilla::gfx::IntRegionTyped<mozilla::LayoutDevicePixel> const&) [nsViewManager.cpp : 555 + 0xd]
15  nsView::PaintWindow(nsIWidget*, mozilla::gfx::IntRegionTyped<mozilla::LayoutDevicePixel>) [nsView.cpp : 919 + 0x7]
16  nsWindow::OnPaint() [nsWindowGfx.cpp : 288 + 0x15]

In the crash report for the GPU process, it looks like the compositor thread is currently in CompositorBridgeParent::RecvFlushRendering, inside WebRenderAPI::WaitFlushed().

Comment 6

[Ryan VanderMeulen [:RyanVM]]

Bob, can you please help get this prioritized for investigation as a new regression in Fx139 causing Firefox to be basically unusable in some situations? Thanks!

Comment 7

[Andrew McCreight [:mccr8]]

This comment from the Reddit thread is possibly interesting: "It seems as if browsers open AFTER a game launches continue to work and limited only to browsers open prior to the game launching."

Comment 8

[andrei.brebenel]

(In reply to Andrew McCreight [:mccr8] from comment #7)

This comment from the Reddit thread is possibly interesting: "It seems as if browsers open AFTER a game launches continue to work and limited only to browsers open prior to the game launching."

I can confirm a similar thing - from my testing so far if I open Firefox after the game in question is already launched, it doesn't seem to crash.

This has made testing using the regression tool somewhat more difficult, but from my limited understanding of it and my testing of it, it does indeed seem that this issue only appears with version 139.

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

The bug is marked as tracked for firefox139 (release). However, the bug still isn't assigned.

:bhood, could you please find an assignee for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 10

[Ashley Hale [:ahale]]

I'll take a look at this.

Comment 11

[Ashley Hale [:ahale]]

Do you mind sharing what game triggers the hangs? A minimal set of web pages that trigger this would be nice but I understand if you do not wish to say.

I tested with youtube+twitch+webgl (https://get.webgl.org/ is a minimal test case that I like for that, but things like Google Maps might also work) in separate Firefox windows, and a UE5 game set to Fullscreen mode (not Borderless) to repro, but it didn't hang Firefox no matter what I did. Though it did freeze for a few seconds each time I alt-tabbed (due to Fullscreen mode, whereas Borderless had no such freeze) on the NVIDIA GPU.

I tested on both AMD (RX 9070 XT) and NVIDIA (RTX 3080 Ti) GPUs in separate machines running Windows 11, I also tested a forced context loss (which hung the UE5 game I was testing, but Firefox was fine) by right clicking the desktop, opening the NVIDIA Control Panel from there, going to the menu and enabling developer settings, then going to the performance metrics tab and toggling permissions (which causes all apps to lose access to the GPU and have to set that up again).

Comment 12

[Markus Stange [:mstange]]

I think it's very likely that the patch for bug 1969253 fixes this.

That patch is in the latest Nightly. Andrei, can you download a Firefox Nightly from https://nightly.mozilla.org/ and check if the problem appears in that build?

Comment 13

[andrei.brebenel]

(In reply to Ashley Hale [:ahale] from comment #11)

Do you mind sharing what game triggers the hangs? A minimal set of web pages that trigger this would be nice but I understand if you do not wish to say.

I tested with youtube+twitch+webgl (https://get.webgl.org/ is a minimal test case that I like for that, but things like Google Maps might also work) in separate Firefox windows, and a UE5 game set to Fullscreen mode (not Borderless) to repro, but it didn't hang Firefox no matter what I did. Though it did freeze for a few seconds each time I alt-tabbed (due to Fullscreen mode, whereas Borderless had no such freeze) on the NVIDIA GPU.

I tested on both AMD (RX 9070 XT) and NVIDIA (RTX 3080 Ti) GPUs in separate machines running Windows 11, I also tested a forced context loss (which hung the UE5 game I was testing, but Firefox was fine) by right clicking the desktop, opening the NVIDIA Control Panel from there, going to the menu and enabling developer settings, then going to the performance metrics tab and toggling permissions (which causes all apps to lose access to the GPU and have to set that up again).

For me, pretty much anything could cause the hang. Usually I need to be playing a video, the browser needs to be started before the game, and then I need to alt-tab back and forth from the game. So for the browser, YouTube, potentially a few other tabs open with just basic websites, and as for the games, I've had it happen in such games as Star Wars Battlefront 2, Counterstrike 2, Wuthering Waves and Reverse 1999.

However, although the crashing happened regularly in the day immediately after the update to version 139, and in the day after the update to 139.0.1, it has been happening less often as of late.

Comment 14

[andrei.brebenel]

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

I think it's very likely that the patch for bug 1969253 fixes this.

That patch is in the latest Nightly. Andrei, can you download a Firefox Nightly from https://nightly.mozilla.org/ and check if the problem appears in that build?

Using the Nightly provided in the link (it seems to be 141.0a1), I haven't been able to replicate the issue, so it seems to be fixed there. I'm not sure if it's fixed or if it's just a coincidence, but I haven't seemed to be able to trigger it at all.

Comment 15

[Ashley Hale [:ahale]]

I'm going to assume this is fixed then.