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.

Kirjautumislomakkeen salasanalle varatussa kentässä on liimauksen esto, jonka takia siihen ei voi kopioida salasananhallintaohjelmassa luotua, vahvaa salasanaa. Se heikentää turvallisuutta, ja suosittelen siksi tämän idioottimaisen ”toiminnon” korjaamista.

Järjestelmä ei myöskään rekisteröitymisen yhteydessä lähettänyt sähköpostiosoitteeni osoitteen varmistusviestiä. Saan tuon tuostakin muille tarkoitettuja viestejä, kun ihmiset kirjoittavat väärän osoitteen tällaisille lomakkeille, eikä kyse ole kirjoitusvirheestä (joiden eliminoimiseksi varten lomake vaatii osoitteen kahteen kertaan), vaan nämä tunarit muistavat osoitteensa väärin. Se varmistusviesti on helppo keino eliminoida nämä virheet.

Frankie Knuckles: The Whistle Song. Tästä klassikosta tulee keväinen fiilis vuodenajasta riippumatta, joten tämä sopiikin erityisen hyvin soitettavaksi näin keväällä.

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