[Suggestion] Snap support

[EPadronU]

The current state of things

Right now the extension is looking for the bridge under /opt/fx_cast/ but inside a snap, Firefox is unable to read such directory.

A possible approach

Under Linux, when /opt/fx_cast/bridge fails to be found, could it be possible to look for the bridge under a user-owned directory (like $HOME, for example)? Maybe a symlink could make the trick in such case.

Another possible approach

Give the user the option to indicate the path under which the bridge is located.

Note

I'm not by any means a Linux nor a Firefox extensions expert. But I'd like to try fx_cast without giving away the option of using Firefox as a snap (I like it to has limited access to my system).

[hensm]

The path to the bridge is hardcoded in the path key of the native messaging manifest. It’s set during the build and can’t be specified at runtime.

I don’t know much about snaps, can they actually execute binaries under $HOME? If so, it would be possible to provide two manifests, allowing for a backup path.

I suppose the only way to allow user-editable paths would be to use an existing native messaging connection to generate a different manifest with that specified path, but I’m pretty sure that’s not what you’re looking for.

[rimrul]

I don’t know much about snaps, can they actually execute binaries under $HOME?

I did some digging, and it seem like snaps with strict confinement (how firefox is packaged) can't execute external binaries. It seems like people could explicitly install their firefox snap as classic or maybe devmode, but those confinement modes seem to undermine the sandboxing.

It seems like we could only try to contact a running process. (maybe, if we had the bridge running as a daemon?)

[EPadronU]

It seems like we could only try to contact a running process. (maybe, if we had the bridge running as a daemon?)

I think it's worth trying and finding out. I can help with the testing.

[hensm]

Firefox’s native messaging spawns new processes, so we can’t contact existing processes that way.

Can a snap with strict confinement establish a local WebSocket (or HTTP) connection? We could have the bridge run as a daemon and provide the API that way instead. Probably the cleanest way to do that, without changing the existing bridge too much, would be a separate daemon process that mimics how Firefox spawns native messaging processes.

[rimrul]

Firefox’s native messaging spawns new processes, so cant contact existing processes that way.

Yes, I just looked at the Native Messaging API and that was my conclusion as well.

Can a snap with strict confinement establish a local WebSocket (or HTTP) connection?

There's at least permissions for establishing network connections and listening for incoming network connections. The firefox snap should at least have the first of those two.

a separate daemon process that mimics how Firefox spawns native messaging processes.

That might work. See also this thread.

[hensm]

Just tested and WebSocket connections work with the snap, so it's viable.

Originally, I was thinking a separate binary, but because of the way the Linux build is packaged, that just complicates things if it's going to be done in node.

So, instead I'm thinking just a --daemon option on the bridge binary which can be referenced from a systemd service unit file that starts it in daemon mode. That starts a WebSocket server that spawns a regular bridge. Messages from the extension, are encoded and then sent to the bridge (stdin). Responses back from the bridge (stdout) are decoded and forwarded back to the extension.

On the extension side, probably wrapping the browser.runtime.connectNative/browser.runtime.sendNativeMessage APIs in a new module and handling connection failures by attempting a WebSocket client connection and using that transparently.

[hensm]

Some progress in #60

Just the app-side. Doesn't work, but unless I'm missing something obvious, I think there's a pkg issue with spawning child processes, because it does work outside of the bridge binary.

[hensm]

[hensm]

v0.0.4