152.0a1 could no longer reproduce the issue
I fired up 152.0a1 (from nightly), did my steps above, and could no longer reproduce the issue. So it does seem to be fixed!
Viestit paikassa Mozilla Bugzilla
Attaching my log with MOZ_LOG=”WidgetScreen:5,WidgetWayland:5,Widget:5,WidgetPopup:5″
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
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.
I tested the 94.0a1 nightly now, and the issue is still present
Also, I tested the 94.0a1 nightly now, and the issue is still present.
I ran mozregression and got the first bad revision
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.
The trigger for this is MOZ_ENABLE_WAYLAND=1 and layout.css.devPixelsPerPx=1.2
I can’t speak for Jeroen, but I played around with the upstream builds (both 92 and 91) and my faulty profile a bit and managed to isolate the trigger combination for this: MOZ_ENABLE_WAYLAND=1 and setting layout.css.devPixelsPerPx to my preferred value of 1.2; either resetting layout.css.devPixelsPerPx to its default (-1.0), or running Firefox without MOZ_ENABLE_WAYLAND=1 will make the toolbar items work again. Here’s the graphics portion of my about:support.
So my steps to reproduce this are:
- start Firefox with
MOZ_ENABLE_WAYLAND=1 - set
layout.css.devPixelsPerPxto1.2 - click on the hamburger menu button
What I expect to happen:
For the hamburger menu content to show.
What happens instead:
The hamburger menu content flickers or doesn’t show at all.
Here’s the updated steps to reproduce
Steps to reproduce
- Open about:config
- Search for autoplay in the settings
- Set
media.autoplay.defaultto1(”Block Audio”, which is the default) - Set
media.autoplay.blocking_policyto2 - Open a Twitch VOD, for instance https://www.twitch.tv/videos/280106033
- Try to unmute the video (either by clicking Twitch player’s speaker control button, or by dragging the accompanying volume slider)
What I expect to happen
For the audio to be unmuted.
What happens instead
The audio remains muted, and the volume control/indicator remains in the muted position.
I’m unmotivated to report this to Twitch, as I’m unsure about the precise meaning of media.autoplay.blocking_policy, and I currently don’t use the non-working value for it myself. Feel free to downprioritize this as you see fit, unless the original reporter is still affected. Here’s my downstream report over at Launchpad though, just for reference. (I’ll update it too.)
Does not appear to have been fixed by Firefox 88
Hi Alex!
It does not appear to have been fully fixed by Firefox 88 for me at least, although the conditions have changed slightly, and the remaining broken behavior is now slightly different too.
First, to update my note above: media.autoplay.enabled.user-gestures-needed has been superseded by media.autoplay.blocking_policy, and setting the latter to 2 is now required to trigger the issue (as it manifests presently); with the setting at either 0 or 1 I haven’t been able to reproduce any variation of the issue.
Now, the video doesn’t get paused anymore, but the unmuting also does not work: clicking the muted indicator just always resets it back to muted, instead of actually unmuting.
I haven’t seen this since Ubuntu-distributed Firefox was updated to 84
For me this seems to have resolved itself since Ubuntu-distributed Firefox was updated to 84, though for all I know, it may have just coincided with some change implemented at Twitter’s end.
I tested 95.0a1 (Nightly), and opening the hamburger menu (using the steps I outlined above) works now.
Closing it is still partly broken though, as clicking on the menu button doesn’t close the menu; I think that is bug 1694514.
For a workaround, clicking outside the menu (and the menu button) does close the menu.