I know I’m not the one the request was directed to, but I’ve attached my log anyway. What I did to produce it:
1. MOZ_LOG="WidgetScreen:5,WidgetWayland:5,Widget:5,WidgetPopup:5" /usr/bin/firefox >log.txt 2>&1
2. opened the Wikipedia article for Firefox
3. powered off both my monitors, then powered them back on
4. tried right-clicking many of the links on the page
5. quit Firefox
Reproducible for me in Ubuntu 24.04, Firefox 150.0 from Mozilla’s PPA, with a small difference: new tab button does seem to work, which is useful, since without it wouldn’t be possible to open about:config the workaround of toggling widget.wayland.fractional-scale.enabled.
This looks like #2851 on the COSMIC issue tracker, affecting Firefox. They’ve also reported it upstream.
The COSMIC issue has been closed as having been fixed by 150.0, but there’s at least one dissenter.
Anyway, I’m using a regular Gnome desktop on Ubuntu 24.04, with Wayland, Librewolf 150.0, and funnily enough, for me this only appeared with 150.0 and not before. So now I am affected.
The workaround of toggling widget.wayland.fractional-scale.enabled mentioned in the COSMIC issue seems to work (i.e. after the menus have died, open about:config, toggle the setting from default trueto false, then immediately back to true).
Please tell me more about your window environment; Gnome/Mutter don’t support Client Side Decoration (CSD) for Wayland clients, so wezterm draws its own limited decorations. Those don’t support right clicking or context menus, so I’m not sure how that maximize menu you described shows up.
Sure, though I don’t yet know anything beyond ”this is a standard Ubuntu 20.04 (Gnome) desktop, using Wayland”. Are there any commands I could run to find out more?
Copy & paste doesn’t work in the debug overlay (any selection I make is deselected as soon as I hit Ctrl), but there’s nothing there anyway apart from the intro (no matter how many times I trigger the resizing issue).
Linux Wayland
Gnome
20220927-071112-9be05951
Yes, and I updated the version box above to show the version of the nightly that I tried
I’m running a standard Ubuntu 20.04 Gnome desktop, but with Wayland. Resizing of wezterm window is broken on this setup: selecting ”maximize” from the title bar context menu or dragging the window against the top or the sides of the screen doesn’t maximize/tile the window, but any resizing that does happen results in any text entered in the terminal thereafter to be get garbled. In this screenshot I’ve first entered wezterm --version before resizing, then dragged the window against the top, then entered wezterm --version again:
no config
After step 5, I expect the window to be maximized (i.e. to fill the desktop). After step 6, I expect to see what I typed.
no logs available
The issue is not present in an X11 session. Ubuntu 20.04 defaults to X11, but I’ve used it with Wayland exclusively since the release without issues. More specifically, I can’t remember seeing resizing issues similar to this with any other application.
I also have a laptop running Ubuntu 22.04 and Wayland, and there all resizing of the wezterm window works just as I’d expect (i.e. just as in any other application).
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:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9f0fbb1431721c9eae68a3c94ae49a4d33fdb1f8&tochange=7b82d177a6b979036f180329be6b029d690d9e0c
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
Nothing
# 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:
sudo snap logs wekan.wekan? nothingProblem description:
Sorry for not providing animation, as peek doesn’t support Wayland. The steps below should be sufficient though.
Steps to reproduce:
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 [1] 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 [2].
* [1] https://mastransky.wordpress.com/2020/06/03/firefox-on-fedora-finally-gets-va-api-on-wayland/
* [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1645671