Webcord uses the wrong filepicker instead of the one provided by the xdg portal

[SpidFightFR]

Acknowledgements

• I have checked that there is no other issue describing the same or
  similar problem that I currently have, regardless if it has been
  closed or open.

• This bug affects Discord website.

• This issue is confirmed to be reproducible when WebCord is packaged
  on at least all three latest supported Electron major releases.

• This issue is reproducible in Chrome, Chromium or any
  Chromium-based browser, e.g Brave or Edge (please write in
  Additional Context which browser you have used if it is neither
  Chrome nor unmodified Chromium).

• There are no fixes done to master which resolves this issue.

• My issue describes one of the unstable and/or not fully implemented
  features.

• I have found a workaround to mitigate or temporarily fix this issue
  in affected releases (please write it in Additional context section
  below).

Operating System / Platform

🐧️ Linux

Operating system architecture

x64 (64-bit Intel/AMD)

Electron version

32.1.2

Application version

v4.10.2

Bug description

"Upload files" feature chooses the gtk filepicker instead of the systemwide file picker.
Webcord:

System-wide filepicker (example here with firefox, it uses the xdg portal for kde):

Additional context

I use the flatpak version that i maintain.
I checked flatseals permissions, nothing to be reported.

This issue started happening since a few days. I updated the package to 4.10.2 yesterday, there might be a correlation.
I also noticed a gtk4 update recently, i tried to uninstall the gtk portal as a consequence but it breaks even more things (such as the fonts of the filepicker).

[SpacingBat3]

I use the flatpak version that i maintain.
I checked flatseals permissions, nothing to be reported.

No matter if you're maintaining it or not, or if you don't see any mistake at your own side, I still need reports from non-sandboxed packaging formats I maintain (there's still Chromium process separation, but that's another thing). This makes sure that your case happens with standard builds as well.

[SpidFightFR]

I use the flatpak version that i maintain.
I checked flatseals permissions, nothing to be reported.

No matter if you're maintaining it or not, or if you don't see any mistake at your own side, I still need reports from non-sandboxed packaging formats I maintain (there's still Chromium process separation, but that's another thing). This makes sure that your case happens with standard builds as well.

Damn, i can't really test this in a non-sandboxed environment as of right now... if it's an appimage directly is it okay ?

[SpacingBat3]

Damn, i can't really test this in a non-sandboxed environment as of right now...

If you really need to, you might also setup some container or VM but this has to be a full Linux enviroment without any quirks or limitations. I just want to eliminate for sure the format / sandboxing issues with the Flatpak. Should say Chromium somewhat sandbox processes, it is in WebCord's best interest to work in a way Discord can't access anything outside of what browsers need to offer it to work. And AppImages both don't contain whole dependencies and aren't sandboxed as of the package format, sure there are ways like MACs to limit the execution but stuff like that can still backfire at you when you set it up inproperly (I really think you need some maintenance expertise when it comes to sandboxing and MAC stuff to troubleshoot what's going on with the software and why, at least that's what my experience with Firefox and Apparmor tells me).

So please go with unsandboxed environment or something that resembles it like VM.

[SpidFightFR]

Damn, i can't really test this in a non-sandboxed environment as of right now...

If you really need to, you might also setup some container or VM but this has to be a full Linux enviroment without any quirks or limitations. I just want to eliminate for sure the format / sandboxing issues with the Flatpak. Should say Chromium somewhat sandbox processes, it is in WebCord's best interest to work in a way Discord can't access anything outside of what browsers need to offer it to work. And AppImages both don't contain whole dependencies and aren't sandboxed as of the package format, sure there are ways like MACs to limit the execution but stuff like that can still backfire at you when you set it up inproperly (I really think you need some maintenance expertise when it comes to sandboxing and MAC stuff to troubleshoot what's going on with the software and why, at least that's what my experience with Firefox and Apparmor tells me).

So please go with unsandboxed environment or something that resembles it like VM.

Alright i got a good idea but i'll be able to test things in a few minutes tho. I hope that's okay!

[SpidFightFR]

@SpacingBat3 hello again, the Appimage works.

So it's a sandboxing issue.
I managed to get an error tho: Server is missing xdg_foreign support
I'll see what i can do with it.

[SpidFightFR]

Alright...! i made a fair amount of tests. To conclude my tests:

Appimage works as intended.
As for flatpak:
I thought it might be caused because we changed the permission system with wayland detection.
Turns out it doesn't impact the client. Despite my tests.

However, the version bump from 4.10.1 to 4.10.2 allows this issue to happen. I tend to believe something changed in-between in order for that to happen.

EDIT: More info in the PR linked above.

[kaizoplant]

Okay I believe the issue here is from the electron version update Electron 32.1 does not use the portals inside a flatpak application, as it is updated from version 32.0.1 to 32.1.2. The xdg-desktop-portal minimum version should be changed back to 3 soon, so I think it's just a matter of updating electron when that happens?

[SpidFightFR]

Okay I believe the issue here is from the electron version update Electron 32.1 does not use the portals inside a flatpak application, as it is updated from version 32.0.1 to 32.1.2. The xdg-desktop-portal minimum version should be changed back to 3 soon, so I think it's just a matter of updating electron when that happens?

I see... thanks.

[SpidFightFR]

@SpacingBat3 do you think it would be possible for me to use a slightly older version of electron (that doesn't have this issue), while we wait for a fix?

Afaik electron apps work with asar archives or something, i can't quite remember, would there be fixed dependencies to the current electron version? I could attempt replacing it?

[SpacingBat3]

@SpacingBat3 do you think it would be possible for me to use a slightly older version of electron (that doesn't have this issue), while we wait for a fix?

Afaik electron apps work with asar archives or something, i can't quite remember, would there be fixed dependencies to the current electron version? I could attempt replacing it?

I mean basically yes, you can package Electron apps actually from scratch using the ZIP files Electron provides on GitHub. On Linux you don't even need to rebrand the binary, since ELF doesn't contain much metadata like this unlike to what's done in macOS / Windows application formats.
Also please be aware that by using newer / older Electron version you might encounter issues that are not happening normally in WebCord. So support in that case from my side would be limited.