WebExtension : a (current ? future ?) way to deal with .my_own_extension files ?

[Dominique De Vito]

Hi,

Not quite sure if this is the right forum to post this but...

[[ I tend to think current addon tech does not able to implement my use
case below. That's why - naively, sorry - I propose a new type of addon if
needed, while thinking it could be useful for others too.
Otherwise, if coming WebExtension is able to fulfill my use case, I would
be glad to read how. ]]

I have a use case that may be worthwhile for an addon, but I am quite sure
current addon tech does not support it, but I let you get the picture first.

- Files come in my mail reader as attached files, with name like
xxx.my_own_extension
- if they have an unusual extension, they are still plain text file
- when I click on a file, I want Firefox to be open in order to read a file
xxx.my_own_extension and to do some treatment accordingly (and maybe
calling an external WS if needed, for example, for validation)

This is my use case.

I, first, expected to implement this use case as the following, with an
addon that would do 2 simple things:
1) such addon should define in its configuration that it has to be called
for treating .my_own_extension files
2) and this addon should also define, again in its configuration file, an
url. The content of this url should be loaded when the addon starts and
used to treat the .my_own_extension file content (that content should be
available - I don't know how - as input file from JavaScript scripts).

According to that picture, such addon type is quite simple. From Firefox
configuration point of view, it might be defined with a manifest file like
this:
{
addon-type: "file-extension-handler",
File-extension: ".my_own_extension",
Init-url: "...some url...."
}

I don't think such addons need to sign by Mozilla for the following
reasons:
1) url could be private, for intranet uses
2) but, more importantly, users could be warned to learn about the addon
behaviour when (a) loading the addon, and (b) each time Firefox starts to
deal with a .my_own_extension file (each time if the user does not choose
to click on the button "please, do not warn me anymore").

For such addons to be a reality, we need (AFAIK) few things:
1) create a new addon type, with the kind of manifest I mentioned earlier
2) that Mozilla accepts such addons not to be signed (for the reasons I
mentioned above)
3) a JavaScript function to read the content of an incoming file by the
browser

I think IMHO that, as the "old" world is full of info exchange through file
exchange, with whatever an enterprise could imagine for a file extension,
it may put the browser into the loop. Then a browser could be used to deal
with those files, instead of using a heavy client.

What do you think of this idea/use case/addon type ?

Thanks

Regards,
Dominique

[Jorge Villalobos]

Maybe I'm missing something, but opening a URL or sending an XHR in
response to certain files that you receive in your email should be
easily done with a content script. I don't see why you would need a new
add-on type for this.

As for signing, it's required for all add-ons and I don't think this is
an exception.

Jorge

[Dominique De Vito]

Hi,

There are multiple points.

1) associate .my_extension files with Firefox
AFAIK I can use a matching approach with such a pattern like:
"file://*/*.my_extension" (the "matches" attribute of "content_scripts")

It would be better if this matching between ".my_extension" & Firefox would
go down up to the OS.
AFAIK it's not provided by WebExtension, but I can live without it.

2) have the read content (.my_extension) file available as input, as a
buffer in JavaScript

AFAIK it's not provided by WebExtension
and without such a feature, I don't see how Firefox could deal with
non-HTML files

3) loading some external ressources to deal with .my_extension files

OK, yes, for this part, it's regular WebExtension job to load an external
files.

4) have or not to sign such WebExtension

IMHO with such a limited WebExtension, just loading some external
ressources, and without use of any WebExtension specific API, having to
sign such extension is an overkill.

So, if anyone has an idea about how to implement (2), I would be glad to
read it.

Thanks.

Dominique

> _______________________________________________
> dev-extensions mailing list
> dev-ext...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-extensions
>

[Jorge Villalobos]

What comes to mind is have an external application handle .my_extension
files and open them in Firefox. One the file is opened in a tab, the
content script can take care of it. That would only work if the file is
plain text or some other format Firefox supports.

Jorge

[Dominique De Vito]

> What comes to mind is have an external application handle .my_extension
> files and open them in Firefox. One the file is opened in a tab, the
> content script can take care of it. That would only work if the file is
> plain text or some other format Firefox supports.

Interesting, thanks.

You gave me this idea: the job could be splitted into 2 parts.

*** part 1: one native app doing this:

<xxx.my_extension file> => format conversion => <xxx_my_extension.html> +
open Firefox with <xxx_my_extension.html>

<xxx_my_extension.html> would be a do-nothing html/JS file with the initial
<xxx.my_extension> file content put into a JS array or just a big JS string.

*** part 2: loading the <xxx_my_extension.html> file into Firefox

Loading the external web ressources through a WebExtension, and, first,
read the JS input "buffer" (array or string) as a first step.

Well, that being said:
1) I don't see how not to do a format conversion as Firefox supports only
html (as the single format one could inject into JS behaviour through
WebExtension)
2) I am a bit frustrated that [part 1] has to be a native app (and could
not be done through Firefox), so a heavy app
3) and still, having to sign such [part 2] extension with an _external_
org. Mozilla for just injecting some _internal_ (url) web ressources looks
like awkward to me.

But, again, thanks for the idea.

On second thoughts, if I write [part 1] native/heavy app, I could make the
format conversion, but also inject the external web ressources into
<xxx_my_extension.html>.
Then, no need for [part 2]-WebExtension doing web ressources injection.

