User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36

Steps to reproduce:

I just upgraded to Ubuntu 22.04 LTS and as part of the upgrade my firefox binary was transitioned to a snap.

Firefox used to work perfectly and without any problems.

Now it will not start.

After reading other bug reports I found one that recommended running xhost + to solve the problem. That partially worked for me too.

Firefox will now start, but it will not open any File Open or File Save dialog boxes, so is still in an unusable state.

Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:105.0) Gecko/20100101 Firefox/105.0

105.0.1 (64-bit) Mozilla Firefox Snap for Ubuntu canonical -002 - 1.0

Actual results:

mvincent@desktop:~$ locale
LANG=en_GB.UTF-8
LANGUAGE=en_GB:en
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=en_US.UTF-8

mvincent@desktop:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 22.04.1 LTS
Release: 22.04
Codename: jammy

mvincent@desktop:~$ which firefox
/snap/bin/firefox

mvincent@desktop:~$ firefox
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
Client is not authorized to connect to ServerError: cannot open display: :1

mvincent@desktop:~$ xhost +
access control disabled, clients can connect from any host

mvincent@desktop:~$ firefox
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
[GFX1-]: glxtest: GLX extension missing
[GFX1-]: glxtest: eglCreateContext returned an error
Missing chrome or resource URL: resource://gre/modules/UpdateListener.sys.mjs
Missing chrome or resource URL: resource://gre/modules/UpdateListener.sys.mjs
[2022-10-01T17:45:42Z ERROR viaduct::backend::ffi] Missing HTTP status
[2022-10-01T17:45:42Z ERROR viaduct::backend::ffi] Missing HTTP status

*** Firefox is working here (after xhost +) ***

Expected results:

Firefox should start the way it did before without running xhost +.

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

The fact you need to xhost + is not normal. Can you describe your setup ?

Firefox will now start, but it will not open any File Open or File Save dialog boxes, so is still in an unusable state.

Can you share stdout / stderr / journalctl -xe when reproducing? Verify you have xdg-desktop-portal as well as xdg-desktop-portal-gnome and/or xdg-desktop-portal-gtk deb packages installed ?

Olivier, do you have any idea why this happens? Why would xhost + be needed ?

Malcolm, IIUC you're running in an X11 session (can you confirm?), and you have some sort of access control in place which xhost + allows to circumvent?
That's the first time I hear of this problem.

(In reply to Alexandre LISSY :gerard-majax from comment #2)

The fact you need to xhost + is not normal. Can you describe your setup ?

Firefox will now start, but it will not open any File Open or File Save dialog boxes, so is still in an unusable state.

Can you share stdout / stderr / journalctl -xe when reproducing? Verify you have xdg-desktop-portal as well as xdg-desktop-portal-gnome and/or xdg-desktop-portal-gtk deb packages installed ?

Yes I am running an X11 session :-)
I'm using LXDE if that might have anything to do with it.

Chrome / chromium work fine (which is how I am writing this), and firefox used to work before the transition to the snap.

mvincent@desktop:~$ sudo apt list | grep xdg-desktop

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

libghc-xdg-desktop-entry-dev/jammy 0.1.1.1-1build3 amd64
libghc-xdg-desktop-entry-doc/jammy,jammy 0.1.1.1-1build3 all
libghc-xdg-desktop-entry-prof/jammy 0.1.1.1-1build3 amd64
xdg-desktop-portal-dev/jammy-updates,jammy-updates 1.14.4-1ubuntu222.04.1 all
xdg-desktop-portal-gnome/jammy-updates,now 42.1-0ubuntu1 amd64 [installed,automatic]
xdg-desktop-portal-gtk/jammy,now 1.14.0-1build1 amd64 [installed,automatic]
xdg-desktop-portal-kde/jammy-updates 5.24.6-0ubuntu0.1 amd64
xdg-desktop-portal-tests/jammy-updates 1.14.4-1ubuntu222.04.1 amd64
xdg-desktop-portal-wlr/jammy 0.5.0-3 amd64
xdg-desktop-portal/jammy-updates,now 1.14.4-1ubuntu2~22.04.1 amd64 [installed,automatic]

mvincent@desktop:~$ journalctl -xe

