They are not the same problem. The Qt one is related to the compositor crashing. Instead of dying immediately when the application loses connection to the comp

They are not the same problem. The Qt one is related to the compositor crashing. Instead of dying immediately when the application loses connection to the compositor, it instead waits until the compositor recovers from the crash, and treats the compositor crash as a GPU reset. Wayland here has the advantage that it holds very little graphical context of the program, except the framebuffer and a few things, and the client controls everything else. As such, the recovery mechanism can be made _unidirectional_. The only thing the compositor needs to do, is to inform clients of the crash and the clients will handle the rest. The wayland-proxy one is related to the application not handling messages fast enough. In case it is not clear, a Wayland application typically crashes if it is disconnected by the compositor. The compositor disconnects because it cannot send any more messages to the application. It is usually due to the application hanging, making disconnection a reasonable action to take. But it could also just be a legitimate working application under heavy load, and this is where disconnection is actually _not_ desirable - this is what wayland-proxy fixes. However, one could also treat the forced disconnection as some kind of "controlled compositor crashing", and so Qt's approach could probably work for Firefox too. But the effects will be user-visible, since the browser windows will be closed and recreated again.