Open Bug 1462888 Opened 4 years ago Updated 2 months ago

Flareget addon not working on firefox.snap

Categories

(WebExtensions :: Developer Outreach, defect, P5)

60 Branch
defect

Tracking

(Not tracked)

UNCONFIRMED

People

(Reporter: dannyalculete, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: triaged)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Build ID: 20180503143129

Steps to reproduce:

Installed flareget from https://flareget.com/ and after installed flareget addon


Actual results:

it doesn't handle downloads (nothing happens)


Expected results:

Should handle downloads, it works on deb version
I assume you installed the deb package from http://flareget.com/download.html ?
That package installs the following files on the host:

    /usr/lib/mozilla/native-messaging-hosts/com.flareget.flareget.json
    /usr/bin/flareget-chrome-host

The firefox snap is confined and won't look for native messaging hosts on the host system. Not sure whether it will look for them somewhere under $HOME/snap/firefox/.
Is there any possible workaround?
I will assign a component to this issue, maybe someone with more experience can help you with a workaround.
Component: Untriaged → Add-ons Manager
Product: Firefox → Toolkit
If the firefox snap looks for native messaging hosts somewhere in $HOME (to be confirmed, and if so, where?), then one could probably install com.flareget.flareget.json there, install the flareget-chrome-host executable somewhere the snap can see it (under $SNAP_USER_DATA or $SNAP_COMMON), and modify the path to it in the json manifest.

This needs to be tested and confirmed.
I don't think there's much we can do from the browser side here if the extension mentioned in comment 0 puts the native application in a place on the filesystem that is inaccessible to a snap-packaged firefox.  Mike, can you correct me if I'm wrong and there's something we can do when packaging as snap (or forward the request).  Otherwise, I think you'll have to ask the developer of this extension / native app to follow the suggestion in comment 4.  Moving this bug to Tech Evangelism for that.
Component: Add-ons Manager → Add-ons
Flags: needinfo?(mozilla)
Product: Toolkit → Tech Evangelism
Version: 60 Branch → Firefox 60
I guess the question is where do extensions look for native messaging hosts files and is there something we can do in the snap to map those to a directory outside the snap. I know we've done that with other things (downloads).
Flags: needinfo?(mozilla) → needinfo?(jlorenzo)
Possible locations for native messaging manifests are documented at:
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Native_manifests#Manifest_location
I manage flareget development. The workaround proposed in comment 4 should work.

If the location of the manifest file for firefox-snap is agreed upon, and documented in 

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Native_manifests#Manifest_location

will update the deb package accordingly. Can someone confirm the location where Firefox snap would look for the manifest json?
Per comment 4 and [1], I think this location:
> ~/.mozilla/native-messaging-hosts/<name>.json
should work. What do you all think? 

[1] https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Native_manifests#Manifest_location
Flags: needinfo?(jlorenzo)
I copied com.flareget.flareget.json to ~/snap/firefox/common/.mozilla/native-messaging-hosts/, and I modified its path entry to point to ~/snap/firefox/current/.local/bin/flareget-chrome-host, which I copied in that location.

Flareget doesn't seem to be working though. How can I check whether firefox sees it?

@adnan.kamili: snaps are not permitted to see the host filesystem, all they see is a subset of the user's home directory, so the addon will have to be installed there (somewhere under ~/snap/firefox), and a deb package is not the right tool for installing files in the user's home directory.
First of all, make sure that the flareget-chrome-host is running, when you start firefox, you can check that in the processes list. If ~/snap/firefox/current/.local/bin/flareget-chrome-host location works, flareget-chrome-host should appear in the processes list.

flareget-chrome-host if running invokes flareget with the download url. The native host invokes flareget using:

QProcess::startDetached("flareget",args);

The above code assumes that flareget is installed in /usr/bin or any other path which is in the PATH env variable.
I am not seeing flareget-chrome-host running after starting firefox, and no associated denials in journalctl either.

  $ grep path /home/osomon/snap/firefox/common/.mozilla/native-messaging-hosts/com.flareget.flareget.json 
    "path": "/home/osomon/snap/firefox/current/.local/bin/flareget-chrome-host",

  $ ls -lh /home/osomon/snap/firefox/current/.local/bin/flareget-chrome-host
  -rwxr-xr-x 1 osomon osomon 17K mai   24 11:26 /home/osomon/snap/firefox/current/.local/bin/flareget-chrome-host

I suspect the snap isn't really looking for the manifest in $HOME/snap/firefox/common/.mozilla/native-messaging-hosts.

@jlorenzo: how can I debug that? Is there a way to get logs for the lookup of extensions at startup?

I am trying to get Flareget to work with Firefox as well under Ubuntu 16.04. Has anyone come up with a fix for this yet ?

I have so far figured out 2 alternative workarounds.

workaround 1

install the "Download with FlashGet" addon. This addon will interupt the built in download manager and open an external program of your choice. In the "executable" field, put in "flareget".

for the command line arguments I am using this

"[URL]" -o "[FILENAME]" (I don't think I need to add the filename parameter there, I haven't tested without it.)

The problem with this workaround is you have to select the directory to save as 2 times because it does only interupts the default download manager after you choose the directory to save to first, and then you can't send the options chosen to flareget, so you have to choose the download directory again in flareget (annoying), which is why I use workaround 2 mostly.

workaround 2

install the "open with" addon for firefox. This adds a "open with" option to the context menus. You can add external programs to open URL's with. In the open with addon options, add "flareget" to the programs list.

One downside is it does not interupt firefox's "save image as", or "save page as", which opens firefox download manager save as dialog (choose directory). So I use workaround 1 also.

I wish there was a way to edit firefox's context menus (like menu editor addon or menu wizard addon used to do), so that I could remove "save page as" and "save image as" from context menus, and then just use the open with addon to handle downloads.

pain in the butt, but I almost have it beat.

If only the Flareget addon worked in Linux I wouldn't have to do all of this.
the "Open with" addon is a bit tricky as it requires a local script in your home directory for it to run.

The "menu editor" and "menu wizard" addon no longer work for Firefox, so you can't 100% replace firefox's default download manager from the menus.

"open with flashget" addon works (if you put flareget as the executable) but when you download a file you are asked to choose your download to directory twice (one by firefox and one by flareget)

My goal is to entirely replace the firefox download manager with Flareget. Does anyone else have any suggestions ?

@lsemple: this bug report is specific to the firefox snap package. Are you using firefox installed from the snap, or from the official ubuntu repositories as a deb package?

Component: Add-ons → General
Product: Tech Evangelism → WebExtensions

Marking this as P5 to remove it from our triage; until/if it turns out to be a bug about Firefox, let's re-visit (or close, if resolved on the Flareget side).

Priority: -- → P5
Component: General → Developer Outreach
Whiteboard: triaged
Version: Firefox 60 → 60 Branch
Blocks: snap
You need to log in before you can comment on or make changes to this bug.