openSUSE Firefox/Tbird builds break file-chooser by not listing xdg-desktop-portal as dependency
All, Anyone running Firefox from the openSUSE builds, can you check with Ctrl+O and see if a file-open dialog appears? The problem is there was a change in settings in Firefox: widget.use-xdg-desktop-portal.file-picker=1 Where: 0: never 1: always 2: auto This was apparently done because Plasma will only use native file dialogs if the widget.use-xdg-desktop-portal.file-picker is set to 1. All of this "portal" crapola is courtesy of flatpak sandbox issue. However, for anyone running a desktop that doesn't have xdg-desktop-portal installed, your file-open chooser is now gone. No xdg-desktop-portal, no file-open dialog. Apparently when this use was set to "always", there wasn't also a corresponding dependency added to Firefox/Thrunderbird. So if you don't have the portal packages installed, no file-open anymore. If others have broken Firefox I'll write it up. (this also breaks vscode/vscodiaum, etc..) From the Flatpak documentation: Portals are the framework for securely accessing resources from outside an application sandbox. They provide a range of common features to applications, including: determining network status, opening a file with a file chooser, opening URIs, taking screenshots and screencasts ... They just overlooked the fact that people on Linux actually use software that isn't running in a damn container... Who would have thunk? Let me know if that caught you too. I'm happy to author the bug. -- David C. Rankin, J.D.,P.E.
On 11/16/24 5:57 PM, David C. Rankin wrote:
All,
Anyone running Firefox from the openSUSE builds, can you check with Ctrl+O and see if a file-open dialog appears?
The problem is there was a change in settings in Firefox:
widget.use-xdg-desktop-portal.file-picker=1
Where:
0: never 1: always 2: auto
This was apparently done because Plasma will only use native file dialogs if the widget.use-xdg-desktop-portal.file-picker is set to 1. All of this "portal" crapola is courtesy of flatpak sandbox issue.
However, for anyone running a desktop that doesn't have xdg-desktop-portal installed, your file-open chooser is now gone. No xdg-desktop-portal, no file- open dialog.
Let me add, that even if you do have xdg-desktop-portal installed, but are not running one of the main desktops, your dialogs will still be inoperative because when an app tries to use a portal chooser and it fails -- there is no sane fallback. You can't download and choose where to save the file, there is no chooser. But, if you set widget.use-xdg-desktop-portal.file-picker=0 in firefox, you can get the basic gtk chooser back. -- David C. Rankin, J.D.,P.E.
On 2024-11-17 01:11, David C. Rankin wrote:
On 11/16/24 5:57 PM, David C. Rankin wrote:
...
But, if you set widget.use-xdg-desktop-portal.file-picker=0 in firefox, you can get the basic gtk chooser back.
Mine is 2. Default. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
On 11/17/24 6:49 AM, Carlos E. R. wrote:
On 2024-11-17 01:11, David C. Rankin wrote:
On 11/16/24 5:57 PM, David C. Rankin wrote:
...
But, if you set widget.use-xdg-desktop-portal.file-picker=0 in firefox, you can get the basic gtk chooser back.
Mine is 2. Default.
Tumbleweed default is 1 for some strange reason. If I choose "reset" on the value, it goes to 1. -- David C. Rankin, J.D.,P.E.
On 2024-11-18 10:36, David C. Rankin wrote:
On 11/17/24 6:49 AM, Carlos E. R. wrote:
On 2024-11-17 01:11, David C. Rankin wrote:
On 11/16/24 5:57 PM, David C. Rankin wrote:
...
But, if you set widget.use-xdg-desktop-portal.file-picker=0 in firefox, you can get the basic gtk chooser back.
Mine is 2. Default.
Tumbleweed default is 1 for some strange reason. If I choose "reset" on the value, it goes to 1.
Here, the reset button is gone if the setting has the default value already. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
On 11/18/24 5:27 AM, Carlos E. R. wrote:
Tumbleweed default is 1 for some strange reason. If I choose "reset" on the value, it goes to 1.
Here, the reset button is gone if the setting has the default value already.
Yes, recall I had set it to 0. 2 (auto) is also fine. Why is TW defaulting to 1?? -- David C. Rankin, J.D.,P.E.
Am 18.11.24 um 22:00 schrieb David C. Rankin:
On 11/18/24 5:27 AM, Carlos E. R. wrote:
Tumbleweed default is 1 for some strange reason. If I choose "reset" on the value, it goes to 1.
Here, the reset button is gone if the setting has the default value already.
Yes, recall I had set it to 0. 2 (auto) is also fine. Why is TW defaulting to 1??
Because it was proposed and requested here: https://bugzilla.suse.com/show_bug.cgi?id=1226112 The learning that xdg-desktop-portal does not work for all cases on all DEs came later. The solution I'm currently thinking about is to set it to two only when running in Plasma but Firefox does not have that possibility and it requires to bring back some KDE detection mechanism in Firefox and set the pref only in that case. This is the plan but given a bit of limited time it will take a few more days to create a patch. Wolfgang
Wolfgang Rosenauer composed on 2024-11-19 13:51 (UTC+0100):
Am 18.11.24 um 22:00 schrieb David C. Rankin:
On 11/18/24 5:27 AM, Carlos E. R. wrote:
Tumbleweed default is 1 for some strange reason. If I choose "reset" on the value, it goes to 1.
Here, the reset button is gone if the setting has the default value already.
Yes, recall I had set it to 0. 2 (auto) is also fine. Why is TW defaulting to 1??
Because it was proposed and requested here: https://bugzilla.suse.com/show_bug.cgi?id=1226112
This is an openSUSE mailing list, discussing openSUSE software: https://bugzilla.opensuse.org/show_bug.cgi?id=1226112
The learning that xdg-desktop-portal does not work for all cases on all DEs came later. The solution I'm currently thinking about is to set it to two only when running in Plasma but Firefox does not have that possibility and it requires to bring back some KDE detection mechanism in Firefox and set the pref only in that case. This is the plan but given a bit of limited time it will take a few more days to create a patch.-- Evolution as taught in public schools is, like religion, based on faith, not based on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Am 19.11.24 um 15:52 schrieb Felix Miata:
Because it was proposed and requested here: https://bugzilla.suse.com/show_bug.cgi?id=1226112
This is an openSUSE mailing list, discussing openSUSE software:
wow, I got this link from a bugzilla notification mail quickly and I promise I will never check in future if that spits out a suse or opensuse url, sorry for that. Feel free to correct me in that case as many times as you want. Alternatively convince the bugzilla maintainers that bug notifications must never use suse.com but opensuse.org when sent to community members. Wolfgang
Wolfgang Rosenauer composed on 2024-11-19 15:56 (UTC+0100):
schrieb Felix Miata:
Because it was proposed and requested here: https://bugzilla.suse.com/show_bug.cgi?id=1226112
This is an openSUSE mailing list, discussing openSUSE software:
wow, I got this link from a bugzilla notification mail quickly and I promise I will never check in future if that spits out a suse or opensuse url, sorry for that.
Since 19 months ago, all bugmail has provided bugzilla.suse.com URLs exclusively.
Feel free to correct me in that case as many times as you want. Alternatively convince the bugzilla maintainers that bug notifications must never use suse.com but opensuse.org when sent to community members.
Those responsible for Bugzilla maintenance obviously have no motivation to do anything about openSUSE-specific issues. https://bugzilla.opensuse.org/show_bug.cgi?id=1210603 "new" since April '23 regression all bugmail attributable to, or respecting, opensuse.org products or components should either contain opensuse.org URIs instead of suse.com, or in addition to https://bugzilla.opensuse.org/show_bug.cgi?id=1210546 "in progress" since June '23 bugzilla.opensuse.org bugmail apparently stopped after bugzilla software upgrade began when https://progress.opensuse.org/issues/127769 was fixed https://bugzilla.opensuse.org/show_bug.cgi?id=863582#c4 "confirmed" 2015 Each bug report should have only one URL https://bugzilla.opensuse.org/show_bug.cgi?id=753203 "confirmed" 2014 Please make Bugzilla easier on openSUSE users Some of these block or depend on bugs requiring "authorization" to access. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
19.11.2024 18:39, Felix Miata wrote:
Those responsible for Bugzilla maintenance obviously have no motivation to do anything about openSUSE-specific issues.
Then what are you trying to achieve barking up the wrong tree on every occasion? Do you demand that everyone must change URL they post to this list to please you personally?
Andrei Borzenkov composed on 2024-11-19 20:41 (UTC+0300):
Felix Miata wrote:
Those responsible for Bugzilla maintenance obviously have no motivation to do anything about openSUSE-specific issues.
Then what are you trying to achieve barking up the wrong tree on every occasion? Do you demand that everyone must change URL they post to this list to please you personally?
It would be nice if people would actively remember their community at least occasionally. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On Tuesday 19 November 2024 08:52:00 Felix Miata wrote:
Wolfgang Rosenauer composed on 2024-11-19 13:51 (UTC+0100):
Am 18.11.24 um 22:00 schrieb David C. Rankin:
On 11/18/24 5:27 AM, Carlos E. R. wrote:
Tumbleweed default is 1 for some strange reason. If I choose "reset" on the value, it goes to 1.
Here, the reset button is gone if the setting has the default value already.
Yes, recall I had set it to 0. 2 (auto) is also fine. Why is TW defaulting to 1??
Because it was proposed and requested here: https://bugzilla.suse.com/show_bug.cgi?id=1226112
This is an openSUSE mailing list, discussing openSUSE software:
https://bugzilla.opensuse.org/show_bug.cgi?id=1226112
The learning that xdg-desktop-portal does not work for all cases on all DEs came later. The solution I'm currently thinking about is to set it to two only when running in Plasma but Firefox does not have that possibility and it requires to bring back some KDE detection mechanism in Firefox and set the pref only in that case. This is the plan but given a bit of limited time it will take a few more days to create a patch.-- In addition to Plasma, KDE3 and Trinity Desktop (a fork of KDE3) are still available and actively used.
Leslie -- Platform: Linux Distribution: openSUSE Leap 15.6 - x86_64 Desktop Environment: Trinity Qt: 3.5.0 TDE: R14.1.2 tde-config: 1.0
On 11/19/24 5:17 PM, J Leslie Turriff via openSUSE Users wrote:
The learning that xdg-desktop-portal does not work for all cases on all DEs came later. The solution I'm currently thinking about is to set it to two only when running in Plasma but Firefox does not have that possibility and it requires to bring back some KDE detection mechanism in Firefox and set the pref only in that case. This is the plan but given a bit of limited time it will take a few more days to create a patch.-- In addition to Plasma, KDE3 and Trinity Desktop (a fork of KDE3) are still available and actively used.
The problem was created upstream in whatever electron or xdg-desktop-portal did. The problem is a lack of validation of what utility they find in the Linux $PATH and attempt to use as a fileChooser. If they find 'kdialog' - they blindly assume it is Plasma's kdialog which supports the --attach option to bind the dialog as a modal dialog to the parents window_id. Problem is that kdialog from TDE/KDE3 does not support the --attach option and fails with an error. However, this is never checked in the electron implementation so the default Gtk dialog is not provided if kdialog fails. This leaves the application without any file-dialogs. This has bitten Mozilla and Microsoft vscode and the vscodium port. (and others I'm sure, but those are what broke on me) The electron commit responsible for the vscode/vscodium (and likely others) issue is: https://github.com/electron/electron/pull/42045 This must be an upstream fix. It cannot be that electron and/or xdg-desktop-portal breaks things for numerous apps and desktops -- but then leaves the problem it create to every app and desktop to work-around, patch and fix. That's just nuts. It's also a bit of a depressing glimpse at how software is being put together today by grabbing bits and pieces from around the internet and then "integrating" features into larger more mature packages without fully understanding the limitations of the library or utility used, or doing thorough validation on what utility was actually found and further whether it worked the way it was envisioned to work by the integrator. The laughable part of how this is done is the PATH ordering can make or break the file-chooser if you have multiple versions of a chooser utility installed by various desktops. If the older version's path is listed before the new, then your dialogs fail just be the luck of how the search-directories in your PATH or ordered. So upstream needs to fix this as it make no sense for every app that uses whatever code that is to have to reinvent differing fixes for what was broken upstream. Worst case, all app with have to patch and fix whatever chooser like kdialog that is being used. The TDE/KDE3 discussion is at https://mirror.git.trinitydesktop.org/gitea/TDE/tdelibs/issues/318 Mozilla at least provides an about:config setting that lets you turn the portal implementation off (or just switch it back to auto) and the Mozilla apps do fine then. The downside is the user wonder what the hell happened to being about to open, print or save a file in the mean time. It took by chance working with a skilled vscode dev to get the magic command line arguments to even see what was happening. A general Linux user, not used to crawling through issues and pull-requests on GitHub, etc.. would just be screwed. That's just the kdialog part, there are other similar utilities that a sought and found that are in the same boat given the comments of no file-choosers since June for vscode. That's about the size of it. Helping push the upstream folk to just make sure the dialog it choose actually opened (a simple 1 sec timer test after the chooser was launched should provide a valid check of whether or not a chooser displayed, and if not, or in case it returned an error, just provide a sane fallback to the default Gtk chooser solves all problems. SUSE raising/pushing the issue may speed the wheels of progress to get a fix much faster the users requesting it (hint, hint....) The vscode/vscodium workaround of just removing part of your PATH that finds the old kdilog or zenity, etc... and provide the rest of the path as a local PATH for launching vscode. Works just fine, the old default Gtk dialog pop right up and that app works again. Maybe all this new stuff isn't really being programmed at all. Maybe it's just a couple of junior programmers having a chat with ChatGPT anymore. That would certainly explain this half-bake implementation to find an use native dialogs. I guess ChatGPt just left out the part about kdialog being a gui-tool designed for shell-progrmmer use -- but it can generate choosers too. Mind boggling. -- David C. Rankin, J.D.,P.E.
On 2024-11-17 00:57, David C. Rankin wrote:
All,
Anyone running Firefox from the openSUSE builds, can you check with Ctrl+O and see if a file-open dialog appears?
It does. Leap 15.5, XFCE, FF 128.4.0esr (64-bit) In TB, it opens the current email in a tab.
The problem is there was a change in settings in Firefox:
widget.use-xdg-desktop-portal.file-picker=1
Where:
0: never 1: always 2: auto
This was apparently done because Plasma will only use native file dialogs if the widget.use-xdg-desktop-portal.file-picker is set to 1. All of this "portal" crapola is courtesy of flatpak sandbox issue.
However, for anyone running a desktop that doesn't have xdg-desktop- portal installed, your file-open chooser is now gone. No xdg-desktop- portal, no file-open dialog.
I don't have that. cer@Telcontar:~> xdg-desktop-[tab][tab] xdg-desktop-icon xdg-desktop-menu cer@Telcontar:~> ... -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
participants (6)
-
Andrei Borzenkov -
Carlos E. R. -
David C. Rankin -
Felix Miata -
J Leslie Turriff -
Wolfgang Rosenauer