Closed Bug 1516290 Opened 6 years ago Closed 3 years ago

Firefox keeps asking for being set as default browser when GTK_USE_PORTAL=1 is set

Categories

(Core :: Widget: Gtk, defect, P3)

Product:
Core
Component:
Widget: Gtk
Version:
65 Branch
Platform:
x86_64
Linux
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
98 Branch
Tracking Flags:
Tracking Status
firefox98 --- wontfix
firefox99 --- fixed

People

(Reporter: shtetldik, Assigned: rmader)

References

Details

Attachments

(1 file, 1 obsolete file)

Bug 1516290 - Disable xdg mime portal in non-flatpack environments by default, r=emilio,stransky
48 bytes, text/x-phabricator-request
Details | Review 
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0

Steps to reproduce:

According to KDE developers recommendation, I tried enabling native KDE dialog integration with Firefox using xdg-desktop-portal-kde, and noticed that Firefox keeps asking about being set as default browser on each startup.

System: Debian testing Linux, Firefox 65.0b6.

I installed:
xdg-desktop-portal 1.0.3
xdg-desktop-portal-kde 5.14.3

Set in $HOME/.profile:

export GTK_USE_PORTAL=1

Applications > Default Applications > Web Browser already set to Firefox.

When GTK_USE_PORTAL is not set, it's not asking after first time.

I also noticed, that Firefox normally remembers this setting after creating a NoDisplay .desktop file in $HOME/.local/share/applications

Such as:

$HOME/.local/share/applications/userapp-Firefox-IIJAUZ.desktop

[Desktop Entry]
Encoding=UTF-8
Version=1.0
Type=Application
NoDisplay=true
Exec=/opt/mozilla/firefox/firefox-bin %u
Name=Firefox
Comment=Custom definition for Firefox

This is not visible in menu and not available to System Settings choice (because of NoDisplay=true), so I usually create another .desktop file there, to expose Firefox. Something like:

$HOME/.local/share/applications/Firefox.desktop 

[Desktop Entry]
Comment=
Exec=/opt/mozilla/firefox/firefox %u
GenericName=Mozilla Firefox
Icon=/home/user/pictures/icons/firefox.png
MimeType=application/x-www-browser;
Name=Firefox
NoDisplay=false
StartupNotify=false
Terminal=false
TerminalOptions=
Type=Application
X-KDE-SubstituteUID=false
X-KDE-Username=
Categories=Network;WebBrowser;

This way it can be selected in System Settings > Applications > Default Applications > Web Browser.

Something between these two and xdg desktop portal goes wrong I suppose.

Corresponding KDE bug https://bugs.kde.org/show_bug.cgi?id=402206 was closed and KDE developers suggested it's a Firefox issue.

Can you please take a look?
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
Component: Untriaged → Widget: Gtk
Product: Firefox → Core

I can confirm this with Fx 66.0.1 on Fedora using KDE Plasma 5.14.

It doesn't matter to which value GTK_USE_PORTAL is set, the bug occurs even if it set to 0. Unsetting it completely doesn't trigger the prompt anymore.

Status: UNCONFIRMED → NEW
Ever confirmed: true

I can also confirm this with 66.0.4 (64-bit) on Neon.

For portal we may use the same mechanism as for Snap:

https://dxr.mozilla.org/mozilla-central/rev/cb5734727c0a9d88e3e236a3e4a741a051509e0e/browser/components/shell/nsGNOMEShellService.cpp#188

It should work unless home dir read+write access is sandboxed.

Priority: -- → P3

Can you please try latest nightly? This can be also a dupe of Bug 1526243.

Flags: needinfo?(shtetldik)

I tried nightly and was getting the same thing but I noticed that if I use firefox rather than firefox-bin the problem stopped. I went back to my installed stable and launched /usr/lib/firefox/firefox instead of through a desktop icon and it seems to have stopped.

I believe the difference is in the /usr/bin/firefox file which (I assume) is called from desktop icons. This is a script with this:

#!/bin/sh

export GTK_USE_PORTAL=1

exec _neon.firefox "$@"

I'm not sure what this is doing though.

