app execution and io/streams

RESOLVED WONTFIX

Status

()

Toolkit
WebExtensions: Untriaged
RESOLVED WONTFIX
a year ago
6 months ago

People

(Reporter: mixedpuppy, Unassigned)

Tracking

49 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

a year ago
VDH uses external apps for video and audio encoding, e.g. libav/FFMpeg.  It needs a way to launch/kill the external app and use i/o streams.
Is something needed beyond what is already supported in native messaging?
This is the kind of thing that should be handled via native messaging or asm.js workers. If for some reason they need to stream data to/from the native app directly rather than having it handle the network IO and JSON overhead is too much, then it may be a case for bug 1268594.
Mid-aired :/
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → WONTFIX

Comment 4

a year ago
Am i correct to assume using native messaging implies modifying the external application so that it handles the native messaging protocol ? This is doable but for now users install standard builds of libav or ffmpeg on Mac and Linux. We provide our own build of libav on Windows though.

I'm not sure about asm.js. Do you mean recompiling libav/ffmpeg and the required libraries to produce javascript code ? This sounds like an adventure :)

Comment 5

a year ago
By the way, in the case of VDH, there is no particular need for performance (little traffic between the app and the addon though stdin/stdout) so bug 1268594 is not an issue.
(In reply to Michel Gutierrez from comment #4)
> Am i correct to assume using native messaging implies modifying the external
> application so that it handles the native messaging protocol ? This is
> doable but for now users install standard builds of libav or ffmpeg on Mac
> and Linux. We provide our own build of libav on Windows though.

I'm not sure I understand the question, if it is "does the external application have to implement the native messaging protocol in order to use native messaging?" then the answer is yes.

Comment 7

a year ago
That was my question indeed, thanks :)

I presume there must be generic native apps that talk to the add-on on one side and launch the original application on the other side, bridging stdin and stdout with native messages. So i don't understand clearly the level of security native messaging brings compared to the legacy nsIProcess interface / sdk/system/child_process SDK module. It sounds to me like it just makes things more complicated.
(Reporter)

Comment 8

a year ago
> I'm not sure about asm.js. Do you mean recompiling libav/ffmpeg and the
> required libraries to produce javascript code ? This sounds like an
> adventure :)

I did find this: 

https://bgrins.github.io/videoconverter.js/
https://github.com/muaz-khan/Ffmpeg.js

Apparently it's not unheard of to recompile Ffmpeg to asm.js.  Whether that would be sufficient for your case is another question.  Given the requirement for installing an app.json file for nativemessaging, if it were me I'd give asm.js a look.

Comment 9

a year ago
I did not worry much about ffmpeg/libav itself but more about the libraries that are required to perform the job VDH users need. Some time ago, it took me a full week to put on a set of scripts to compile a proper libav with a reasonable set of libraries (https://github.com/mi-g/libav-xbuild2win). Much sweat and it was a native compile (well cross-compile from Linux to Windows). So i'm not too optimistic. There could be licensing issues too. But, yes, it's worth having a look.

At this point, native messaging apps looks like the most promising option.
(In reply to Michel Gutierrez from comment #7)
> I presume there must be generic native apps that talk to the add-on on one
> side and launch the original application on the other side, bridging stdin
> and stdout with native messages. So i don't understand clearly the level of
> security native messaging brings compared to the legacy nsIProcess interface
> / sdk/system/child_process SDK module. It sounds to me like it just makes
> things more complicated.

The native messaging protocol doesn't add security per se, it exists to support the message passing API that is used throughout webextensions, and which is much simpler than an arbitrary streams based interface.
The security difference between webextensions native messaging and nsIProcess or the sdk child_process module is that with webextensions, native processes must be explicitly granted permission to access individual native applications, they can't just spawn any old executable they can find on the filesystem (in fact extensions don't have direct access to the local filesystem and when using native messaging the location of the native app on the filesystem is never directly exposed to the extension)

Comment 11

a year ago
(In reply to Andrew Swan [:aswan] from comment #10)
> ... they can't just spawn any old executable they can find
> on the filesystem ...

Makes sense, thanks for the explanation.
Duplicate of this bug: 1310435

Comment 13

a year ago
So (copying my question from the duplicate issue),

A possible scenario is 'Open With' type of extension that provides ability to open current page in another browser.
Of course, one can write a simple wrapper, whose sole purpose is to launch an application, and communicate with this wrapper via native messaging. But this means writing the native wrapper and the native installer for each operating system. All just to be able to do something as simple as 'runProcess("iexplore.exe")'

Is this your proposed solution?

In addition, what is wrong with this kind of approach?

A simple idea would be, each time when an extension tries to launch an executable, present the user with a window saying "Extension FooBar tries to run 'c:\Program Files\Internet Explorer\iexplore.exe'. Allow this? (Yes) (No) [] Remember choice".
Duplicate of this bug: 1373926
Comment hidden (advocacy)
You need to log in before you can comment on or make changes to this bug.