There have been some mysterious oddities since the Lightning addon was included by default. The first set of reports were from users who had at some point tried Lightning, decided they didn't like it and so removed or disabled it. These users found that after Lightning was included by default, it would always become re-enabled. So there is something wrong in the logic that tries to decide if Lightning should be enabled or not.

I suspect your experience is another manifestation of the same problem.

The trouble is that no-one has found a way to replicate either of these failures on demand - and clearly they don't happen for the developers building Thunderbird.

Likewise, I use Lightning myself and have never seen it vanish on an update as you have. Since I do use it, I won't see the other problem of it re-enabling itself after being disabled.

Zenos, many thx for background on Lightning "enablement" issues. I fully appreciate how hard it is to replicate these probs, particularly with complex version/build levels of many layers of s/w (TB, Lightning, OS, Java, etc). This is particularly true for extensions, which, unlike addons, must integrate w. exposed TB interfaces/APIs and look seamless thru an upgrade of the underlying product. I saw warnings in TB error log relating to use of exported TB methods/objects, for restoration of the window presentation space on the post-update side (eg., "Unknown property '-moz-border-radius'"; "Unknown property '-moz-box-shadow'", etc). It's likely that the TB codebase keeps changing and Lightning isn't always up-to-date on the API changes. However, as long as Lightning data is separately "branched" and loosely coupled to the code, a reinstall should always get things back to normal.

Let's also remember that TB and Lightning have different teams, and I'm sure the last thing TB developers want to do is spend time debugging Lightning compatibility issues. I just installed Lightning 4.0.5.2, whose extension description says "Lighting 3.3.3 for Thunderbird 31 is available here" (LOL)... still maintained by Mozilla Calendar Project, but I'm sure extension compatibility tests are not a prerequisite for TB update releases (for all the above reasons).

This all said, though, the "disappearance" of an extension is odd since that is controlled by TB-side data. I did not check Lightning's level before update, nor did I check for existence of Lightning code (or take apart TB extension manifest) before reinstalling it.

EDIT: 1) Looks like "Unknown property" warning mssgs actually come from rendering stored mail messages, so forget my comments about Lightning's presentation space. 2) I still cannot find TB error log mssgs in any file in the user profile tree, so it must be stored elsewhere. On the other hand, I discovered that the log is rewritten every time TB is started, so pre-update errors (like saving extension manifest) would not survive into post-update restart. That's not helpful...

actually as this is a volunteer project, not different teams is not really the right word. although Fallen does do most of the development work for Lightning.

The issue is two fold. Lightning is a binary add-on and must maintain binary compatibility. That is what makes it fragile.

The issue so far however all appear to be related to race conditions. Some are well understood and have been fixed, others not so much.

These race conditions are basically corrupting the installed add-on data. at one point an update to lightning was installing as soon as the install was done and updating the file with it's data while lightning from the original install was still updating. IT has been messy and what should have been a remarkably simple process has been anything but. With every fix making a new problem.

On the plus side, as the council is looking at distributing new features as bundled add-ons (not everyone was happy to get chat for instance), this learning process will server us well into the future as the plan is to do more, not less bundling of add-ons.

> I saw warnings in TB error log relating to use of exported TB methods/objects, for restoration of the window presentation space on the post-update side (eg., "Unknown property '-moz-border-radius'"; "Unknown property '-moz-box-shadow'", etc). It's likely that the TB codebase keeps changing and Lightning isn't always up-to-date on the API changes. However, as long as Lightning data is separately "branched" and loosely coupled to the code, a reinstall should always get things back to normal.

None of what you describe is related.

> Let's also remember that TB and Lightning have different teams, and I'm sure the last thing TB developers want to do is spend time debugging Lightning compatibility issues. I just installed Lightning 4.0.5.2, whose extension description says "Lighting 3.3.3 for Thunderbird 31 is available here" (LOL)... still maintained by Mozilla Calendar Project, but I'm sure extension compatibility tests are not a prerequisite for TB update releases (for all the above reasons).

I think you are venturing into territory that you do know understand, because you are very much mistaken: A. The issues involved are not compatibility between Thunderbird and Lightning B. The people working on TB and Lightning are very much acquainted and in frequent contact. Further, the primary Lightning developer is a key member of the Thunderbird release team.

The problem is like more related to the mozilla *update* code.