Closed Bug 1493528 Opened 6 years ago Closed 6 years ago

Thunderbird "legacy" sdk no longer installed since TB 60

Categories

(Thunderbird :: Add-Ons: Extensions API, defect)

Product:
Thunderbird
Component:
Add-Ons: Extensions API
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: wavexx, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 Build ID: 20100101 Steps to reproduce: Built TB 60 in the hopes to update a "legacy" addon that broke in TB 60 and cannot work with WebExtensions yet (since the required APIs are not available). Actual results: Legacy xpcom/typelib utilities are no longer installed/available. This also reflects the state in debian unstable, that no longer ships with a thunderbird-dev package. I could find typelib.py, and the various idl files, but where is the python xpt module required by typelib itself? How am I supposed to fix and rebuild a legacy extension while waiting for the WebExt stuff to be available? I'm waiting for this API to be available: https://bugzilla.mozilla.org/show_bug.cgi?id=1481052 All the legacy and *current* documentation is basically broken. The 52->60 transition guide only lists a few IDL classes that got renamed. That's fine, but how do I build the xpt file now? Should I tell my users to stay with TB 52 until TB 63 supposedly ships? Expected results: I'm really trying hard here, but was changing the IDL classes necessary in TB 60? Could you have waited until all WebExt API were *truly* available before 1) disabling legacy extensions by default 2) changing the existing APIs for the legacy extensions? This broke the existing addon while at the same time preventing me to provide something during the transition period. I've been a TB user for a long time, and I maintained the TB extension since TB 13, but this is really testing my patience.
(a lot to unpack here - I'm just taking a stab at component)
Component: Untriaged → Add-Ons: Extensions API
Who is building the thunderbird-dev package? And what are you trying to do exactly? Build an XPT file for your extension? (Excuse the ignorance, I'm just trying to find the people who might be able to help.)
Yes, I'm just trying to build an XPT file as I did before. I'm using a build.sh script that was available in mozillazine.org. What the script is doing is calling typelib: typelib.py -I [xpcom include dir] [idl file] -o [xpt file]
So, can anybody provide some basic info or documentation on how to build a legacy addon using TB 60 please?
(In reply to wavexx from comment #4) > So, can anybody provide some basic info or documentation on how to build a > legacy addon using TB 60 please? https://discourse.mozilla.org/c/thunderbird/addons is the best place to ask all things add-on related
Not when the required tools are missing
We may likely backport the FileLink WebExtensions API to 60, so in this case you should have a transition path. As for the xpt files, can you maybe link your add-on source? I'm not quite sure why an xpt file is necessary and if you can't just do this without your own idl interfaces.
Flags: needinfo?(wavexx)
Note also that most of what seems to be removed is not Thunderbird's doing. Firefox changed some things related to xpts and probably removed typelib.py. They also removed the add-ons infrastructure for legacy add-ons. We may have changed some of our own idl files though. We'd love to help, but given the toolkit dependency we have our limits.
The addon is this: https://addons.thunderbird.net/en-US/thunderbird/addon/dl-for-thunderbird/ You can see how I was building the addon here: https://github.com/DownloadTicketService/dl/tree/master/client/thunderbird-filelink-dl see config_build.sh, which is what I customized. This is how the xpt is built: BEFORE_BUILD="/usr/lib/thunderbird-devel/sdk/bin/typelib.py -I /usr/share/idl/thunderbird components/nsDL.idl -o components/nsDL.xpt"
Flags: needinfo?(wavexx)
You do not need your own interface to do what you're doing. In fact, you can see in our new API we add extra stuff to an nsIMsgCloudFileProvider without creating a new interface: https://hg.mozilla.org/comm-central/file/tip/mail/components/extensions/parent/ext-cloudFile.js.
By "new" api you mean the new webextension API?
Yes, but it's just an implementation of the old API.
@wavexx As per bug 1481052 we'd be happy to try and help with this if it appears that we can now update the add-on. My PFY re wrote another plugin for us to work with the newer TB and knows a lot more than me. He is still learning, but is bright. Unfortunately with holidays he won't be about for 3+ weeks so the best we do is take a look early January. I'll get him to take a look when he is available. By all means mail me at the my address logged here.

Is this a confirmed issue that we can fix in product? In which case it can be changed to NEW. And does the bug need to move to toolkit, as Fallen implies?

Flags: needinfo?(geoff)

I can confirm it's an issue. Toolkit doesn't work like that any more and hasn't for a long time.

Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Flags: needinfo?(geoff)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.