I ran mozregression like this (twice, to be sure):
MOZ_ENABLE_WAYLAND=1 mozregression --profile /home/jani/.mozilla/firefox/fyaus28k.LP1940417 --bad 91 --good 89 --profile-persistence clone-first
Here’s the result (it was the same for both bisects):
5:25.73 INFO: No more integration revisions, bisection finished.
5:25.73 INFO: Last good revision: 9f0fbb1431721c9eae68a3c94ae49a4d33fdb1f8
5:25.73 INFO: First bad revision: 7b82d177a6b979036f180329be6b029d690d9e0c
5:25.73 INFO: Pushlog:
According to that log, this changeset was introduced to address #1661516.
1. There’s nothing in /var/crash
2. There are no reports on the page for this computer.
3. Done, still nothing in /var/crash.
I don’t know if this means it’s not a true crash, although visually all the indications are there.
I also verified that this reproduces when using a newly-created user (with the only change from defaults for it being switching to Wayland), and also on another computer (also running 20.04). I am limited to using the one mouse that I have, so that all testing so far has been with the same mouse.
# Steps to reproduce
0. have a mouse with horizontal scrolling functionality (mine is a Microsoft Comfort Mouse 4500 with a tilting action for horizontal scroll)
1. move mouse pointer over the dock
2. use the mouse scroller to scroll horizontally
# What I expect to happen
# What happens
Mouse pointer and everything on screen freezes. After a few seconds it unfreezes, but all the icons from the dock are missing. I have to log out and back in to restore the dock.
# Other info
Slightly similar to LP #1875106, but I’m not using imwheel.
I am using Wayland.
Syslog seems to always point to this one function: ”The offending callback was get_preferred_height(), a vfunc”. I’ll attach the relevant part from one crash.
Since recently, editing the description takes two clicks instead of just one. The first click turns the content into a textbox, but it remains unfocused until I click it again.
Server Setup Information:
- Did you test in newest Wekan?: yes
- For new Wekan install, did you configure root-url correctly so Wekan cards open correctly? yes
- Wekan version: 4.49
- Meteor version: 2.0-beta.4
- Node version: 12.19.0
- MongoDB version: 3.2.22
- Operating System: Ubuntu 20.04
- Deployment Method: snap
- Http frontend if any: Apache
- What webbrowser version are you using? Both Firefox 82.0.2 and Chrome 86.0.4240.183 equally affected.
- If using Snap, what does show command
sudo snap logs wekan.wekan? nothing
Sorry for not providing animation, as peek doesn’t support Wayland. The steps below should be sufficient though.
Steps to reproduce:
- Open a card
- Click on the description once
What I expect to happen:
For the description to have focus (i.e. cursor, to be able to type)
What happens instead:
The description textbox remains unfocused and I can not type into it
Console log contents
site.webmanifest:1 GET https://my-domain.com/site.webmanifest 404 (Not Found)
site.webmanifest:1 Manifest: Line: 1, column: 1, Syntax error.
A bad HTTP response code (404) was received when fetching the script.
mZLgcqMWYXM4o7dmL:1 Uncaught (in promise) TypeError: Failed to register a ServiceWorker for scope ('https://my-domain.com/') with script ('https://my-domain.com/pwa-service-worker.js'): A bad HTTP response code (404) was received when fetching the script.
It seems to refer to to paths in the domain root, whereas my root-url has the path https://my-domain.com/kan. Not sure if that’s related to the issue or not.
After updating Firefox from 78 to 79, hardware-accelerated video decoding no longer works properly in Wayland: streaming video gets cut off with an error message from the service.
== Steps to reproduce ==
1. Follow the steps in  to enable VA-API.
2. Open a Youtube/Twitch video (for instance https://www.twitch.tv/rifftrax), press play
== What I expect to happen ==
For the video be played without issues (as it did with Firefox 78).
== What happens ==
After playing for a while (anything from just a few seconds to a couple of minutes), the video stops and is replaced by a service-specific error message, such as error #3000 (in case of Twitch) or (Youtube). Even when playing, the video also flickers green. After reloading the tab, the video again plays for a few seconds before the error message reappears.
== Other info ==
A fix is apparently already in the works upstream .
*  https://mastransky.wordpress.com/2020/06/03/firefox-on-fedora-finally-gets-va-api-on-wayland/
*  https://bugzilla.mozilla.org/show_bug.cgi?id=1645671
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: 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: WL: error in client communication (pid 11639)
touko 08 11:35:16 saegusa gnome-terminal-: Error reading events from display: Katkennut putki
touko 08 11:35:16 saegusa systemd: vte-spawn-bbca1723-5987-4ccf-98cb-3389ad05641e.scope: Succeeded.
touko 08 11:35:16 saegusa systemd: vte-spawn-fbe02208-95df-4cf4-bfbe-fffc71d6bc7e.scope: Succeeded.
touko 08 11:35:16 saegusa systemd: gnome-terminal-server.service: Main process exited, code=exited, status=1/FAILURE
touko 08 11:35:16 saegusa systemd: 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.
Oh and I’m using Wayland, in case it matters here. Haven’t yet tried whether Xorg is similarly affected.
Alright, from my brief testing it would seem this does not reproduce under Wayland.
My recipe above appears to be quite sensitive to details: I have a test user with a clean desktop (with little more customization apart from the extension), and there the recipe works just as written. On the other hand, with my main user account it doesn’t. To clarify: while the steps listed above fail to reproduce the issue with my main account, my main account does manifest the issue too; just not with those exact steps.
My main account starts up the Signal desktop client, Nextcloud client and some other stuff upon login, but so far I haven’t found which of those (if any) causes this difference.
I was, however, able to reproduce the ”see-through hole” effect under both accounts: instead of maximizing Gnome terminal (in step 3), I tile it to cover the left half of my screen, then start up Chrome/Firefox, tile itover the terminal window (i.e. to also cover the left half of the screen), before turning the display off and on again. Firefox then also manifests the hole, as does Gnome terminal when brought back to foreground from below. (Chrome does not manifest the hole, but then again Chrome has always appeared oblivious to the extension here.)
I should mention that I’m leaving the display off for about 4-5 seconds before turning it back on again. I’m not sure if that makes any difference, I’m just doing to to be sure that the ”I’m off” signal has time to propagate back to the system.
I’ve only used Xorg too, but I may be able to try reproducing it under Wayland over the weekend.