So, in the end, let's wrap up:
* I didn't see how to implement my use case with WebExtension only
* if WebExtension alone can't do the job, let's put in a native app to do
part of the job
* but if a native app is used, such app could do all the job, even the job
of WebExtension side, so let's forget about WebExtension

WebExtension KO for my use case, back to native/heavy app: bad luck.

Dominique

[Jorge Villalobos]

Regarding signing, there are ways to disable signing enforcement. For
example, if this is an enterprise setup, you could use ESR and flip the
preference. If it's just for your personal use, you could use Developer
Edition or Nightly and flip the preference. See this for other options:

https://wiki.mozilla.org/Addons/Extension_Signing

As for what the add-on actually does, it's not quite clear to me.
However, if something can be done completely independently from Firefox,
then it probably shouldn't be an add-on. Add-ons are meant to enhance
the browsing experience. Other uses are not really the goal of add-ons
or Firefox.

Maybe Node.js would be a good platform to migrate this tool to. It's
based on similar technologies and should be easy to get started with.

Jorge

[Dominique De Vito]

> Regarding signing, there are ways to disable signing enforcement. For
> example, if this is an enterprise setup, you could use ESR and flip the
> preference. If it's just for your personal use, you could use Developer
> Edition or Nightly and flip the preference. See this for other options:
>
> https://wiki.mozilla.org/Addons/Extension_Signing

yes, I have seen it.

> As for what the add-on actually does, it's not quite clear to me.
> However, if something can be done completely independently from Firefox,
> then it probably shouldn't be an add-on. Add-ons are meant to enhance
> the browsing experience. Other uses are not really the goal of add-ons
> or Firefox.
>
> Maybe Node.js would be a good platform to migrate this tool to. It's
> based on similar technologies and should be easy to get started with.

Well, I see your point.
My answer is yes and no ;-)

I want to replace an heavy app doing 3 things:
1) reading xxx.my_extension __local__ files
2) GUI
3) WS calls

One (now traditional) way is to use web tech.

The old-fashion add-on would be XUL and XPCOM-based add-ons (to build a
native/heavy app, but with web tech!).
And just like Thunderbird could interact with local drives and non-html
formats, such an old-fashion add-on may do the same for Firefox for my use
case.

The new way - I see - is WebExtension.
I know I could do (2) + (3) with Firefox, I was investigating (1) with
WebExtension.

My understanding is that there's not enough bits into WebExtension to deal
with non-text or non-HTML input formats.

Or to do say things differently:
a) I can't use WebExtension to extend the number of supported __input__
formats by Firefox (just like PDF input format is supported through html/js
tech within Firefox) - for me, that's part of enhancing the browsing
experience, as you wrote it
b) there is still some use cases (like dealing with non-text or non-HTML
input formats) where XUL and XPCOM-based add-ons look like mandatory, as
WebExtension is not the answer AFAIU.

Anyway, thanks for your answers.

Dominique

[Dominique De Vito]

Jorge has written:

> Regarding signing, there are ways to disable signing enforcement. For
> example, if this is an enterprise setup, you could use ESR and flip the
> preference. If it's just for your personal use, you could use Developer
> Edition or Nightly and flip the preference. See this for other options:
>
> https://wiki.mozilla.org/Addons/Extension_Signing
>
> As for what the add-on actually does, it's not quite clear to me.
> However, if something can be done completely independently from Firefox,
> then it probably shouldn't be an add-on. Add-ons are meant to enhance
> the browsing experience. Other uses are not really the goal of add-ons
> or Firefox.
>
> Maybe Node.js would be a good platform to migrate this tool to. It's
> based on similar technologies and should be easy to get started with.

Take a look at
https://support.mozilla.org/en-US/kb/applications-panel-set-how-firefox-handles-files

It's written that there is different ways to handle (non-html) files into
Firefox, and one is the plugin way to handle some type of files:
""
* Choose a feature or plugin: If you want a feature or a plugin in Firefox
to handle the type, and one is available, select it from the drop-down menu.
* Choose an application: To choose a local or web application to handle a
type, select the application from the drop-down menu. If you want a local
application that is not in the menu to handle the type, select Use other…
from the drop-down menu and point Firefox to its location.
""

If XUL/XPCOM is really going to disappear, then, IMHO, WebExtension would
need a mechanism to handle those (non-html) files into Firefox.

As far as we have already discussed, I see (AFAIU) there is not such
mechanism today.

Dominique

2016-06-20 18:50 GMT+02:00 Dominique De Vito <ddv3...@gmail.com>:

> > Regarding signing, there are ways to disable signing enforcement. For
> > example, if this is an enterprise setup, you could use ESR and flip the
> > preference. If it's just for your personal use, you could use Developer
> > Edition or Nightly and flip the preference. See this for other options:
> >
> > https://wiki.mozilla.org/Addons/Extension_Signing
>

> yes, I have seen it.
>

> > As for what the add-on actually does, it's not quite clear to me.
> > However, if something can be done completely independently from Firefox,
> > then it probably shouldn't be an add-on. Add-ons are meant to enhance
> > the browsing experience. Other uses are not really the goal of add-ons
> > or Firefox.
> >
> > Maybe Node.js would be a good platform to migrate this tool to. It's
> > based on similar technologies and should be easy to get started with.
>

[Jorge Villalobos]

I suggest you send an email to this list with a proposal for the API:
dev-addons AT mozilla DOT org

Regards,

Jorge

[Dominique De Vito]

Thanks for your support and our discussion.