gyng / save-in

WebExtension for saving media, links, or selections into user-defined directories
MIT License
208 stars 26 forks source link

Symlink tweak to save outside Downloads folder doesn't work in Firefox Flatpak version #185

Closed LukasThyWalls closed 2 years ago

LukasThyWalls commented 2 years ago

Hello.

Disclaimer:

I think this is an issue with Flatpak itself and not with Firefox or Save-In addon, but maybe I'm doing something wrong, although I don't think is the case, and I want to gather all information I can to put it in the Flatpak issue tracker and confirm this is not working for other people too, or maybe this is something known that is discussed somewhere, but i didn't found yet.

Summary:

Simply the known symlink tweak to save outside the Downloads folder with Save-In doesn't work in the Flatpak version. I had it working with the Snap version in the same computer, and for sure it works in the Windows version in other one.

Explanation:

I have a hidden folder (using .hidden file) in Downloads called "FirefoxWebEx", with inside two symlinks Desktop and USBDisk. Desktop goes to /home//Desktop/ and Disk goes to /media//USBDisk/Files_ which is a USB Disk, with some folders inside (one of them "Downloads"), making the symlink available only when is plugged in. Also i made a folder called "Test" only for testing this.

Both symlinks works in the file explorer, Dolphin (Obviously the USB Disk one works when the USB Disk is plugged and not when it isn't) so the symlinks are right configured working.

In Save-In, i have these paths configured:

Firefox_WebEx/USBDisk/Files/Downloads // symlink 
Firefox_WebEx/Desktop // symlink
. // (alias: Downloads)
---
Firefox_WebEx // parent folder
Firefox_WebEx/Test // folder

Like I said, with the Firefox Snap version, I had no issues with this configuration. However, using the Firefox Flatpak version both, symlinks doesn't work, but everything else does.

Also I tested to "Save as" with Firefox using the save path throw the symlinks, and they work.

Questions:

Thanks!!

gyng commented 2 years ago

Is there a way to show a more specific error or response to see what's the issue? I looked it to the developer console, but I didn't see any error or anything

You'll have to check the extension's developer console (instructions).

FILE_FAILED

Unfortunately FF doesn't have good error messages for failed downloads. I don't know if you'll get better error logs from the developer console.

I haven't tried it yet, but a bindmount (mount --bind) could help.

Martii commented 2 years ago

FWIIW I've also seen this issue in the snap package.

LukasThyWalls commented 2 years ago

FWIIW I've also seen this issue in the snap package.

I was using the Firefox Snap package for months with Save In and the symlinks workaround and i haven't had any issues. It was just yesterday changing it to the Flatpak when i saw it. Maybe is something else there, but that's why i'm asking here first.

If you can give more information it could be useful to see where can be the issue.

You'll have to check the extension's developer console (instructions).

I did that, and only found an error that shows every time i use Save In, but in successful and failed downloads, doesn't matter:

Uncaught (in promise) Error: Could not establish connection. Receiving end does not exist.
    downloaded moz-extension://c5063e81-91a3-4158-ba2e-b216886ea124/src/messaging.js:7
                                                                                           messaging.js:7:23

There are other messages (not errors): from download.js (with all the info for the download) and two from notifications.js (the notification display), but all of them appear too in all tries, whatever are successful or failed.

Maybe somewhere there there is some information but yet i didn't find it...

I haven't tried it yet, but a bindmount (mount --bind) could help.

I tried that. It works. For the Desktop path works exactly the same as the symlink, BUT there is an issue with the USB Disk one: They need the USB Disk be inserted all the time, you can't unplug securely the USB because the path is mounted and the OS doesn't allow to unplug it. You need to create it with the USB mounted and you need to umount it to unplug the USB later. With the symlink in the Snap package you don't need to to this, because the symlink doesn't point to anything, if fails the download with the USB unplugged, but with the USB plugged and mounted the symlink works and the download is successful.


Maybe i should be doing other thing: create a profile to test this alone, maybe i brought some configuration from the old profile (i copied where the Firefox snap profiles are to where the Firefox Flatpak profiles should be to make it work again).

EDIT:

I tested everything with a clean profile and the behaviour is the same. However, I saw other error message debugging Save In when it tries to download to the symlink path to the USB Disk (and there isn't a notification):

Uncaught (in promise) Error: An unexpected error occurred (unknown module)
    apply self-hosted:2669
    applySafeWithoutClone resource://gre/modules/ExtensionCommon.jsm:704
    wrapPromise resource://gre/modules/ExtensionCommon.jsm:952

What means? I don't know...

Thanks!

LukasThyWalls commented 2 years ago

Hello.

After posting in the Flatpak issue tracker, the issue is related to the permission isolation of the Flatpak package. You need to specify in the Firefox Flatpak configuration (I used Flatseal to make it easy) the paths you need to access outside the Downloads folder, including the ones you go throw the symlinks (You can also allow to access to all filesystem, but doesn't seem the best idea). Is explained here https://github.com/flatpak/flatpak/issues/4994#issuecomment-1185796543 .

It's funny, because the symlinks workaround is made to "trick" Firefox, but in this case you need to "reveal" the trick to the Flatpak engine to keep tricking Firefox. I don't know if some flexibility in the future with the webextensions API downloads folder could help to improve this (Firefox notifying Flatpak what folders need to reach), but at the moment doesn't seem that can be done anything more than this.

Maybe can be detailed this detail with the flatpak package where are explained the symlink workaround, only to be warned in that case.

I will keep open the issue only to make @gyng aware of this, but can be closed now.

gyng commented 2 years ago

Glad you figured this out!