1462888 - Flareget addon not working on firefox.snap

Status: RESOLVED DUPLICATE of bug 1661935

(WebExtensions :: Developer Outreach, defect, P5)

Description

[dannyalculete]

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

Comment 1

[Olivier Tilloy]

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/.

Comment 2

[dannyalculete]

Is there any possible workaround?

Comment 3

[ovidiu boca[:Ovidiu]]

I will assign a component to this issue, maybe someone with more experience can help you with a workaround.

Comment 4

[Olivier Tilloy]

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.

Comment 5

[Andrew Swan [:aswan]]

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.

Comment 6

[Mike Kaply [:mkaply]]

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).

Comment 7

[Andrew Swan [:aswan]]

Possible locations for native messaging manifests are documented at:
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Native_manifests#Manifest_location

Comment 8

[adnan.kamili]

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?

Comment 9

[Johan Lorenzo [:jlorenzo]]

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

Comment 10

[Olivier Tilloy]

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.

Comment 11

[adnan.kamili]

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.

Comment 12

[Olivier Tilloy]

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?

Comment 13

[lsemple]

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.

Comment 14

[lsemple]

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 ?

Comment 15

[Olivier Tilloy]

@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?

Comment 16

[David Durst [:ddurst]]

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).

Comment 17

[:gerard-majax]

Olivier is fixing native messaging on bug 1661935