Open matt-hayden opened 4 months ago
Both Tor and Mullvad beget Browser/.local/share <- /dev/null. Replacing this with a directory is the workaround.
Note that replacing this symlink with a directory may leak on disk the
list of downloaded URLs. The symlink to /dev/null
was added to fix
this issue:
https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/17560
On Arch, the dependencies for Firefox are installed and the choices during that installation were noto-fonts and pipewire-jack. Tor Browser is installed from the Arch Linux torbrowser-launcher package. Mullvad browser is simply dropped into place from the 13.5 tarball.
I'm wondering if the different behavior between Mullvad Browser and Tor Browser can be explained by the different dependencies installed. Are you running Mullvad Browser in the same container as Tor Browser? If not, can you try running it with the same dependencies installed to see if it solves the issue?
Greetings,
Workaround for a problem with containerized Mullvad failing to launch a file dialog.
Expected behavior works on the related Tor browser:
On Mullvad:
What appears when run with
--log
:Both Tor and Mullvad beget Browser/.local/share symlinked to /dev/null. Replacing this with a directory is the workaround.
My environment may matter:
Those browsers are both in the same Arch Linux container, with a variant of Ubuntu as host.
systemd-nspawn was chosen because only a few extra options are needed to permit browsers to play audio.
On Arch, the dependencies for Firefox are installed and the choices during that installation were noto-fonts and pipewire-jack. Tor Browser is installed from the Arch Linux torbrowser-launcher package. Mullvad browser is simply dropped into place from the 13.5 tarball.
Outside of this containerization, Mullvad on the host machine runs fine with Browser/.local/share symlinked to /dev/null.