Flatpak Support
tseli0s opened this issue · comments
A very large amount of GNU/Linux applications use the Flatpak packaging format, which, apart from other features, runs the packaged application inside a container. This causes a problem with this crate however, where the browser cannot be located.
Even if specifying full access to the filesystem in the build manifest, some directories are by definition inaccessible to the application, as well as any other Flatpak application available.
There are three solutions to this:
- Require the user to have a browser natively installed.
- Require the developer to ship their own browser (Afaik this is what Electron does with Flathub, however I am not sure so feel free to correct me)
- Or, just make the developer display their webpage in-app as a fallback, which probably requires another crate entirely, and probably one of the two options as well.
@tseli0s, any reason why you think this should be handled inside this crate, instead of the user application handling the error code bubbled up by this crate? The latter approach is the norm in the Rust ecosystem.
Can you also point me how some of the other applications handle such scenarios? Electron isn't the best example here because it packages a browser by definition, while the goal of this crate isn't to bundle a browser, but to open an existing one.
Thanks.
any reason why you think this should be handled inside this crate, instead of the user application handling the error code bubbled up by this crate? The latter approach is the norm in the Rust ecosystem.
Because "handling the error" is not enough. What if the application requires for example signing in? That requires a web browser on all distros. And yes, the developer may not intend to ship it as a Flatpak in that case, but it's often the community packaging the software and flathub takes a long time to respond to takedown requests. In addition, the crate guarantees to open the webpage (According to the documentation), if there's a browser available.
Can you also point me how some of the other applications handle such scenarios? Electron isn't the best example here because it packages a browser by definition, while the goal of this crate isn't to bundle a browser, but to open an existing one.
Most of them usually use xdg-open, and the default browser (If set) will always open. If you give me some time I can show you actual projects and their source code to handle that, because nothing comes off the top of my head. Although data sharing is limited or non existent, it is guaranteed to open a page. Issues that may come up are when opening files instead of webpages (May launch the file manager), or when xdg-open is not installed (Which is extremely rare).
Because "handling the error" is not enough. What if the application requires for example signing in?
Ah, ok. I misread your original comment as saying that the browser doesn't exist.
Most of them usually use xdg-open, and the default browser (If set) will always open
What I'm gathering is that the browser is available to flatpak apps, but needs special way of handling the flatpak environment perhaps.
If you give me some time I can show you actual projects and their source code to handle that
Yes, this will be very helpful, thanks. In the meantime, I'll read up on Flatpak as I get some time.
What I'm gathering is that the browser is available to flatpak apps, but needs special way of handling the flatpak environment perhaps
Kind of, also it's distro-specific sometimes so a few distros may just refuse to make it easier.
I tried deploying the generated test binary under flatpak today, and it seems to open the browser just fine. Can you share a sample repo where this is not working?
The manifest I used was the following (test binary would be random in name):
app-id: in.rootnet.webbrowser
runtime: org.freedesktop.Platform
runtime-version: '22.08'
sdk: org.freedesktop.Sdk
command: /app/bin/webb
modules:
- name: webbrowser
buildsystem: simple
build-commands:
- install -D target/debug/deps/test_unix-06e5c2910415d159 /app/bin/webb
sources:
- type: dir
path: .For me, it doesn't work with my own application and a test one I deployed later to investigate. This is the error I get:
Unable to open webpage 'https://github.com/': No valid browsers detected. You can specify one in BROWSERS environment variable
What permissions do you have? For me, this is my finish-args:
"--share=ipc",
"--socket=x11",
"--socket=wayland",
"--device=all",
"--filesystem=host"ipc is for X11 and Wayland to work, device is just for game controllers and the most important part is --filesystem=host, which basically gives access to the host system.
But, as the documentation says, some directories (Which is probably where a browser would be placed) are blacklisted by default and nothing can be done about it.
If it helps, I run elementaryOS 7.0.
Noted. I'm doing this on Ubuntu, but let me see if I can install Elementary, or play around sufficiently with Flatpak to replicate this issue.
Yep, works flawlessly. Should I report this behavior upstream?
Great, thanks for checking & for the report. I'll make a release of this soon.
Should I report this behavior upstream?
No, the issue isn't with Flatpak, so you don't have to report this upstream.
FYI, this is now out as v0.8.9. Thanks for the report & helping expand coverage.