Extension development for beta
axel.grude at gmail.com
Mon Oct 29 12:42:04 UTC 2018
Eyal - I hear you.
That's why I am still hoping we can do a "guided conversion" in a public google
hangout, just to show that it is possible.
I think the biggest thing is converting to the new build process and then dealing with
individual XPCOM breakages. AS far as I understand overlays still work, as long as you
overlay the correct xul file (as Thunderbird itself won't have overlays). So it
shouldn't be impossible.
when you said "without preferences." - did you mean no settings dialog, because of
broken xul dialogs? That one is very easy to fix and even backwards compatible (one
line of code).
*Axel Grude <mailto:axel.grude at gmail.com>*
Music Production and Composition
Thunderbird Add-ons Developer (QuickFolders
QuickPasswords <https://addons.mozilla.org/firefox/addon/quickpasswords/>, Zombie Keys
Visit my YouTube Channel <https://www.youtube.com/c/thunderbirddaily> for email
productivity tips Get Thunderbird!
> *Subject:*Re: Extension development for beta
> *From:*Eyal Rozenberg <eyalroz at technion.ac.il>
> *To:*Thunderbird Planning (Moderated) <tb-planning at mozilla.org>; Geoff Lankow
> <geoff at thunderbird.net>
> *Sent: *Monday, 10/29/2018 10:43 GMT ST +0000 [Week 44]
> Without discounting the significance of this problem, I believe there's
> a larger one. I'll generalize it from my personal experience because
> everyone knows a biased sample of one person is good enough :-P
> Anyway, I'm speaking as an extension (only) developer, of a
> non-bootstrapped non-WebExtensions extension . I've been chasing the
> moving target of what I need to rewrite in my extension for a while now.
> But, frankly, I'm tired of doing that. I published a (clearly-marked)
> beta version targeted at TB 60, which works, but without preferences.
> Well - I don't feel motivated to fix that. Seeing that there's more
> breakage to handle for v63, and hearing now that I might need to address
> v60 and v63 issues, my thoughts are: "Why would I even want to fix this?
> I mean, next month there's going to be v64 alpha, or what-not, and
> something else will break or be taken away, and I'll need to chuck my
> hacks so for for yet another hack. I'm tired of this! Also, why do I
> individually have to adapt my old preferences dialog to Chrome-style
> extensions? Why don't _they_ adapt to _me_? I'm pretty sure the
> transition can be automatized. Eh, f*** it, let them just wake me up
> when things are stable once more and I'll attend to my extension then."
> I tend to believe that similar, or worse, sentiments are shared by most
> extension developers - or at least those who are mostly maintaining
> rather than actively developing.
>  : Remove duplicate messages (alternate)
> On 29/10/2018 10:37, Geoff Lankow wrote:
> > We have a problem. Actually, a series of problems.
> > Firstly. For an extension to run on ESR60, it must be:
> > 1. an overlay extension with an install.rdf manifest, or
> > 2. a bootstrapped extension with an install.rdf manifest, or
> > 3. a WebExtension with a manifest.json
> > C is very rare, because ESR60 supports so few of the WebExtension APIs.
> > B isn't an issue yet but will become one soon, so I'm ignoring it for
> > this conversation.
> > For A to run on beta, it must have a manifest.json and /NOT/ have an
> > install.rdf manifest. (At this point it's technically a WebExtension and
> > we're just lying to the extensions back-end about what it's actually doing.)
> > This leads to the second problem: it's impossible to have an extension
> > that both has an install.rdf and doesn't have an install.rdf. Therefore
> > an extension developer cannot make an extension that can run on both
> > ESR60 and beta.
> > (Side note: I've been trying to make a backport for ESR that can run an
> > updated legacy extension, but I'm uncomfortable with the size of the
> > changes.)
> > The extension developer /could/ make a separate version of their
> > extension which is only for beta. Given the other big changes in the
> > platform, that's probably the best option anyway, but that takes us to
> > problem three: they can't host the beta version of their extension on
> > ATN, because ATN no longer has support for development channel
> > extensions. I /think/ there's an ugly workaround involving uploading
> > versions out-of-order such that the ESR version is the one displayed,
> > but I really don't think developers should have to deal with that, or
> > would bother. They could also self-host the extension but I think most
> > wouldn't want to do that.
> > We're left with a bunch of not-very-nice options, as well as all the
> > other issues facing extension developers, which I think is just going to
> > put a lot of developers off altogether, and we'll lose a large fraction
> > of our extensions.
> > GL
> > _______________________________________________
> > tb-planning mailing list
> > tb-planning at mozilla.org
> > https://mail.mozilla.org/listinfo/tb-planning
> tb-planning mailing list
> tb-planning at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 846 bytes
Desc: not available
More information about the tb-planning