Closed Bug 580961 Opened 12 years ago Closed 11 years ago
[Debug and QA UI] Installed extensions cache (extensions
.sqlite) is not cleared/updated on a new installation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.3a6pre) Gecko/20100629 SeaMonkey/2.1a2 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.3a6pre) Gecko/20100629 SeaMonkey/2.1a2 The file "extensions.sqlite" in the user's profile directory (%APPDATA%\Mozilla\SeaMonkey\Profiles\<profile dir>) is not deleted (nor updated with a new maxVersion value) on a new installation, thus rendering the "Debug and QA UI" extension not working. Reproducible: Always Steps to Reproduce: 1. Have SeaMonkey 2.1a1 with the "Debug and QA UI" extension installed. 2. Uninstall 2.1a1 and install 2.1a2 without rebooting. 3. Start the newly installed 2.1a2. Actual Results: After starting the browser the "Debug and QA UI" extension is not working: 1) Its menu items (namely, "Debug" and "QA") are not displayed in the browser's main menu bar. 2) In Add-on Manager, the "SeaMonkey Debug and QA UI" extension is disabled and marked as incompatible with SeaMonkey 2.1a2. 3) There's no "Debug" node in the Preferences dialog window. Expected Results: The "Debug and QA UI" extension should work as it's supposed to.
A workaround is to exit the browser and delete extensions.sqlite in your profile directory.
Mossop, any idea what could be up there? The mentioned add-on is pre-shipped in the app in alpha builds.
This could well be bug 579513, is it still happening with current builds?
2.1a2 is the latest milestone we released, but you're right, sounds very much like that one. Please reopen this bug when it still happens once we release 2.1a3.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 579513
Build identifier: Mozilla/5.0 (Windows NT 5.2; rv:2.0b4pre) Gecko/20100817 SeaMonkey/2.1a3 The same story when updating from 2.1a2 to 2.1a3.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Could you please test with a clean profile and doing the upgrade from 2.1a1 to 2.1a3 (without using 2.1a2 in between). That will tell us if this is a dupe of bug 579513. The problem with upgrades from 2.1a2 to 2.1a3 is bug 557956.
Oops, sorry for screwed numbering.
Probably needs the same fix as Bug 657957
Summary: Installed extensions cache (extensions.sqlite) is not cleared/updated on a new installation → [Debug and QA UI] Installed extensions cache (extensions.sqlite) is not cleared/updated on a new installation
(In reply to comment #9) > Probably needs the same fix as Bug 657957 Filed bug 658283 for the general problem.
This is a little bit different since bug 627240 now with the XPIs located in distribution/extensions actually installing into the user's profile, but the problem is similar. Given that the version of the extension remains "1.0pre" even after a milestone bump, the originally installed XPI stays in place and isn't updated, thus reported as incompatible. Matching the XPI's version with SeaMonkey's version in install.rdf resolves the issue, tested with a 2.1.1pre profile accessed with a 2.2a1pre nightly where the shipped debugQA XPI was manually bumped from an add-on version of 1.0pre to 2.2a1pre. The XPI was replaced in this way, going back to 2.1.1pre didn't place back the older XPI though (which shouldn't matter as it's in the general risk of going back to an older version with an already migrated profile). Thus, an approach similar to bug 657957 should resolve the issue until the big picture is fixed in bug 658283, and may be necessary as an interim fix at least for SM 2.1/2.2 given that the global fix would come with a newer Gecko version.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows Server 2003 → All
Hardware: x86 → All
Version: unspecified → SeaMonkey 2.1 Branch
Note that I wasn't able to reproduce this, so we should either trust rsx11m testing skills, or this needs further feedback.
Assignee: nobody → jh
Status: NEW → ASSIGNED
>- <em:minVersion>2.0a</em:minVersion> >+ <em:minVersion>@SEAMONKEY_VERSION@</em:minVersion> > <em:maxVersion>@SEAMONKEY_VERSION@</em:maxVersion> This may not be a good idea as it would prevent a "bumped" version to go back to an earlier nightly (unless in that case the incompatible higher version is replaced by the compatible lower version in distribution/extensions, I didn't test that specific scenario). What's wrong with leaving it at 2.0a to be sure?
(In reply to comment #13) > What's wrong with leaving it at 2.0a to be sure? Nothing I guess. I just wanted to line this up with the themes files, but maybe we should really play safe here. Callek, your call.
Comment on attachment 533668 [details] [diff] [review] patch Ok, so I've tried this version and going back doesn't work: - create new profile with 2.1.1pre, debugQA works - open with 2.2a1pre, debugQA is updated and works - open with 2.1.1pre, debugQA is reported incompatible With minVersion=2.0a, the 2.2a1pre debugQA remains in place but works.
Comment on attachment 533668 [details] [diff] [review] patch The case for this is quite different from the themes, as this is an add-on that is being installed into the profile and which is available from AMO (and, btw, not shipped in stable releases so doesn't affect 2.1). This means that the minVersion should actually reflect the minimal version this can be installed in (as testers might install it from AMO into final versions), and it would be a good idea to not have the version of the add-on itself fluctuate too much so a new version doesn't have to be uploaded to AMO all the time, even though we are hilariously negligent in updating the actual stuff in that add-on. Also, the problems with it getting disabled might just be because AMO tells SeaMonkey it's not compatible, because nobody seems to look into the SeaMonkey Council account on AMO if I don't.
Comment on attachment 533678 [details] [diff] [review] patch v2 Notwithstanding KaiRo's concerns in comment #17 regarding AMO, that's the version I've tested and which worked in either direction as distributed with the nightly builds.
Attachment #533678 - Flags: feedback?(rsx11m.pub) → feedback+
Comment on attachment 533678 [details] [diff] [review] patch v2 I'm not convinced on this being the right or even a good course of action, as I suspect the real reason why this "fixes" the problem is because this version isn't present on AMO.
> (comment #17) it would be a good idea to not have the version of the add-on > itself fluctuate too much so a new version doesn't have to be uploaded to > AMO all the time Thinking that bug 658283 might obsolete any solution found here, we may be talking just about covering Gecko 4.0 and 5.0, possibly 6.0 before the add-on version wouldn't matter for getting and updated version as provided by the application (and that's the case covered here). Thus, current version of the debugQA add-on is 1.0pre; then there would be a couple of 2.x version which mirror the SeaMonkey milestone; finally a more general solution may become available and you can freeze the add-on version at 3.0 or something like that. Either way, I don't see how this would prevent the need to update maxVersion for the AMO download with each application update, unless it is set to a generic 2.* maxVersion, in which case one could do the same for the bundled debugQA which comes with the nightly builds and the problem would be gone. > Also, the problems with it getting disabled might just be because AMO tells > SeaMonkey it's not compatible A compatible version comes with the installer or the downloaded update, thus there isn't a need to download the debugQA extension even after an update.
(In reply to comment #20) > talking just about covering Gecko 4.0 and 5.0, possibly 6.0 There is no Gecko 4, and we just don't need to care about Gecko 2 or SeaMonkey 2.1 any more, there are no useful builds from that branch any more that include debugQA. Covering any future versions is easy by just logging into AMO and bumping the max version setting there. > then there would be a couple of 2.x version > which mirror the SeaMonkey milestone Uselessly if there's no "code" change to debugQA. Actually, in its current state, I'd even say it's more helpful to have it disabled than updated. > > Also, the problems with it getting disabled might just be because AMO tells > > SeaMonkey it's not compatible > > A compatible version comes with the installer or the downloaded update, thus > there isn't a need to download the debugQA extension even after an update. And there is no reason at all to update it if the code is the same old outdated crap as before (no offense intended, but roughly half of what's in there right now is inaccurate so "crap" is the only useful description IMHO), esp. if it's easy to make it just work with a simple fix to settings in AMO.
I must admit that the main reason I'm using the debugQA add-on is to see the BuildID in the window title. ;-) So, the options to proceed here seem to be the following: - don't do anything here and wait for bug 658283 to fix it for SM 2.3 or 2.4, then verify that it's WFM and close this bug; - set maxVersion to "infinity" or whatever reasonable value and bump the add-on version to 1.1pre to ensure that it's picked up, then provide it both with the nightly builds and from AMO and be done with it until it effectively breaks at some point; - go with the patch proposed here to bump the add-on version with each milestone, leaving two sub-variants of this option: - upload the new version every time to AMO, or - have a version with a different ID specifically for release versions, thus it can stay at AMO and won't have to be re-uploaded.
(In reply to comment #22) > - set maxVersion to "infinity" or whatever reasonable value and bump the > add-on version to 1.1pre to ensure that it's picked up, then provide it > both with the nightly builds and from AMO and be done with it until it > effectively breaks at some point; No, you misunderstand. The option here is to just log into AMO and bump the max version setting there and have no code change needed at all.
> (comment #23) just log into AMO and bump the max version I thought your point was that this isn't happening on a regular basis and thus should be avoided (current maxVersion there is 2.1b2), thus my proposal was to preemptively bump it to a higher maxVersion than necessary (assuming that no code change will be required for any SM 2.x build) to reduce the need for bumping anything. This should happen both with the shipped and AMO versions.
(In reply to comment #24) > > (comment #23) just log into AMO and bump the max version > > I thought your point was that this isn't happening on a regular basis and > thus should be avoided No, it shouldn't be avoided, it just should happen often enough. Everyone on the SeaMonkey Council should have access, but most probably just didn't care when I sent out the password. We just need to encourage people so we have someone who actually cares. ;-)
Ah, ok. It would still mean that users need to update it from there on a milestone change (assuming "someone" bumped the AMO version at that time), but apparently only until bug 658283 is fixed, so that should be feasible.
> (current maxVersion [on AMO] is 2.1b2) For KaiRo's suggestion to work, debugQA would need to be bumped to the highest current nightly version available, thus 2.2a1pre or 2.2 already.
Sure, we just need to keep updating AMO with the always most-current version available there. Nobody needs to update the add-on itself from there, though, unless he installed from there and we deliver an actual new version there.
Comment on attachment 533678 [details] [diff] [review] patch v2 r- per KaiRo's comments, if he hasn't done it I'll plan to log into AMO this week and bump. requesting feedback from myself so I don't forget to do that
Callek: Compatibility info on AMO shows SM 2.0a-2.4a1, thus maybe time to cancel your "reminder" feedback request, unless it's for bumping to 2.5a1 now.
Comment on attachment 533678 [details] [diff] [review] patch v2 Cancelling stale review request.
WONTFIX=> 1) Extensions are now in /distribution/extensions/ so a newer version will be automatically installed. 2) Compatibility version on AMO is now regularly updated by the SeaMonkey-Council.
Status: NEW → RESOLVED
Closed: 12 years ago → 11 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.