Mozilla/5.0 (X11; Linux x86_64; rv:2.2a1pre) Gecko/20110329 Firefox/4.2a1pre SeaMonkey/2.2a1pre ID:20110329225206 I suspect that this regression is due to the landing of bug 627240. This tinderbox-build comes with ChatZilla, DOM Inspector and DebugQA missing: after rm -Rvf /usr/local/seamonkey tar -jxvC /usr/local -f seamonkey-2.2a1pre.en-US.linux-x86_64.tar.bz2 these extensions (which used to be built-in) are found *neither* in /usr/local/seamonkey/extensions *nor* in the extensions/ subfolder of my profile, and about:support lists none of them.

but they are in distribution/extensions of the app folder, right? I intend[ed] to write a blog post about that landing. What we found was that the extensions do not download to profile, unless its either a new profile, or the app version changes. Unfortunate for nightly users, but it will be just fine for our "normal" users. And as of b3 we'll get this out for nightly users as well (as it will be a version change since our app did this magic)

(In reply to comment #1) > but they are in distribution/extensions of the app folder, right? Yes, they are, but I didn't think to look there until you told me, and neither does the app. > > I intend[ed] to write a blog post about that landing. What we found was that > the extensions do not download to profile, unless its either a new profile, or > the app version changes. Unfortunate for nightly users, but it will be just > fine for our "normal" users. IIUC, I should make sure that extensions.checkCompatibility.2.2a is set to false, close SeaMonkey, set extensions.lastAppVersion (is that it?) in prefs.js to other than it was, and restart? Or is there some more magic that I should be aware of? > > And as of b3 we'll get this out for nightly users as well (as it will be a > version change since our app did this magic) Let's hope so.

On second thought, changing extensions.checkCompatibility.* is probably notnecessary, but changing extensions.lastAppVersion makes all the difference: after I did, ChatZilla opened at startup, and the characteristic DOMi, Venkman and DebugQA were present again (yes, Venkman was of course also among the missing). Justin, I'm marking this bug WONTFIX; feel free to reverse this decision if the circumstances (or my status) don't warrant it.

WONTFIX is what I was planning to do, I was just waiting to be sure that some othe robscure bug hadn't crept in and that the workarounds worked. Me and KaiRo had a brief discussion on this, and think that we might try and convince Mossop to do one of the following (or something similar): * In |pre| versions always attempt a profile install * Check extension version against the profile on statrup, and do the install if the extension version changed even if the app version has not. * Do #2 lazily. Another option might be to initiate some of that logic on our end. I do not expect any solution beyond what we have now to make it into 2.1

In reply to comment #3 oops ...DOMi, Venkman and DebugQA *menus* In case it wasn't clear, after faking a version change and restarting I found the "missing" extensions had been added to my profile. In reply to comment #4 OK then: REOPEN, leave as-is, or open a followup bug, as you think the case warrants.

BTW, another option would be for EM to just store and check the Build ID in addition to the version - if the versions is the same and build ID changed, then attempt at least the copy.

Maybe I don't quite understand the implications and the mechanism of the change made in bug 627240, but won't this be a problem once users migrate from their current 2.0 installation to 2.1 with the same profile? If that upgrade wipes out installed shipped extensions as it did in the nightly builds, it appears that some migration code would be needed to prevent that from happening?

(In reply to comment #7) > Maybe I don't quite understand the implications and the mechanism of the change > made in bug 627240, but won't this be a problem once users migrate from their > current 2.0 installation to 2.1 with the same profile? If that upgrade wipes > out installed shipped extensions as it did in the nightly builds, it appears > that some migration code would be needed to prevent that from happening? No the version change that will happen with that will then take the extensions in distribution/extensions and copy/install them to the users profile. All will be safe and sound in user-land.