Calendar:Thunderbird Integration

Lightning to Thunderbird Integration

Lightning integration in TB38 needs some discussion, its unclear if we can pull it off but we should try. Ideally we'd need more cycles than we have to make sure it works, perhaps we could do extra betas, if that helps?

Action Items

• (Fallen) Enable Lightning by default on c-c and c-a to increase testing (app-global install)
  • Work in bug 1130854
  • Blocking bug 910660 - Packager: Precompile of startup cache fails
• (redDragon) Experiment with different addon install methods

• (MakeMyDay) Draft an opt-in dialog
  • Work in bug 1130852

• (DONE) Contact remaining localizers to see if they would be willing to translate

Favorites

• Fallen: C + D, then F if it works.
• redDragon: if A/F works, else C

Enable Lightning by default or not?

Enable for everyone

Pro:

• Will increase the active user base

Con:

• Might make users angry that have previously decided against Lightning

Enable for only new profiles

Pro:

• Doesn't aggravate existing users

Con:

Enable after opt-in

Pro:

• User control

Con:

Methods of bundling

A) distribution folder

Putting it into the distribution/extensions folder Pro:

• Easy to handle, install once
• redDragon: SeaMonkey does this for ChatZilla extension, using AMO for Chatzilla updates.
• Updates via AMO or via TB updates (if updated addon is bundled together)
• Update happens during TB startup, so compatibility should not be an issue

Con:

• Once installed, it acts like a normal extension (which means that it must autoupdate from AMO for TB updates, and does not roll back for TB downgrades)
  • I don't think that's right. It doesn't have to autoupdate from AMO. If you provide an updateURL in the install manifest, it can update from anywhere. (what I meant is that even if we ship to addon with a TB update, it does not get picked up in the profile, but has to be downloaded. Yes you could choose an alternate location)
  • If the newer version of TB comes with an updated version of the Addon, it will replace it. Otherwise for normal updates, Add On Manager will ping AMO if no updateURL is provided.
• Unfortunately, if the profile addon was disabled, the TB update that comes with the dist version of the add on replaces it in the profile and enables (need to check why this happens, maybe there is a pref in the AddOnManager that allows to not overwrite disabled addons)

B) app-global install

Pro:

• Would allow us to install disabled, and locked
• Better for Linux distributions since only one package is needed

Con:

• addons folks want to get rid of app-global installs, eventually
• mac v2 signing would break because we have new binary components in Contents/Resources
  • Might not be the case, because we would sign *with* the binary component so its ok
• Cannot prefer app-global install over profile install, need to uninstall profile Lightning?
• rkent: too many warnings forcing to re-enable

C) Download on Demand

Pro:

• Total User choice
• Simple to implement
• No issues with signing or disabled addons
• Can be combined with (D) to solve more issues

Con:

• No improvement for linux distros, although could be solved with (D)
• Not a real integration, just an extra dialog to download Lightning
  • With "real" I mostly meant system-wide install, where we don't have to worry about updates, having the wrong version installed, etc. Of course there are other issues with that mode.
• adds new failure modes (download failures, trouble keeping binary add-ons in sync)
  • Download failure might be an issue, binary-sync is not as you're always going to have that problem
  • Possibly we can fix the update problem by providing our own updateURL.
    • No, as new versions must have a higher version number, so downgrading Tb will break Lightning (TB won't download a lower version if a higher version is already installed, even if the installed version is incompatible and the lower one is compatible), and afaik, there is no automated way to download the correct version. Upgrading is a non-issue, works already
    • Upgrading mostly works, but there have been reports that the upgrade process doesn't work (sorry, no concrete examples). I was thinking about the issue that amo only has two channels, with our own updateURL we could provide more exact results.
      • We can look into these issues as soon as we have a concrete example? Agreed.
      • You'd need a non-trivial server logic. Plus, that won't solve the downgrade issue. Also agreed.

D) Ship binary components in Thunderbird/Seamonkey

This option improves compatibility, but does not really lead to direct integration. Alternatively we could just add a dialog that tells the user about incompatibility and offers to install the right version.

Pro:

• Guaranteed working binary component
• Better for Linux distributions

Con:

• Weird split between Product and extension?
• Possible non-issue: what happens if a user manages to install a wrong version of Lightning, where the JS doesn't work correctly with the binary component
• This just solves possible AMO bugs where the wrong version is installed or for some reason not available yet. It might make the update more seamless, but it doesn't really tighten the integration.

E) Install into Thunderbird, but not as an addon

This means getting rid of XPI_NAME and just packaging it into Thunderbird fully. Assumes we want to enable by default and offer no way to disable it. Can package as extension for Seamonkey/Postbox as needed.

Pro:

• No issues with updating
• No issues with linux distros

Con:

• Cannot disable Lightning (but could use a pref to load or not load Lightning's chrome.manifest)
• Need to package as extension for non-Thunderbird apps or integrate there too.

F) Install via distribution/bundles

This is kind of like (E), but instead of integrating it, we'd install via distribution/bundles. We'd need to figure out how this reacts to things like a previously installed Lightning in the profile or manually installing Lightning via addons manager.

Should it be possible to programatically disable bundles installed this way, we could combine it with a firstrun dialog.

Pro:

• Makes it feel integrated without mixing Thunderbird+Lightning
• Easy disable Calendaring via Thunderbird Preferences

Con:

• Need to check if it reacts well with updates, profile installed Lightnings, etc.

Seamonkey

• I believe Seamonkey uses distribution/ to install their extensions
• Same question as for Thunderbird, how would it be installed? We can probably use the same mechanism there.
• This support was bundled into the original Mozilla Application Suite. It just wasn't such an issue at the time. The icon was present in the lower left of the status bar for all installations, IIRC. Like Chatzilla, one either used it or did not.

L10N

Required Strings

• String freeze for TB38 is coming up soon, we need to have the migration dialog done until then
  • We don't yet know how exactly the dialog will work, so we might have to improvise.

Untranslated Locales

• Thunderbird 31 has 55 locales, Lightning 3.3 has 27 locales and 1978 strings.
  • How do we convince the remaining locales to translate almost 2k strings until the 38 release?
  • We could ship Lightning with as many locales as sign up, but it would be ideal to persuade them to translate eventually
  • Some automated possibility to cut down the number of strings?
  • Check if there are unused strings we could cut down? This would only save us a few though.
  • If we ship with only some locales, remove Lightning from untranslated locales during repack

AMO

• Can we keep the AMO page? It would make donations easier and more visible
  • If you use distribution/install then you still need this anyway for existing users
  • Will most likely be needed anyway, we can figure this out later