1310317 - app execution and io/streams

Status: RESOLVED WONTFIX

(WebExtensions :: Untriaged, defect)

Description

[Shane Caraveo (:mixedpuppy)]

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.

Comment 1

[Andrew Swan [:aswan]]

Is something needed beyond what is already supported in native messaging?

Comment 2

[Kris Maglione [:kmag]]

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.

Comment 3

[Kris Maglione [:kmag]]

Mid-aired :/

Comment 4

[Michel Gutierrez]

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

[Michel Gutierrez]

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.

Comment 6

[Andrew Swan [:aswan]]

(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

[Michel Gutierrez]

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.

Comment 8

[Shane Caraveo (:mixedpuppy)]

> 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

[Michel Gutierrez]

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.

Comment 10

[Andrew Swan [:aswan]]

(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

[Michel Gutierrez]

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

Comment 13

[slycelot]

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

Comment 15

[tinjon]

(In reply to slycelot from comment #13)
> 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".

I was also hoping for such an option as well, but alas.

Forcing developers to create a completely separate app, that must be maintained for each operating system, have a place to live on the internet (github?), have a process and supporting documentation for how to install and uninstall, dedicate support time to issues regarding that program's install and hooking up to firefox etc. etc, "just to launch a process" is both developer and user hostile.

I've resigned myself to the fact that Firefox will simply be a different UI for Google Chrome when FF57 drops, and that everything that once made firefox relevant as a browser for distinguising addons will be no more.

There's no way I'm going to carry the entire maintenance burden of a _third party app_, with all that such entails, just to be able to launch a process. Instead I'll rather let my addon initiatives die a quite death than subject myself and my users to this travesty.