You can use /etc/apt/preferences
to specify which versions you want on a per-package basis.
To have the latest iceweasel version, use (at your own risk) the following configuration files:
/etc/apt/preferences
Package: iceweasel
Pin: release a=experimental
Pin-Priority: 1000
Package: *
Pin: release a=testing
Pin-Priority: 500
Package: *
Pin: release a=unstable
Pin-Priority: 400
Package: *
Pin: release a=experimental
Pin-Priority: 300
/etc/apt/source.list
deb http://http.debian.net/debian testing main contrib non-free
deb http://security.debian.org/ testing/updates main
deb http://http.debian.net/debian unstable main contrib non-free
deb http://http.debian.net/debian experimental main contrib
But beware the the apt_preferences(5) manpage warns
Packages included in a specific release aren't tested in (and therefore don't always work as expected in) older or newer releases, or together with other packages from different releases. You have been warned.
There doesn't seem to much motivation to implement some EWMH support in Firefox nor in Chrome, even though this would get the restoration to workspace issue resolved with a large number of desktops. A bug has been open for Firefox since 2007 and one for Chrome since 2009.
What you can do outside of Firefox and Chrome, if the active TABs in different browser windows point to different URLs, is to use tendency that different URLs usually have different titles associated with the pages and hence with the window in which they are displayed.
Starting with that idea you can use the output of wmctrl -l -G -p
which provides you with
- window id
- workspace number
- process id
- x,y position of window
- width and height of window
- machine name
- window title (if any)
for each window. Given a process id PID you can see where the link /proc/PID/exe
points to and filter out non-browser windows. For the browser related windows, save at least the window title and workspace number (possible also the browser type and all the other information).
After a browser (re-)start, when all the windows are restored, but on in one workspace, use the saved data to lookup the new window id, WID, associated with a specific title and push it to the retrieved related workspace with wmctrl -i -r WID -t workspacenumber
.
If you don't want to implement the above yourself (it is mostly text processing and a symlink lookup) in your shell or scripting language of choice, you can download a program that does all this for you (and a bit more). Or you can install it from PyPI using:
sudo pip install ruamel.bws
after which the bws
command should be available with options to save
(multiple saves are kept, 10 by default), list
(show the saved dates with number of windows saved), or restore
(by default the latest saved info).
Best Answer
Background
If you just want the solution, you can skip this part. But for the curious, I'll explain the problems we face:
$XDG_RUNTIME_DIR/kpxc_server
for applications to listen too.keepassxc-proxy
is started – via native messaging – by the browser (triggered by the add-onkeepassxc-browser@keepassxc.org
, i.e. KeePassXC-Browser) and tries to listen on that socket to find messages.flatpak run
, i.e. Firefox can now run aSo we could solve that by making wrapper scripts and using flatpak-spawn to let Firefox escape it's sandbox. However, seeing how lovely and quite securley the Firefox sandbox is already built, I would not dare to destroy that security for such a feature. After all, from a security POV you could then also just install Firefox on the host, yet again. So glad news ahead: This solution preserves all sandboxes and security aspects!
However, even if we've solved the fact of Firefox having to run the proxy, there are more problems. To spoiler, this are the main points we need to solve:
Current workaround
v1.2
Tested with: Fedora 32,
org.mozilla.firefox
v75 from flathub,org.keepassxc.KeePassXC
v2.5.4 from flathubStarting keepassxc-proxy by Firefox
keepassxc-proxy
as a binary, because we want to have it run inside of the Firefox flatpak. Good for us: it has not many depenencies and is available as a stand-alone application.cargo build --release
)../target/release
. Thekeepassxc-proxy
binary, version211ae91
, compiled with rustc 1.43.0 (the current stable in Fedora 32) for x86_64 (and if it helps and you wanna know more that.rustc_info.json
). And altghough Rust is not (yet) totally reproducibly compiling I did got the same bit-by-bit result on two machines with Fedora 32. The SHA-256 hash isc5c4c6c011a4d64f7e4dd6c444dcc70bee74d23ffb28c9b65f7ff6d89a8f86ea
. So if you are in a risky mood, you can just download my keepassxc-proxy binary here. (hosted by GitHub ;P)~/.var/app/org.mozilla.firefox/.mozilla/native-messaging-hosts
. Actually, thenative-messaging-hosts
likely does not exist yet, so do create it.org.keepassxc.keepassxc_browser.json
in there, and paste in the following content: Note that only absolute paths work (I guess), so replaceREPLACE_WITH_USERNAME
with your$USER
name, so that the paths leads to it's own working dir.keepassxc-proxy
in the same dir. Obviously, you could use any other path there, but this was the first one that is obviously accessible by Firefox and you have everything in one place. (If you have better suggestions, feel free to let me know.)Note: Remember to make it executable (
chmod +x
) if it is not, already.Allowing Firefox to access the socket
KeePassXC, by default, creates it's socket in
$XDG_RUNTIME_DIR/kpxc_server
. So this is what we need to give the Firefox flatpak access to (read-only is obviously enough).Fortunately, this is easy. Just run:
Hooray!: For those, who install KeePassXC on the host (without any sandbox/flatpak), this is enough. Start KeePassXC and then Firefox and it should be able to connect. :tada: Please note the "existing problems" section at the bottom, though.
Continue, if you also want to run KeePassXC in a flatpak.
Exposing the UNIX socket from the KeePassXC flatpak
Note: Again skip to the bullet point (point 1) below, if you don't wanna know the technical background.
The flatpaked KeePassXC from Flathub creates it's Unix socket in the location flatpaks should do so, in
$XDG_RUNTIME_DIR/app/org.keepassxc.KeePassXC/kpxc_server
. (If it would use$XDG_RUNTIME_DIR
directly like the "native" KeePassXC, it would only exist in the sandbox.)As we know, the usual keepassxc-proxy expects the file at
$XDG_RUNTIME_DIR/kpxc_server
. To solve this, we just create a symbolic link. As you can verify, this actually solves our problem. For some very strange reason, the Flatpak sandbox now allows Firefox (and all other flatpaks! Just FYI, be aware of that.) to see that UNIX socket file. As it should turn out later, this does not work when you move that symbolic link anywhere else (even another file name already prevents it from working – I've tried a lot of things.).However,
$XDG_RUNTIME_DIR
is usually deleted at shutdown. So we need to recreate it at startup/user login. Good for us there, is already a tool for that. (you could also mangle with shell scripts in your autostart of course, but that is ugly.) That's why we make use of systemd-tmpfiles. (The man page for tmpfiles.d is more useful for us actually.)~/.local/share/user-tmpfiles.d
. Again, there is a high chance theuser-tmpfiles.d
dir does not exist yet. If so… well… you know what to do…This is basically a config file for
systemd-tmpfiles
that says it to create that symbolic link for the user.systemd-tmpfiles
can apply the changes and create the config file. (Alternatively, you can also manually runsystemd-tmpfiles --user --create
to apply the changes.)Hooray!: Afterwards start the KeePassXC flatpak and then Firefox and it should be able to connect. :tada:
Please note the "existing problems" section below.
Existing problems
$XDG_RUNTIME_DIR/kpxc_server
file, if the file (respectively it's symbolic link target) does not exist yet. In practise, this results in one big disadvantage: You always need to start KeePassXC before Firefox.flatpak run org.keepassxc.KeePassXC
) may not work. Delete the symbolic link again to make this work.Debugging tips
about:debugging
to access add-on internals.keepassxc-browser@keepassxc.org
is the add-on ID. It actually also logs failed attempts. Note there are different results (logs and visibly) when it cannot start the proxy vs when it can start the proxy, but no connection suceeds (because the UNIX socket is not there, e.g.)flatpak run --command=/bin/sh org.mozilla.firefox
.cat
it and you'll see a strange error thatcat
cannot find a resourceThings I've tried
Things that do not work: Preserved for future solutions and better™ workarounds.
$XDG_RUNTIME_DIR/app
are highly sandboxed, even with flatpak overrides I could not get the Firefox flatpak to read the content of the../org.keepassxc.KeePassXC
dir. Even with crazy symbolic links in it's own dir. (Do try it though, maybe you'll make it! At least you'll learn something. :wink:.)Final notes
That took quite some time to figure it out.
I do try to continue improving this workaround and find solutions in this GitHub issue. It's best to follow there, if you are interested.
I've cross-posted this question and answer in the Fedora community and in the Flathub forum.