Thanks for the instructions, Daniel! I found no crash files either locally or online, so I’ve implemented the workaround now, and will try to trigger the crash again.

For future reference, this was probably Ubuntu bug #1875558 (”libproxy1-plugin-gsettings triggers a lot of warnings”).

Since upgrading to 20.04 and switching to Wayland, Gnome terminal occasionally crashes. I interpret the corresponding logs to mean that it’s actually Wayland that fails to do something in the background, which then takes down Gnome terminal:

touko 08 11:35:16 saegusa gnome-shell[4227]: WL: compositor bug: The compositor tried to use an object from one client in a 'wl_pointer.enter' for a different client.
touko 08 11:35:16 saegusa gnome-shell[4227]: WL: error in client communication (pid 11639)
touko 08 11:35:16 saegusa gnome-terminal-[11639]: Error reading events from display: Katkennut putki
touko 08 11:35:16 saegusa systemd[4153]: vte-spawn-bbca1723-5987-4ccf-98cb-3389ad05641e.scope: Succeeded.
touko 08 11:35:16 saegusa systemd[4153]: vte-spawn-fbe02208-95df-4cf4-bfbe-fffc71d6bc7e.scope: Succeeded.
touko 08 11:35:16 saegusa systemd[4153]: gnome-terminal-server.service: Main process exited, code=exited, status=1/FAILURE
touko 08 11:35:16 saegusa systemd[4153]: gnome-terminal-server.service: Failed with result 'exit-code'.

I have yet to nail down the precise circumstances, as this has (so far) been somewhat rare, having occurred perhaps once or twice a week.

Since the log mentions pointer, I should perhaps mention that I’ve set `org.gnome.desktop.wm.preferences` > `focus-mode` to `mouse`. Gnome terminal also exhibits other misbehaviour wrt. to this, occasionally refusing to get focus, or alternatively losing the focus, despite mouse cursor being over the terminal window.

Boinc-client logs ”No protocol specified” incessantly, twice every second on my setup.

    -- Logs begin at Wed 2020-03-25 14:45:19 EET, end at Fri 2020-05-01 17:14:34 EEST. --
    touko 01 00:00:00 saegusa boinc[2083]: No protocol specified
    touko 01 00:00:00 saegusa boinc[2083]: No protocol specified
    touko 01 00:00:01 saegusa boinc[2083]: No protocol specified
    touko 01 00:00:01 saegusa boinc[2083]: No protocol specified
    touko 01 00:00:02 saegusa boinc[2083]: No protocol specified
    touko 01 00:00:02 saegusa boinc[2083]: No protocol specified
    touko 01 00:00:03 saegusa boinc[2083]: No protocol specified
    touko 01 00:00:03 saegusa boinc[2083]: No protocol specified
    touko 01 00:00:04 saegusa boinc[2083]: No protocol specified
    touko 01 00:00:04 saegusa boinc[2083]: No protocol specified
    touko 01 00:00:05 saegusa boinc[2083]: No protocol specified
    touko 01 00:00:05 saegusa boinc[2083]: No protocol specified
    touko 01 00:00:06 saegusa boinc[2083]: No protocol specified

…and on and on…

    touko 01 17:14:54 saegusa boinc[2083]: No protocol specified
    touko 01 17:14:55 saegusa boinc[2083]: No protocol specified
    touko 01 17:14:55 saegusa boinc[2083]: No protocol specified
    touko 01 17:14:56 saegusa boinc[2083]: No protocol specified
    touko 01 17:14:56 saegusa boinc[2083]: No protocol specified
    touko 01 17:14:57 saegusa boinc[2083]: No protocol specified
    touko 01 17:14:57 saegusa boinc[2083]: No protocol specified
    touko 01 17:14:58 saegusa boinc[2083]: No protocol specified
    touko 01 17:14:58 saegusa boinc[2083]: No protocol specified
    touko 01 17:14:59 saegusa boinc[2083]: No protocol specified
    touko 01 17:14:59 saegusa boinc[2083]: No protocol specified
    touko 01 17:15:00 saegusa boinc[2083]: No protocol specified
    touko 01 17:15:00 saegusa boinc[2083]: No protocol specified
    touko 01 17:15:01 saegusa boinc[2083]: No protocol specified
    touko 01 17:15:01 saegusa boinc[2083]: No protocol specified
    touko 01 17:15:02 saegusa boinc[2083]: No protocol specified
    touko 01 17:15:02 saegusa boinc[2083]: No protocol specified

This is still an issue.

With `media.autoplay.enabled.user-gestures-needed` set to false and `media.autoplay.default` set to 1 (block audio), which is the default (and other autoplay-related settings in their defaults as well), a Twitch video can only be either paused or playing muted; unmuting the video pauses it and vice versa.

== Steps to reproduce ==
1. Open about:config
2. Search for autoplay in the settings
3. Set media.autoplay.enabled.user-gestures-needed to false
4. Set media.autoplay.default to 1
5. Open a Twitch VOD, for instance https://www.twitch.tv/videos/280106033
6. Try to unmute the video

== What happens ==
The video is unmuted, but also paused

== What I expect to happen ==
For the video to continue playing, unmuted

I’m able to reproduce this when I set media.autoplay.enabled.user-gestures-needed to false; if set to true (which is the default), unmuting does not pause the video.

Done. Thanks, Sebastien!

Affected version

I’m using Ubuntu 20.04 and Wayland, with gnome-shell currently at version 3.36.1-4ubuntu1. (I originally filed this on Launchpad.)

Bug summary

When trying to start a virtual machine with Gnome Boxes, I get a prompt about keyboard shortcuts. The prompt text is localized, but translated back to English it says:

Boxes wants to inhibit shortcuts

You can restore shortcuts by pressing Super+Escape.

In my locale (Finnish), it says

Sovellus Boksit haluaa rajoittaa pikanäppäinten toimintaa.

Voit palauttaa pikanäppäinten toiminnan painamalla Super...

(sic; see attached photo)

So the actual key combination is truncated, defeating the point of that part of the text.

This isn’t a localization error (AFAICT, based on the translation source). Rather, it’s caused by the text being forced to fit on a single line of an arbitrarily fixed width, instead of wrapping to span as many lines as needed.

Screenshot