(In reply to Martin Stránský [:stransky] from comment #4)

Can you please try latest nightly? This can be also a dupe of Bug 1526243.

Just tested it with nightly (69.0a1). It still keeps asking to be set the default browser on start, when GTK_USER_PORTAL=1 is set.

Flags: needinfo?(shtetldik)

Correction I meant GTK_USE_PORTAL=1 in the previous comment, naturally.

Jan, could you look at ti please? Thanks.

Flags: needinfo?(jhorak)

Setting GTK_USER_PORTAL=1 to get KDE native dialog is generally not a good idea. The GTK_USER_PORTAL variable is used to detect if the app runs as a flatpak and that means it cannot use the native print dialog and look for mimetype handlers in Firefox.

So the GTK_USE_PORTAL variable is only meant for Snaps and Flatpaks?

I could not reproduce this issue, I'm on Arch Linux and I'm using KDE Desktop Environment, I've created a custom application for firefox in /home/itsdrike/.local/share/applications/firefox.desktop which overrides the original one. it's command is set to GTK_USE_PORTAL=1 /usr/lib/firefox/firefox %u. I've not experienced any issues about firefox asking to be a default browser as it already was before I've set this option.

(In reply to ItsDrike from comment #11)

I could not reproduce this issue, I'm on Arch Linux and I'm using KDE Desktop Environment, I've created a custom application for firefox in /home/itsdrike/.local/share/applications/firefox.desktop which overrides the original one. it's command is set to GTK_USE_PORTAL=1 /usr/lib/firefox/firefox %u. I've not experienced any issues about firefox asking to be a default browser as it already was before I've set this option.

Which distro are you on? I'm currently on KDE Neon

(In reply to ItsDrike from comment #11)

I could not reproduce this issue, I'm on Arch Linux and I'm using KDE Desktop Environment, I've created a custom application for firefox in /home/itsdrike/.local/share/applications/firefox.desktop which overrides the original one. it's command is set to GTK_USE_PORTAL=1 /usr/lib/firefox/firefox %u. I've not experienced any issues about firefox asking to be a default browser as it already was before I've set this option.

Ignore my previous comment.

HI All,

In case of widget.use-xdg-desktop-portal is set to true, then firefox is not the default browser anymore.
It cannot be made default anymore, unless that value is false.

I think those two are not compatible with each other.

Confirm it on Firefox for Arch Linux 86.0 64 bit KDE.
After install xdg-desktop-portal and xdg-desktop-portal-kde package then set widget.use-xdg-desktop-portal to True, Firefox believe it isn't default browser although I've set it to default browser again and again. No related environment variable was set.

(In reply to miku84 from comment #14)

HI All,

In case of widget.use-xdg-desktop-portal is set to true, then firefox is not the default browser anymore.
It cannot be made default anymore, unless that value is false.

Did you use GTK_USE_PORTAL=1 AND enable widget.use-xdg-desktop-portal, or did you only enable the former?

Hi,

I tried all of it:

  1. MOZ_ENABLE_WAYLAND=1 MOZ_WEBRENDER=1 GTK_USE_PORTAL=1 firefox + widget.use-xdg-desktop-portal true: portal is not working, default browser not working. I think use portal is not needed anymore: https://www.reddit.com/r/kde/comments/hdquxl/how_do_i_make_firefox_open_files_on_dolphin/
  2. firefox with widget.use-xdg-desktop-portal true: portal working, default browser not working
  3. firefox with widget.use-xdg-desktop-portal true + do not check default browser, firefox is not default: portal working, but as firefox is not default, open links are not working
  4. firefox with widget.use-xdg-desktop-portal false: portal off, default browser works. I use this way, as it opens links, but portal is ugly.

The behavior "Firefox keeps asking for being set as default browser" is present in Firefox 89.0 (apt package version 89.0+build2-0ubuntu0.20.04.2 from Ubuntu repositories for "focal" release. GTK_USE_PORTAL=1 and widget.use-xdg-desktop-portal is false in about:config.

Full OS info:

Operating System: KDE neon 5.21
KDE Plasma Version: 5.21.5
KDE Frameworks Version: 5.82.0
Qt Version: 5.15.3
Kernel Version: 5.4.0-73-generic
OS Type: 64-bit
Graphics Platform: X11
Processors: 8 × Intel® Core™ i5-8250U CPU @ 1.60GHz
Memory: 7.7 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics 620

Forgot to mention – this wasn't present in Firefox 88.0 for me.

The issue reappeared for me too on KDE Neon, however I'm pretty sure it started before the 89 update. Maybe one month ago or so.

This issue also appeared for me on Firefox 89, and it was not present previously on 88.
I am on Manjaro Linux with KDE plasma, with GTK_USE_PORTAL=1 set, to be able to use the KDE file dialog.

Hi,

Same here for me, using KDE Neon 20.04 (Firefox v89).

The eternal bug.

Still present in Firefox 90, KDE Neon 20.04.

Can reproduce (FF 94, Gnome, Fedora 35). Very odd bug, will look into it.

Assignee: nobody → robert.mader
Status: NEW → ASSIGNED
See Also: → 1621913, 1515136

So what's happening here is that GTK_USE_PORTAL=1 and widget.use-xdg-desktop-portal activate two technically related but also independent features, mainly targeting sandboxed environments.

The portal for opening URIs is quite limited and apparently there's no system portal yet that would allow to set or even check the default app - and it's not clear to me that there will ever be such a portal. Likely the whole default browser feature should be disabled in sandboxed environments / when portals are used (see bug 1621913 and bug 1515136).

Then there is the file picker portal. This one appears to be a totally different story. AFAICS there's no strong reason to not use the portal, even in non-sandboxed environments, if it's available. The only real reason I can see is that we'd behave differently than other GTK based apps - and FF is very different anyway. This would make the default experience on DEs like KDE quite a bit nicer.

So I guess what we should do here is:

  • split up the portal option into one for the filepicker and one for URIs (and maybe future ones)
  • add detection that checks if the filepicker portal is available
  • if so, enable it by default (with an option to force it off)

Martin, how does that sound to you?

Flags: needinfo?(stransky)

(In reply to Robert Mader [:rmader] from comment #26)

AFAICS there's no strong reason to not use the portal, even in non-sandboxed environments, if it's available. The only real reason I can see is that we'd behave differently than other GTK based apps - and FF is very different anyway. This would make the default experience on DEs like KDE quite a bit nicer.

As someone who enables GTK_USE_PORTAL=1 globally, I have to pour a bit of cold water on this.

GTK developers do plan to enable the portals by default, but they currently require the environment variable because portals sometimes cause functionality regressions.

For example, on Kubuntu Linux 20.04 LTS (what I'm running at least until 22.04 LTS comes out), the portal host is too old to support directory pickers, which causes the Flatpak version of Thunderbird's "save all attachments" option to display a file picker where the filter only allows you to click "Ok" if you've selected a directory, but the rest of the dialog interprets selecting a directory as "enter the directory in search of the file you want" and the only thing you can actually do is Cancel. Very confusing if you don't know the technicals of what's going on.

I'm also told that some bits of metadata (application icon?) are currently fed to the portal host via files only present when running sandboxed, though that one seems to either be specific to the GTK/GNOME portal host or minor enough that I haven't noticed a problem.

It's probably best to just do what GTK does for now when it comes to whether to use the portals by default.

Thanks for that insight. In that case I guess we should just disable the default browser functionality whenever portals are enabled (also fixing bug 1621913 and bug 1515136).

Yes, I think we should disable the default browser check in sandboxed environment as this is controlled by user anyway.

Flags: needinfo?(stransky)
Flags: needinfo?(jhorak)

(In reply to Robert Mader [:rmader] (back on ~23. Nov) from comment #26)

Then there is the file picker portal. This one appears to be a totally different story. AFAICS there's no strong reason to not use the portal, even in non-sandboxed environments, if it's available.

Using the file picker portal in a non-sandboxed environment sonuds a good idea. Chromium recently added such a feature (https://chromium-review.googlesource.com/c/chromium/src/+/2992214). But I think that's another task than the original issue?

(In reply to Chih-Hsuan Yen [:yan12125] (UTC+8) from comment #30)

(In reply to Robert Mader [:rmader] (back on ~23. Nov) from comment #26)

Then there is the file picker portal. This one appears to be a totally different story. AFAICS there's no strong reason to not use the portal, even in non-sandboxed environments, if it's available.

Using the file picker portal in a non-sandboxed environment sonuds a good idea. Chromium recently added such a feature (https://chromium-review.googlesource.com/c/chromium/src/+/2992214). But I think that's another task than the original issue?

Given what I covered in my previous comment, I'd say that the current "defer to GTK's judgment" behaviour is a good position.

  1. It allows people to opt into it with export GTK_USE_PORTAL=1 if the're willing to accept the potential for regressions like the example I gave.
  2. Since the GTK devs do want to make it default eventually, it defers switching to "on by default" to people who are more aware of the progress on eliminating regressions.
  3. Not just relying on GTK to make the decision feels like it'd be another case of "Hey Google, Firefox is ignoring my filetype associations while Chrome defers to xdg-open and Just Works™. How do I fix that?"

Looks like the non-flatpak case was largely fixed in bug 1746559, which disabled printing via portal in non-flatpak environments. From here it's easy to do the same for mime-types. That should help people on e.g. KDE that want a native file picker.

See Also: → 1746559

The mime portal breaks checking and setting the default browser.
thus disable it by default, just like D135120 did for printing.

Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e6e6714aa40a
Check for default browser using xdg-settings before trying to use the protocol handler. r=stransky

Backed out changeset e6e6714aa40a (Bug 1516290) for causing valgrind failures

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&selectedTaskRun=TdeVcINVT06QPURx6CfMiQ.0&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&searchStr=linux%2Cx64%2Cwebrender%2Copt%2Cvalgrind-linux64-valgrind-qr%2Fopt-swr%2Cv-swr&revision=e6e6714aa40aa91e38048129160c9a1b6ab70445

Log: https://treeherder.mozilla.org/logviewer?job_id=365134948&repo=autoland
perma tier2: https://treeherder.mozilla.org/logviewer?job_id=365139586&repo=autoland&lineNumber=45326
There were also some mass failures like:
https://treeherder.mozilla.org/logviewer?job_id=365136749&repo=autoland&lineNumber=3660
https://treeherder.mozilla.org/logviewer?job_id=365138877&repo=autoland&lineNumber=12175
which were green on the backout push

https://treeherder.mozilla.org/jobs?repo=autoland&selectedTaskRun=KpwEYFYPR-2ryrqNjKtxpA.0&resultStatus=success%2Ctestfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&searchStr=linux%2C18.04%2Cx64%2Cwebrender%2Casan%2Copt%2Cmochitests%2Cwith%2Csoftware%2Cwebrender%2Cenabled%2Ctest-linux1804-64-asan-qr%2Fopt-mochitest-browser-chrome-swr-e10s%2Cbc10&tochange=1ce9d23799c35921a9458d145a50b5a57f1baea4&fromchange=2389a3930e08caf7c9ce2d095d0c26a74b56f7b6

https://treeherder.mozilla.org/jobs?repo=autoland&resultStatus=success%2Ctestfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&searchStr=linux%2C18.04%2Cx64%2Cwebrender%2Casan%2Copt%2Creftests%2Ctest-linux1804-64-asan-qr%2Fopt-reftest-e10s%2Cr1&tochange=1ce9d23799c35921a9458d145a50b5a57f1baea4&fromchange=2389a3930e08caf7c9ce2d095d0c26a74b56f7b6

Backout: https://hg.mozilla.org/integration/autoland/rev/1ce9d23799c35921a9458d145a50b5a57f1baea4

Flags: needinfo?(emilio)
Pushed by robert.mader@posteo.de:
https://hg.mozilla.org/integration/autoland/rev/1985d591b133
Disable xdg mime portal in non-flatpack environments by default, r=emilio,stransky

https://hg.mozilla.org/mozilla-central/rev/1985d591b133

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
status-firefox98: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 98 Branch
Flags: needinfo?(emilio)
Attachment #9260166 - Attachment is obsolete: true
QA Whiteboard: [qa-98b-p2]
Regressions: 1756083

Backed out changeset 1985d591b133 (Bug 1516290) for causing a functional regression in snap builds (Bug 1756083) a=backout
https://hg.mozilla.org/releases/mozilla-beta/rev/9e37658e45e4

status-firefox98: fixed → affected
status-firefox99: --- → fixed
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: