724276 - Add support to build XPI for other applications

Status: RESOLVED WONTFIX

(Add-on SDK Graveyard :: General, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Right now the cfx command only allows to run and build XPIs for Firefox. There is no way to specify compatibility with other applications.

This kind of feature would be helpful to start experimenting with the support of the SDK for applications like Thunderbird.

I talked with Alex at FOSDEM and a probably good solution will be to add new entries to the package.json file, which then gets put into the install.rdf when building the XPI.

I will try to have a look at it.

Comment 1

[Alexandre Poirot [:ochameau]]

We may have to split the following patch in multiple piece, 
but it highlights a WIP in order to bring back thunderbird support:
  https://github.com/ochameau/addon-sdk/tree/thunderbird
  https://github.com/ochameau/addon-sdk/compare/master...thunderbird

So the thunderbird support is not only about missing targetApplication in XPI.
There is some regressions introduced with the new module loader.

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Alex, you will probably also wanna check bug 560716 which has been closed as wontfix a while ago due to lack of response. We should probably reopen?

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Also we would have to update the RDFUpdate class in rdf.py so we also ship updates for the other applications.

Comment 4

[Alexandre Poirot [:ochameau]]

Attachment: Pull request 341

Here is one way to handle "3rd party applications":
add an "application" attribute in package.json in order to control install.rdf file.

Comment 5

[Alexandre Poirot [:ochameau]]

Matteo, you mentioned during FOSDEM event some concerns about this work as being irrelevant or useless regarding your upcoming work on module metadata. I still don't think it collide, in fact, I think both are complementary.

Comment 6

[Matteo Ferretti [:zer0] [:matteo]]

Alex, I still think it collide: install.rdf will be generated based on the modules compatibility graph, without queries the "packages.json".

Here the module metadata bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=725409

As far as I understood from this bug the purpose is exactly the same, that's why I think they're overlapping.

Comment 7

[Alexandre Poirot [:ochameau]]

As I pointed out in bug 725409 comment 3, mainly on last item.
I'm not convinced that module metadata will properly handle all cases,
so that having a way to override install.rdf may still be usefull
in order to :
 - specify a custom application id, or,
 - go off road and specify custom compatibility ranges,
 - handle edge cases when module metadata isn't precise enough.

So I still think:
1/ something similar will be needed, even, with advanced module metadata feature implemented.
2/ it will unlock multiple people to start hacking with the SDK, now.

Comment 8

[Matteo Ferretti [:zer0] [:matteo]]

I'm not sure why you saying that module metadata can't handle these cases you listed. They actually cover them as well – or, at least, they should be covered: the compatibility graph is made for this purpose.

If you think there is some specific case the compatibility graph and module metadata doesn't cover, then we should modify the module metadata proposal in order to cover it.

I agreed we need to provide this functionality so the community can start hacking with SDK, I was always pushing SDK for Thunderbird. That's because module metadata has a high priority, they have to be defined and landed as soon as possible.

I don't think that land this addition to packages.json and the module metadata immediately after is a good idea: they are designed to do mostly the same, so we could end up in racing condition. Also, developers could be confused: we already land too many things that actually trying to solve same problems, and then we're now spending effort to roll them back, and teaching to the community which one they have to use.

Comment 9

[Wayne Mery (:wsmwk)]

(In reply to Matteo Ferretti [:matteo] [:zer0] from comment #8)
> I agreed we need to provide this functionality so the community can start
> hacking with SDK, I was always pushing SDK for Thunderbird. That's because
> module metadata has a high priority, they have to be defined and landed as
> soon as possible.

Mark, Might some of our Thunderbird addon fans be interested in hacking at this?

And do we have anything specific/important waiting on this - beyond something for the average addon author?  Henrik tells me we need this to have memchaser addon work in Thunderbird. ref: https://github.com/mozilla/memchaser/issues/38

Comment 10

[Matteo Ferretti [:zer0] [:matteo]]

Just to update everyone is interested: I'm completing the bug 725409; I'm hoping to land it in the next days. Then, I'm going to fix this bug.

Comment 11

[Mark Banner (:standard8)]

(In reply to Wayne Mery (:wsmwk) from comment #9)
> (In reply to Matteo Ferretti [:matteo] [:zer0] from comment #8)
> > I agreed we need to provide this functionality so the community can start
> > hacking with SDK, I was always pushing SDK for Thunderbird. That's because
> > module metadata has a high priority, they have to be defined and landed as
> > soon as possible.
> 
> Mark, Might some of our Thunderbird addon fans be interested in hacking at
> this?

Yes, I suspect they might.

> And do we have anything specific/important waiting on this - beyond
> something for the average addon author?

I guess the main things are for someone to take the lead on getting relevant parts of the existing sdk working, and then looking to expand what is necessary.

Comment 12

[Matteo Ferretti [:zer0] [:matteo]]

Mark, Wayne, I'm available for any kind of help you could need to makes SDK modules working on Thunderbird; so let me know in case!

Comment 13

[Szabolcs Hubai (:xabolcs)]

I happily take this bug if it's free, and there is somebody to help me what to implement. :)

Comment 15

[Erik Vold [:erikvold] (please needinfo? me)]

Due to bug 915376, the problem here is flipped, those other applications will have to support Jetpack instead, hopefully they pull from m-c..

We can probably won't fix this now.

Comment 16

[Matteo Ferretti [:zer0] [:matteo]]

So, how it will works, then? I mean if the devs wants to create an add-on that will works for both Firefox and Thunderbird, or Firefox and Fennec, or just Fennec?

Comment 17

[Erik Vold [:erikvold] (please needinfo? me)]

(In reply to Matteo Ferretti [:matteo] [:zer0] from comment #16)
> So, how it will works, then? I mean if the devs wants to create an add-on
> that will works for both Firefox and Thunderbird, or Firefox and Fennec, or
> just Fennec?

Devs will add `{ "engines": { "thunderbird": ">25" } }` to their package.json, and the rest is up to Thunderbird.

Comment 18

[Matteo Ferretti [:zer0] [:matteo]]

Cool thanks, so nothing is changed on that side.
When you mean "up to Thunderbird" it means it has just to pull from m-c, right?

Comment 19

[Matteo Ferretti [:zer0] [:matteo]]

Dave, shall we close this bug then?
Or we should leave it open and leave it depends by the Native Jetpack?
I think we should close it, and maybe open specific bug for those platform that should support jetpack.

Comment 20

[Dave Townsend [:mossop]]

Yeah this is a "going to be fixed by a different approach" bug.