Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 1888920

Summary: Firefox crashes on wayland with WL: error in client communication
Product: [Fedora] Fedora Reporter: Tomeu Vizoso <tomeu>
Component: firefoxAssignee: Martin Stransky <stransky>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 33CC: berend.de.schouwer, bward, elxreno, erack, fedora, gcase, gecko-bugs-nobody, gordon.messmer, jhorak, john.j5live, kai-engert-fedora, mkrupcale, notting, pasik, petersen, pjasicek, rhughes, rmeggins, rstrode, sandmann, stransky, tqueiros, vondruch, vponcova
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: firefox-82.0.2-1.fc33 firefox-82.0.2-1.fc32 firefox-82.0.2-1.fc31 firefox-105.0.2-1.fc38 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-10-31 01:54:19 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1054334    
Attachments:
Description Flags
WAYLAND_DEBUG log
none
journal and wayland debug none

Description Tomeu Vizoso 2020-10-16 09:23:37 UTC
Created attachment 1722033 [details]
WAYLAND_DEBUG log

Description of problem:

Mutter kills Firefox when the user switches to the workspace that Firefox is in.

Version-Release number of selected component (if applicable):

firefox-81.0.1-5.fc33.x86_64

How reproducible:

Occasionally

Steps to Reproduce:
1. Open Firefox
2. Work in other workspace
3. Switch back to the workspace Firefox is in

Actual results:

Firefox is terminated

Expected results:

Firefox keeps working

Additional info:

When this happens, I see this in the journal:

Oct 13 10:55:17 cizrna gnome-shell[3667]: WL: error in client communication (pid 20787)

Followed by a bunch of "Exiting due to channel error." messages written by Firefox itself.

I'm attaching the log taken with WAYLAND_DEBUG=1 on the client.

Comment 1 Martin Stransky 2020-10-16 14:38:49 UTC
Hm, I don't see anything relevant in the log...I wonder why mutter closed the connection. Do you have anything in journal for instance?
Thanks.

Comment 2 Tomeu Vizoso 2020-10-16 14:43:10 UTC
(In reply to Martin Stransky from comment #1)
> Hm, I don't see anything relevant in the log...I wonder why mutter closed
> the connection. Do you have anything in journal for instance?

Not really :/

But I found interesting that there's some clipboard-related messages just before the connection is closed. I didn't do anything other than move to the workspace were Firefox is.

Comment 3 Rich Megginson 2020-10-19 20:33:06 UTC
I see the same problem on Fedora 32: firefox-81.0.2-1.fc32.x86_64

Firefox is crashing several times per day

Comment 4 Christian Stadelmann 2020-10-19 20:57:07 UTC
Same here, I see many crashes, though I doubt that the cause is related to workspace switches in my case.

Comment 5 Rich Megginson 2020-10-20 02:00:22 UTC
running firefox in the console I see this message:

IPDL protocol error: Handler returned error code!

###!!! [Parent][DispatchAsyncMessage] Error: PLayerTransaction::Msg_ReleaseLayer Processing error: message was deserialized, but the handler returned false (indicating failure)

Gdk-Message: 19:54:18.997: Error flushing display: Broken pipe
Exiting due to channel error.
Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: Receive IPC close with reason=AbnormalShutdown (t=8183.13) Exiting due to channel error.
Exiting due to channel error.

so I'm not sure if this is https://bugzilla.redhat.com/show_bug.cgi?id=1889251

Comment 6 Gordon Messmer 2020-10-24 00:24:54 UTC
Created attachment 1723869 [details]
journal and wayland debug

In my case, the crash always seems to occur when I switch to the workspace containing a Firefox window after unlocking my screen.

I've attached a file which contains messages from the system journal around the time of a Firefox crash, and the end of a WAYLAND_DEBUG log.

Comment 7 Rich Megginson 2020-10-24 15:40:40 UTC
In my case I don't have multiple workspaces, but it seems to be related to switching windows e.g. using Alt-Tab or using the hotspot with the mouse.

It's still crashing - I just updated to firefox 82.0-4 on f32

This is getting to be a problem - crashing several times a day - I'm considering switching to chrome (and as a former Netscape employee, that kills me to write)

Comment 8 Tomeu Vizoso 2020-10-25 06:24:15 UTC
Wonder if a good first step could be to add to gnome-shell's logging the reason why a client was disconnected. It will surely help in the future to Firefox and other applications as well, if their use of the Wayland protocol isn't what gnome-shell expects.

Comment 9 Martin Stransky 2020-10-25 21:02:06 UTC
btw. as a workaround you can use firefox-x11 which does not run on Wayland backend.

Comment 10 Martin Stransky 2020-10-25 21:43:00 UTC
From the log it looks like mutter is flooded with wayland objects - see the large wl_display chunk on a log end. But I don't know why Mutter does not process the wayland objects and we Firefox keeps to create them. It may be related to missing frame callbacks or so which may lead to cached drawings / shm memory exhaustion or so.

Can you try to run firefox from commnad line with MOZ_LOG="WidgetWayland:5" env variable and attach the log here in a case of the crash?
The log may be huge so please attach only last MB of the log.

Thanks.

Comment 11 Martin Stransky 2020-10-25 21:44:32 UTC
Also wl_display(new id wl_callback@141564) does not look sane....we're not supposed to have such pile of active frame callbacks.

Comment 12 Martin Stransky 2020-10-26 20:42:16 UTC
Seems to be related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3193

Comment 13 Martin Stransky 2020-10-26 21:11:48 UTC
*** Bug 1860451 has been marked as a duplicate of this bug. ***

Comment 14 Martin Stransky 2020-10-26 21:12:31 UTC
*** Bug 1829329 has been marked as a duplicate of this bug. ***

Comment 15 Martin Stransky 2020-10-29 12:26:57 UTC
Added fix to firefox-82.0.2-1 package.

Comment 16 Fedora Update System 2020-10-30 07:23:00 UTC
FEDORA-2020-871455fdcf has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-871455fdcf

Comment 17 Fedora Update System 2020-10-30 07:23:00 UTC
FEDORA-2020-4a0e4504c6 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-4a0e4504c6

Comment 18 Fedora Update System 2020-10-30 19:49:39 UTC
FEDORA-2020-1a48fa788b has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-1a48fa788b

Comment 19 Fedora Update System 2020-10-31 01:54:19 UTC
FEDORA-2020-1a48fa788b has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 20 Fedora Update System 2020-10-31 02:01:50 UTC
FEDORA-2020-4a0e4504c6 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 21 Fedora Update System 2020-10-31 03:16:09 UTC
FEDORA-2020-871455fdcf has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-871455fdcf`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-871455fdcf

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 22 Fedora Update System 2020-11-04 03:54:44 UTC
FEDORA-2020-871455fdcf has been pushed to the Fedora 31 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 23 Fedora Update System 2022-10-05 12:46:58 UTC
FEDORA-2022-f0988ea008 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2022-f0988ea008

Comment 24 Fedora Update System 2022-10-05 12:56:46 UTC
FEDORA-2022-f0988ea008 has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.