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!

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.

A small addition: Firefox 150.0 (from Mozilla’s PPA) is similarly affected for me, so this is indeed an upstream one.

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).

I can’t remember when exactly this began, but for maybe a few weeks now the first clicks of the share button in the web UI just give a ”Sharing is not available for private podcasts” notification at the bottom corner. This is for any and all podcasts, so not just actually private ones. After two or three clicks the sharing dialog then finally does pop up.

My main browser is Librewolf (based on Firefox), but the same issue occurs in Vivaldi too (which is based on Chromium).

There’s nothing in the browser’s console about this (no errors at all).

I made a screencast demonstrating the issue: https://youtu.be/5_LieFpsz0I

Thanks. I had hoped for either some correlation with my history.log, or something connected to drawing/rendering the desktop, but nothing jumps out from those, alas. The nvidia/libnvidia-* ones from the 23rd would be the obvious suspect, except you had already posted about the problems (above) when those packages were getting installed.

The apparmor denials for Firefox seem to be a known issue. I don’t use Firefox (and back when I did, I used the Mozilla PPA version instead of the snap), but I suspect they’re not related to the freeze. At least not unless you’re running particularly low on memory.

Kun avaan tämänpäiväisen sisäpyöräilysuoritteeni muokattavaksi Connectin web-näkymässä (Vivaldilla tai Firefoxilla), ja yritän syöttää matkan pituuden, joka on 33,24 km, sivusto vaihtaa itsekseen pilkun tilalle pisteen, ja sen jälkeen valittaa, että tämä ei ole kelvollinen lukema: ”Your 33.24 value is not within permissible limits.”

Samaa virhettä se valittaa tietysti myös, jos syötän alunalkujaankin pilkun sijasta pisteen.

Jos typistän lukeman 33,2:een, se menee läpi.

Jos muokkaan samaa suoritetta puhelinsovelluksessa, se tallentaa kaksidesimaalisen arvon ihan mukisematta.

Aiemmin nämä ovat kelvanneet webissäkin ihan hyvin.

Describe the bug
I’m getting inconsistent results when converting AVIF images to other formats, using Firefox (in Ubuntu). I’m self-hosting Mazanoke 1.1.5, but the results are the same with mazanoke.com.

To Reproduce
Steps to reproduce the behavior:

1. Download this example AVIF file (as raw)
2. In Mazanoke, select Convert to: PNG
3. Drag and drop the AVIF file into the browser
4. Click the Download button of the converted file

Expected behavior
to receive a PNG file, fox.profile0.10bpc.yuv420.png

Screenshots
I receive a JPEG file, named fox.profile0.10bpc.yuv420.jpeg

Desktop (please complete the following information):

• OS: Ubuntu 24.04
• Browser Firefox 142.0.1

Additional context
The same thing (i.e. receiving a JPEG file) happens if I choose WebP as output, but not if I choose ICO: downloading the latter does produce a fox.profile0.10bpc.yuv420.ico, as expected.

Choosing JPG output also works as expected (although it would be pretty funny if it didn’t). Notably, this produces the filename fox.profile0.10bpc.yuv420.jpg: the file extension differs from the one produced by Firefox for the unexpected cases (.jpeg).

I can also work around the issue by selecting ”Download all”, which produces a zip archive, and all the files therein are in my chosen output formats as listed.

In Vivaldi (which is based on Chrome) the Download link also does produce the file in the chosen output format. So this looks like Firefox-specific issue.

Converting from (and to) other formats seems to work as expected in Firefox (at least the ones I’ve tested so far).

Summary

Since installing 21.0-20241023-nightly, apps on my tablet can no longer access Internet when Wireguard is connected. This worked just fine right up until 20241023-nightly, and Wireguard’s app hasn’t been updated in over a year, so I’m pretty sure it’s the new build.

Looks like it’s DNS. (It’s always DNS.) There are a couple of conspicuously related-looking commits in this build: 406071 (VPN-covered DNS traffic may not fall through) and 406070 (Revert ”Prevent DNS traffic from bypassing lockdown VPNs”).

Expected Behavior

Apps should be able to connect to the Internet even when Wireguard is connected.

Current Behavior

Apps lose access to Internet immediately when Wireguard is connected. Curiously, Chrome is unaffected; all other apps that I’ve tested are affected, including Firefox, which says ”Address not found”, hinting at DNS.

Steps to Reproduce

1. Install Wireguard
2. Set up a connection that doesn’t route all traffic but just that interface’s address space. I’m including a screenshot of my Wireguard configuration below.
3. Toggle the Wireguard interface on.
4. Open Firefox and try to browse the web.

Device information

/codename gts4lvwifi /version 21 /date 2024-10-23 /kernel 4.9.337-g16026dfb9b4c #1 Wed Oct 23 13:53:22 UTC 2024 /baseband none /mods Google Apps

I have read the directions