Oct 06 10:48:53 desktop systemd[151503]: Started snap.firefox.firefox.a63c0296-25c4-4fd3-ab9d-f0d7a151eb87.scope.
Oct 06 10:49:03 desktop dbus-daemon[151521]: [session uid=1000 pid=151521] Failed to activate service 'org.freedesktop.portal.Desktop': timed out (service_start_timeout=120000ms)
Oct 06 10:49:04 desktop dbus-daemon[151521]: [session uid=1000 pid=151521] Failed to activate service 'org.freedesktop.impl.portal.desktop.gnome': timed out (service_start_timeout=120000ms)
Oct 06 10:49:04 desktop dbus-daemon[151521]: [session uid=1000 pid=151521] Failed to activate service 'org.freedesktop.Notifications': timed out (service_start_timeout=120000ms)

Looks like you have problems with xdg-desktop-portal, that's unfortunate but it is outside of Firefox' scope.

Additional information

I found this bug report https://bugzilla.mozilla.org/show_bug.cgi?id=1639575 , and others on the net (e.g. google xdg-desktop-portal suddenly broken) which suggested that there have been an increase of failures in xdg-desktop-portal. These may or may not be related.

I used about:config and set widget.use-xdg-desktop-portal.file-picker to 0

The file open/save dialogs now work, and firefox starts up immediately instead of after c. 30s which I can only assume was because it was waiting for the xdg-desktop-portal timeout.

Setting xhost 127.0.0.1 in my startup file in combination with this looks like it is starting to make firefox usable again.

I might suggest that if xdg-desktop-portal fails (and there is nothing at all special about my configuration), you don't just error, but instead fall back on the working solution above since firefox obviously knows how to cope with this when it is manually selected by the user.

(In reply to malcolmvincent from comment #7)

[...]

I used about:config and set widget.use-xdg-desktop-portal.file-picker to 0

The file open/save dialogs now work, and firefox starts up immediately instead of after c. 30s which I can only assume was because it was waiting for the xdg-desktop-portal timeout.

How can this even work? From https://searchfox.org/mozilla-central/rev/b0e929cfaf3994cad2dd02afdac138083ee3fc84/widget/gtk/WidgetUtilsGtk.cpp#148,165-166 if you set the pref to 0 it means you disable using the portal and you switch to the GTK file chooser.

According to https://docs.gtk.org/gtk3/class.FileChooserNative.html#portal-details-gtkfilechooserdialognative-portal it seems to suggest that our switch to call the GTK file chooser might in the end still endup with the XDG Desktop Portal.

Can you give a try to /usr/libexec/xdg-desktop-portal-gnome -rv and share the output?

This error makes me wondering:

Oct 06 10:49:04 desktop dbus-daemon[151521]: [session uid=1000 pid=151521] Failed to activate service 'org.freedesktop.impl.portal.desktop.gnome': timed out (service_start_timeout=120000ms)

Also while it might sound "simple" as you suggest in

I might suggest that if xdg-desktop-portal fails (and there is nothing at all special about my configuration), you don't just error, but instead fall back on the working solution above since firefox obviously knows how to cope with this when it is manually selected by the user.

The code that performs calling of the portal is not ours, we rely on GTK.

I would not be surprised, since you have to play with xhost + that you might have a previous XDG Desktop Portal GNOME somehow started before this xhost and somehow we can't communicate with it. It would be nice if you could verify / kill previous such processes.

Also since you are running LXDE, it would be useful to know if you reproduce the issue under GNOME, if you can install some. I'm going to try and check on my side under LXDE on a Ubuntu VM but just in case I dont reproduce ...

Even xhost + does not unblock the situation for me. I'm pretty sure your XDG Desktop Portal issues are just a side effect of the same root cause.

(In reply to Alexandre LISSY :gerard-majax from comment #11)

Even xhost + does not unblock the situation for me. I'm pretty sure your XDG Desktop Portal issues are just a side effect of the same root cause.

Nevermind, I was trying to run Wayland version. Going back to the stable version with XWayland, I:

• dont need xhost +
• get XDG Desktop Portal to work correctly for downloading.

I have tried many combinations now :-)

Removing unity and switching to GNOME-Flashback (Metacity) makes the firefox snap work on the desktop again.

The problem seems most easy to reproduce across different systems when connecting to Ubuntu using TigerVNC or TightVNC.

Chrome / Chromium work perfectly in all configurations.
Installing Firefox-ESR using apt works perfectly across all configurations.

The problem seems to be only with snap.

The 'recipe' for a correctly working snap for me seems to be to put the following into the VNC xstartup file

export XKL_XMODMAP_DISABLE=1

start firefox using the following command from a terminal

DBUS_SESSION_DBUS_ADDRESS=unix:path=$XDG_RUNTIME_DIR/bus firefox

and configure firefox about:config

widget.use-xdg-desktop-portal.file-picker = 0

I think I'm happy now that I have a working version, I can put the startup command in as a bash alias. Hope this helps someone else.