If you use the built-in software update to update Thunderbird (I'm on the nightly build channel on the 1.8 branch), Enigmail doesn't load when Thunderbird starts again after the update installs. If you then quit Thunderbird and start it again manually it loads fine. This is using the 0.93.0 build of Enigmail. In the real world this won't happen very often (Thunderbird will get updated every 6 weeks or so probably?) but it's extremely visible and frustrating when it does (bad user experience). This has also been filed as http://mozdev.org/bugs/show_bug.cgi?id=12727 against Enigmail, but with it being as late in the game as it is for 1.5 I'm not sure whose problem it is, so I'm filing it both places.
OK, this isn't enigmail, unless DOM Inspector has the same bug. I just built the new DOM Inspector that mscott checked in the other day, and installed that, and the menu item inserted in the Tools menu by DOM Inspector also does not show up after an update until I quit and restart Thunderbird again. I've also reproduced this with the "Remove Duplicate Messages" extension. The context menu item when right-clicking a folder to delete duplicate messages from that folder also doesn't show up until after restarting Thunderbird again.
Summary: Enigmail doesn't load after a software update → Extensions that modify chrome don't load after a software update
benjamin usually has good ideas about this kind of thing.
I don't understand. Is the extension disabled? Is the "maxVersion" of the DOMI that scott released 1.5 or 1.5.0.* ? What are the exact steps to reproduce of this bug?
Unless you tell me how I would tell, I can't answer that. It doesn't appear to be disabled, I don't know if it loads or not, but the chrome the extensions modify does not get modified, which is the extent of the systems I can see without pointers for what else to look at. Steps to reproduce: 1) Install any extension that modifies chrome (DOMi, Enigmail, and Delete Duplicate Messages can all reproduce this, I'd imagine any of a number of others can, too). 2) Restart Thunderbird and verify that the modified chrome in question is present (menu items, toolbar icons, etc). 3) Install an update to Thunderbird via the automated update system. This will restart Thunderbird as part of the update process. 4) Verify that the modified chrome in question is *not* present. 5) Restart Thunderbird manually, and verify that the modified chrome *is* present again.
OK. For the moment we'll call this an EM issue ;-)
Assignee: mscott → nobody
Component: Mail Window Front End → Extension/Theme Manager
Product: Thunderbird → Firefox
QA Contact: extension.manager
Version: 1.5 → Trunk
Dave suggested (at bug 254031) that the problem I noticed might be the same; I don't think my steps-to-reproduce are the same as his, but he's probably right that the symptom is related. But here's what I did (Win2K): 1) Run TB 1.5RC2 2) Install DOM Inspector extension; get message 'DOMi will be installed when TB is restarted.' 3) Restart TB 1.5RC2; DOMi is there. 4) Exit 1.5RC2; run 1.6a1-0105; get 'Checking Extensions' window, and informed that DOMi is out of date. 5) Check Extensions window: DOMi is disabled and may not be enabled. 6) Exit 1.6a1; restart 1.5RC2 7) Check Extensions window; DOMi is disabled, but may be enabled. 8) Select 'Enable', get message 'DOMi will be installed when TB is restarted.' 9) RE-restart 1.5RC2; DOMi is there. Actual results: 8) DOMi isn't available (probably because extensions' chrome init only takes place at startup) Expected results: 8) DOMi should be immediately avaialable (chrome should be updated dynamically) Actually, those expected results would be nice after step (2) as well. I suspect this isn't a Mac-only bug.
Mike, that's totally unrelated.
(In reply to comment #5) > OK. For the moment we'll call this an EM issue ;-) I can't reproduce this in Firefox at all. It's definitely a Thunderbird-only bug.
I was not able to reproduce by installing DOMi, installing Thunderbird from http://mozilla.osuosl.org/pub/mozilla.org/thunderbird/nightly/2006-01-06-07-mozilla1.8/ changing channel-prefs.js from release to nightly, and auto-updating the couple of times it takes to get to the latest build. After each restart from an update I verified that DOMi appeared under Tools, that it could be launched, and I inspected chrome://messenger/content/messenger.xul each time as well.
Forgot to mention this is on WinXP
It may be possible for me to reproduce this if you zip up your profile's extensions directory along with the extensions.cache, extensions.ini, and extensions.rdf in your profile's directory. I've found some fairly unusual quirks in the last week when debugging with these files. It would be easiest if you could email them to me.
qawanted: is anyone besides Dave seeing this problem?
Minus for release drivers until we get a better handle on reproducability
Flags: blocking18.104.22.168? → blocking22.214.171.124-
This seems to have fixed itself in the last couple nightlies I've pulled? After installing an update, it now does the "double restart" thing on its own, and by the time I get control of the app everything's loaded.
Chances are it was due to something specific with the extensions installed in your profile... there have been several bugs found with the EM that can have this symptom in that the EM throws and when it does would have prevented the second restart. If you experience this again please zip up your profile's extensions directory and the profile's extensions.cache, extensions.ini, and extensions.rdf. I know it is a pain but they have been invaluable in finding root causes like * not being able to delete a .lnk file that does not contain shortcut info. * read-only files in the extensions dir * enum bug in the EM * and others
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.