Launchpad has imported 56 comments from the remote bug at https://bugzilla.mozilla.org/show_bug.cgi?id=680802.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2011-08-21T22:18:23+00:00 Abhay-saraf wrote: User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0) Gecko/20100101 Firefox/7.0 Build ID: 20110816154714 Steps to reproduce: Upgrade from 6.0 to 7.0 on beta channel. Actual results: NoScript addon was uninstalled Expected results: Addons should not have been affected Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/0 ------------------------------------------------------------------------ On 2011-08-22T17:58:40+00:00 Robert-bugzilla wrote: Are you sure it isn't listed in the bottom section of the add-ons manager? Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/1 ------------------------------------------------------------------------ On 2011-08-22T18:32:31+00:00 Abhay-saraf wrote: Yeah pretty sure. I checked about:addons first thing. Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/2 ------------------------------------------------------------------------ On 2011-08-22T18:34:55+00:00 Robert-bugzilla wrote: Please double check. The installer and the updater both don't touch the user's profile so it is extremely unlikely that the add-on was by removed by either of them. It is possible that the add-ons manager code which does have code that touches the extensions in the user's profile could have removed it. Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/3 ------------------------------------------------------------------------ On 2011-08-22T19:47:49+00:00 Abhay-saraf wrote: I am a s/w developer myself and understand the importance of repros. So I double checked it on both my machines. I have the same situation on my laptop so next time I restart FF I will come back and report on it when the update gets applied on the restart Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/4 ------------------------------------------------------------------------ On 2011-08-30T21:29:43+00:00 Robert-bugzilla wrote: Have you had a chance to check yet? Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/5 ------------------------------------------------------------------------ On 2011-09-27T18:26:38+00:00 Patrik-nyborg wrote: I can confirm this (6.0.2=>7.0 release channel). Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0) Gecko/20100101 Firefox/7.0 and Mozilla/5.0 (Windows NT 6.1; rv:7.0) Gecko/20100101 Firefox/7.0 Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/6 ------------------------------------------------------------------------ On 2011-09-27T18:35:54+00:00 Savagebiscuits wrote: I had a similar issue. While I was running the Firefox 6.0beta Linux build, I went to Tools>Addons and noticed that I had a pending update for NoScript (green stripes, etc). I ignored it and went on browsing, thinking that I'll wait till I restart my browser for that update to occur (I generally leave my browser open till the end of the day, then shut it down before shutting down my computer). However, some hours later, I noticed that Firefox was wanting to update to the 7.0beta, so I decided to let it update and restart the browser. It was once that I restarted the browser and it was running as 7.0beta, that I noticed that NoScript was missing. Its .xpi file was in the extension's directory in my profile, but it wasn't listed as an addon by Firefox (other extensions were fine). I then reinstalled NoScript, with no further issues, and the extension had updated fine since. This was on a Debian Squeeze (32bit) machine. Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/7 ------------------------------------------------------------------------ On 2011-09-27T19:26:48+00:00 Robert-bugzilla wrote: That sounds like the add-ons manager is not handling add-on updates properly when the application version changes after an application update. What ever the case, application update doesn't touch the profile, modify extensions, etc. so moving over to add-ons manager. Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/8 ------------------------------------------------------------------------ On 2011-09-27T21:32:28+00:00 Dtownsend wrote: Confirmed, this line is throwing NS_ERROR_UNEXPECTED for some reason: http://mxr.mozilla.org/mozilla- central/source/toolkit/mozapps/extensions/XPIProvider.jsm#1172 Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/9 ------------------------------------------------------------------------ On 2011-09-27T23:18:53+00:00 G-maone wrote: So, if I understand it right, the downloaded file is kept in the profile (comment 7). Does this mean that another Firefox update can detect the mess and fix it? Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/10 ------------------------------------------------------------------------ On 2011-09-27T23:25:54+00:00 G-maone wrote: And could someone figure out whether it's better removing latest add-on version from AMO or declaring it incompatible with Fx 7? Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/11 ------------------------------------------------------------------------ On 2011-09-27T23:34:43+00:00 kmaglione wrote: Giorgio: I'd recommend removing it. The AMO update check mechanism is supposed to Do The Right Thing in circumstances where the newest version is not marked compatible with a given version and an older is, but that's unfortunately not reliable. If you do remove it, just let me know when you've re-uploaded and I'll review it right away. Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/12 ------------------------------------------------------------------------ On 2011-09-27T23:37:41+00:00 Jah wrote: Had the same problem today. Went from latest release of v6 to v7 on WinXP SP3 and there was no incompatibility warning regarding noscript, it was silently uninstalled. I'm not sure which version of noscript I was using before it was removed, but it was one of the dev channel releases. Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/13 ------------------------------------------------------------------------ On 2011-09-27T23:39:05+00:00 Savagebiscuits wrote: (In reply to Giorgio Maone from comment #10) > So, if I understand it right, the downloaded file is kept in the profile > (comment 7). Yes, I noticed that the new .xpi file was in the profile (in the extensions directory), yet wasn't installed and also missing in about:addons after the browser update and restart. Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/14 ------------------------------------------------------------------------ On 2011-09-27T23:48:32+00:00 Dtownsend wrote: I've figured out what the problem here is and it will likely affect any user that has a new add-on waiting to install or an update to an existing add-on waiting to be installed at the time they update from anything earlier than Firefox 7 to Firefox 7 or later. The problem stems from how the add-on install process works. We download the XPI and store it in a staging directory. We also load the information from install.rdf into a JS object. Any updated compatibility information (as well as other things I'm sure I'm not remembering) is applied to this JS object and then it is written alongside the XPI as a JSON text file. After restarting Firefox loads the JSON data rather than needing to parse install.rdf and do compatibility checks a second time. Normally that works out fine however if the version of Firefox changes in the meantime and new fields are now supported in install.rdf the loaded JSON data won't contain those new fields, best case the install/update will complete but the database won't contain the correct data from install.rdf, worst case the install fails. In this case the latter is happening. Bug 653637 introduced the new fields that is causing this. I have a hack that sort of solves the problem but I have a strong feeling that it may break things. The better solution is probably to do a better job of passing the data between Firefox instances and I have a few ideas of how to do that that I need to investigate further. Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/15 ------------------------------------------------------------------------ On 2011-09-27T23:56:21+00:00 Dtownsend wrote: (In reply to Graham Gordon from comment #14) > (In reply to Giorgio Maone from comment #10) > > So, if I understand it right, the downloaded file is kept in the profile > > (comment 7). > > Yes, I noticed that the new .xpi file was in the profile (in the extensions > directory), yet wasn't installed and also missing in about:addons after the > browser update and restart. That is a strange thing and it has the weird side effect that if the user installs a different add-on then NoScript would suddenly be detected and installed again. Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/16 ------------------------------------------------------------------------ On 2011-09-27T23:58:51+00:00 G-maone wrote: (In reply to Dave Townsend (:Mossop) from comment #15) > I have a hack that sort of solves the problem but I have a strong feeling > that it may break things. The better solution is probably to do a better job > of passing the data between Firefox instances and I have a few ideas of how > to do that that I need to investigate further. "Solve" and "solution" like in just "this won't happen again on next major update" or also "next minor update will complete broken installation/updates"? Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/17 ------------------------------------------------------------------------ On 2011-09-28T00:09:22+00:00 Dtownsend wrote: (In reply to Giorgio Maone from comment #17) > (In reply to Dave Townsend (:Mossop) from comment #15) > > > I have a hack that sort of solves the problem but I have a strong feeling > > that it may break things. The better solution is probably to do a better job > > of passing the data between Firefox instances and I have a few ideas of how > > to do that that I need to investigate further. > > "Solve" and "solution" like in just "this won't happen again on next major > update" or also "next minor update will complete broken > installation/updates"? The code changes would mean that it won't happen again the next time we introduce new fields to install.rdf. I suspect that the next update to Firefox would make it re-detect the present XPI in the profile already. Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/18 ------------------------------------------------------------------------ On 2011-09-28T00:18:15+00:00 kmaglione wrote: (In reply to Dave Townsend (:Mossop) from comment #18) > The code changes would mean that it won't happen again the next time we > introduce new fields to install.rdf. I suspect that the next update to > Firefox would make it re-detect the present XPI in the profile already. Can we confirm that? If it is the case, is there something else we can do to automatically re-install the add-ons that were uninstalled from this bug for users with automatic updates? If not, can we push out a minor release with this fixed so that it happens anyway? Millions of users having their favorite add-ons disappear is not good for Firefox's public image. Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/19 ------------------------------------------------------------------------ On 2011-09-28T00:22:30+00:00 Dtownsend wrote: (In reply to Kris Maglione [:kmag] from comment #19) > (In reply to Dave Townsend (:Mossop) from comment #18) > > The code changes would mean that it won't happen again the next time we > > introduce new fields to install.rdf. I suspect that the next update to > > Firefox would make it re-detect the present XPI in the profile already. > > Can we confirm that? If it is the case, is there something else we can do to > automatically re-install the add-ons that were uninstalled from this bug for > users with automatic updates? If not, can we push out a minor release with > this fixed so that it happens anyway? Millions of users having their > favorite add-ons disappear is not good for Firefox's public image. I'm working with the release drivers as we speak to figure out the best path forwards Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/20 ------------------------------------------------------------------------ On 2011-09-28T00:23:00+00:00 Hskupin wrote: Dave, is there anything QA could help at this stage? Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/21 ------------------------------------------------------------------------ On 2011-09-28T00:28:45+00:00 Dtownsend wrote: (In reply to Kris Maglione [:kmag] from comment #19) > (In reply to Dave Townsend (:Mossop) from comment #18) > > The code changes would mean that it won't happen again the next time we > > introduce new fields to install.rdf. I suspect that the next update to > > Firefox would make it re-detect the present XPI in the profile already. > > Can we confirm that? If it is the case, is there something else we can do to > automatically re-install the add-ons that were uninstalled from this bug for > users with automatic updates? If not, can we push out a minor release with > this fixed so that it happens anyway? Millions of users having their > favorite add-ons disappear is not good for Firefox's public image. I've also just confirmed that this works, it reverts back to the previous version of NoScript, but that'd then automatically updated in the next day. Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/22 ------------------------------------------------------------------------ On 2011-09-28T00:29:16+00:00 Dtownsend wrote: (In reply to Henrik Skupin (:whimboo) from comment #21) > Dave, is there anything QA could help at this stage? Not right now thanks Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/23 ------------------------------------------------------------------------ On 2011-09-28T00:37:42+00:00 Clegnitto wrote: (In reply to Dave Townsend (:Mossop) from comment #22) > (In reply to Kris Maglione [:kmag] from comment #19) > > (In reply to Dave Townsend (:Mossop) from comment #18) > > > The code changes would mean that it won't happen again the next time we > > > introduce new fields to install.rdf. I suspect that the next update to > > > Firefox would make it re-detect the present XPI in the profile already. > > > > Can we confirm that? If it is the case, is there something else we can do to > > automatically re-install the add-ons that were uninstalled from this bug for > > users with automatic updates? If not, can we push out a minor release with > > this fixed so that it happens anyway? Millions of users having their > > favorite add-ons disappear is not good for Firefox's public image. > > I've also just confirmed that this works, it reverts back to the previous > version of NoScript, but that'd then automatically updated in the next day. A) I'm not exactly sure this is millions of users. Yes, we have reports in this bug but we aren't seeing widespread problems yet (admittedly could be due to a lag in feedback channels) B) Does uninstalling a different add-on trigger the "hidden" ones to show up / reinstall as well? Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/24 ------------------------------------------------------------------------ On 2011-09-28T00:44:48+00:00 kmaglione wrote: (In reply to Christian Legnitto [:LegNeato] from comment #24) > A) I'm not exactly sure this is millions of users. Yes, we have reports in > this bug but we aren't seeing widespread problems yet (admittedly could be > due to a lag in feedback channels) I'm basing my assumption on the fact that this seems to be 100% reproducable when an add-on update was downloaded just before a Firefox update. NoScript has over 2 million users, and Giorgio pushed out an update several hours before the Firefox release team did. There have also been reports of affected AdBlock Plus users. So this easily has the potential to affect millions of users and I'd rather err on the side of caution. Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/25 ------------------------------------------------------------------------ On 2011-09-28T00:46:03+00:00 Dtownsend wrote: (In reply to Christian Legnitto [:LegNeato] from comment #24) > B) Does uninstalling a different add-on trigger the "hidden" ones to show up > / reinstall as well? Yes Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/26 ------------------------------------------------------------------------ On 2011-09-28T01:08:56+00:00 Fligtar-h wrote: (In reply to Christian Legnitto [:LegNeato] from comment #24) > A) I'm not exactly sure this is millions of users. Yes, we have reports in > this bug but we aren't seeing widespread problems yet (admittedly could be > due to a lag in feedback channels) > I wouldn't expect widespread reports of this for days or weeks -- most users won't notice their add-ons are gone immediately. The day before and of a Firefox release is always the busiest time for putting out add-on updates. Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/27 ------------------------------------------------------------------------ On 2011-09-28T01:22:11+00:00 G-maone wrote: I removed the latest versions of my add-on both from the beta and the dev channel, but as a more general stop-gap measure couldn't AMO temporarily stop answering add-on update pings which come from Gecko 4-6.x? Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/28 ------------------------------------------------------------------------ On 2011-09-28T01:25:55+00:00 Fligtar-h wrote: (In reply to Giorgio Maone from comment #28) > I removed the latest versions of my add-on both from the beta and the dev > channel, but as a more general stop-gap measure couldn't AMO temporarily > stop answering add-on update pings which come from Gecko 4-6.x? We'd have to devise a pretty complicated solution in order to do that, because most add-ons aren't explicitly compatible with Firefox releases anymore and depend on AMO update responses saying they are compatible. Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/29 ------------------------------------------------------------------------ On 2011-09-28T01:38:30+00:00 kmaglione wrote: (In reply to Justin Scott [:fligtar] from comment #29) > (In reply to Giorgio Maone from comment #28) > > I removed the latest versions of my add-on both from the beta and the dev > > channel, but as a more general stop-gap measure couldn't AMO temporarily > > stop answering add-on update pings which come from Gecko 4-6.x? > > We'd have to devise a pretty complicated solution in order to do that, > because most add-ons aren't explicitly compatible with Firefox releases > anymore and depend on AMO update responses saying they are compatible. I think he means pings coming from Gecko 4-6. I.e., for requests where currentAppVersion is less than 7, return no results until this issue has been sorted out. Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/30 ------------------------------------------------------------------------ On 2011-09-28T03:26:41+00:00 Mardeg wrote: *** Bug 689842 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/31 ------------------------------------------------------------------------ On 2011-09-28T03:42:44+00:00 Shadowfyr55 wrote: Just to be clear, I ran into this too. Its not uncommon for Firefox to state that some addons are "incompatible", and it will, usually, update some of them, when installing the new version. In my case, I got a list, which I mostly didn't pay attention to, except that I know it included Linkification (self adjusted, because its one of those that half the time doesn't update at all), and HTTPS-Everywhere, which I very recently added. I don't know if Noscript was "in the list" or not, but a number where listed as, "Current version is not compatible, check for updates?" As soon as the client loaded, every single thing that was in that list was just flat missing. Once I "installed" another plugin, as suggested by someone here, and restarted, they all reappeared. It should be noted that, for me, installing a new Noscript "failed" to make this happen, or make it reappear, I had to install a completely different plugin, picked semi-randomly out of the ones available. So, something in the process of checking for compatibility and updating the list of new versions to load, failed. Its possible it effected only very recent additions, since it killed ones that I installed and/or manually updated, the last time I got such an update message as well. Everything installed "prior" to that update, stayed. And I know Noscript updated since then, I added the HTTPS one after that, and I also hand patched Linkification, to make it compatible (since I didn't figure what it did what likely broken between versions). I will bet donuts to dollars that everything else listed was in the same category, with the exception of a few that really are out of date, and I just haven't gotten rid of (or can't... I just love ones that refuse to let you uninstall them...). Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/32 ------------------------------------------------------------------------ On 2011-09-28T03:56:59+00:00 Dtownsend wrote: (In reply to Patrick Elliott from comment #32) > Just to be clear, I ran into this too. Its not uncommon for Firefox to state > that some addons are "incompatible", and it will, usually, update some of > them, when installing the new version. In my case, I got a list, which I > mostly didn't pay attention to, except that I know it included Linkification > (self adjusted, because its one of those that half the time doesn't update > at all), and HTTPS-Everywhere, which I very recently added. I don't know if > Noscript was "in the list" or not, but a number where listed as, "Current > version is not compatible, check for updates?" As soon as the client loaded, > every single thing that was in that list was just flat missing. Once I > "installed" another plugin, as suggested by someone here, and restarted, > they all reappeared. The list you refer to, was it something that displayed while you were still running Firefox 6, part of the UI telling you that a new version of Firefox was available, or was it something that displays after you first started Firefox 7? Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/33 ------------------------------------------------------------------------ On 2011-09-28T04:27:18+00:00 Shadowfyr55 wrote: Hmm. Hard to say, actually. I think the list was shown when starting the new one, maybe, then there was an error, during the actual start up, in a sort of off color, yellowish, box, during the step where updates to the addons would normally happen, which said that there had been a problem installing new version of the addons. The original list is the one that always shows up when patching versions, and a conflict happens, so I am pretty sure it happened when ever that does normally. But the error happened "during" the update for new addons, so.. I think that happens during start up, not in the old one. In any case, I think Firefox does realize something went wrong, hence the error message, during the step where download of the addons would happen, after starting up, but it didn't know what to do about it. Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/34 ------------------------------------------------------------------------ On 2011-09-28T04:31:36+00:00 Dtownsend wrote: (In reply to Patrick Elliott from comment #34) > Hmm. Hard to say, actually. I think the list was shown when starting the new > one, maybe, then there was an error, during the actual start up, in a sort > of off color, yellowish, box, during the step where updates to the addons > would normally happen, which said that there had been a problem installing > new version of the addons. The original list is the one that always shows up > when patching versions, and a conflict happens, so I am pretty sure it > happened when ever that does normally. But the error happened "during" the > update for new addons, so.. I think that happens during start up, not in the > old one. The bug we have here happens before the UI you're talking about appears so the UI simply wouldn't contain add-ons that got hit by it. You're also saying you lost a lot of add-ons, some of which definitely wouldn't have had any updates waiting to install before you upgraded. So either we don't yet correctly understand this bug, or there is a different bug that you hit. Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/35 ------------------------------------------------------------------------ On 2011-09-28T04:51:57+00:00 Cbeard wrote: Our China team reports that they are seeing this across their entire user base as their localized distribution of Firefox relies upon a bundle of add-ons to package and deliver their local market adaptations -- and we updated all of those add-ons this week ahead of the release Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/36 ------------------------------------------------------------------------ On 2011-09-28T05:08:25+00:00 Shadowfyr55 wrote: Well, as I said, my guess is that it may effect addons that "only" where updated "recently", like within weeks of the new patch. The bug may be happening before that UI appears, but the UI itself, in my case, just happened to catch that something went odd. I am not entirely certain which one though. Thinking on it.. I may have seen one, on shutdown, that said they where not compatible, then one on start, which showed "others" which where not up to date (legitimately), but not the ones that had gone missing, and *then* a message, telling me that something went badly wrong. But I am not 100% certain of the order. But, now that you mention it, its likely the bug, and the initial list, happened in the process of the first one closing down. In any case, all the "lost" ones where, as with Chris, *recent*, and they all popped up, and without "incompatibility" messages, as soon as a new addon was put in the queue, and a new restart was done. Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/37 ------------------------------------------------------------------------ On 2011-09-28T05:53:34+00:00 Dtownsend wrote: Created attachment 562976 patch rev 1 This is the patch that seems like the best solution. We still cache the entire manifest when preparing to install (for backwards compatibility) however on the startup it completely loads the install manifest from install.rdf (thus parsing it and getting all the fields that the new Firefox supports) and then also loads the cached manifest and copies across only certain appropriate properties. If any of the properties expected seem to be missing then we just ignore and carry on. This should guarantee a safe and working add-on install. There is a small performance penalty associated here because we have to read install.rdf on startup for every new add-on. I haven't measured the cost of that yet but I expect it to be low and as it is only for the case when a new add-on is installed I'd expect it to be worth it for correcting this. I think the only risk here is that if I have missed any properties to copy across. That would appear as the add-on changing state in some way on upgrade (maybe getting disabled etc.) but I am growing confident that I have them all. I'll be double checking that in the morning but figured I might as well put the patch up now as adding properties to that list won't really change the review. We can also be over-zealous about listing properties there (maybe even just try to copy all properties) because the new code will simply ignore any it doesn't find and the cached properties will always be the same or newer than those loaded from install.rdf. The testcase from bug 664833 already checks installing an update when the DB schema and app version changes. The only thing missing was to make the cached manifest have a necessary property missing so I updated the test to do that. Without this fix the test fails in the same way that I've been seeing in this bug. I've pushed this to the try server, if people want to test builds they will be showing up at http://ftp.mozilla.org/pub/mozilla.org/firefox /try-builds/[email protected] Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/38 ------------------------------------------------------------------------ On 2011-09-28T05:57:45+00:00 Dtownsend wrote: (In reply to Dave Townsend (:Mossop) from comment #38) > The testcase from bug 664833 already checks installing an update when the DB > schema and app version changes. The only thing missing was to make the > cached manifest have a necessary property missing so I updated the test to > do that. Without this fix the test fails in the same way that I've been > seeing in this bug. Forgot to add, the testcase here is good and I think an accurate test for this, however it suffers from the same problem that much of our automated tests for updates do, it doesn't actually test moving from one version of Firefox to another in reality. So we certainly want a litmus test for this scenario. Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/39 ------------------------------------------------------------------------ On 2011-09-28T06:06:33+00:00 Robert-bugzilla wrote: Comment on attachment 562976 patch rev 1 Looks like a decent approach. btw: there is a bug to test app updates after the nightly build. Perhaps a similar test for this case should be done at the same time. Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/40 ------------------------------------------------------------------------ On 2011-09-28T10:25:55+00:00 Hskupin wrote: (In reply to Dave Townsend (:Mossop) from comment #39) > tests for updates do, it doesn't actually test moving from one version of > Firefox to another in reality. So we certainly want a litmus test for this > scenario. We already have a litmus test for it. Sadly it's only part of the major update test scenario. Since we do minor updates now, those tests haven't been executed. We should create a test group for minor updates and include all appropriate tests from the MU test group. I have already started this discussion so we can hopefully proceed on it quickly. Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/41 ------------------------------------------------------------------------ On 2011-09-28T10:33:10+00:00 Steffen Wilberg wrote: This has been reported by several users in a German IT news site: the update deleted Adblock Plus (http://www.heise.de/newsticker/foren/S-Firefox-Update-loescht-Adblock-Plus/forum-210502/msg-20851562/read/) Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/42 ------------------------------------------------------------------------ On 2011-09-28T11:00:48+00:00 Epinal99-bugzilla wrote: I guess bug 689752 (NoScript icon disappeared from add-on manager after auto-updating to Firefox 7) is a dupe of this bug. Issue reported here http://forums.informaction.com/viewtopic.php?p=31326#p31326 with NoScript. Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/43 ------------------------------------------------------------------------ On 2011-09-28T11:12:16+00:00 Hskupin wrote: *** Bug 689752 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/44 ------------------------------------------------------------------------ On 2011-09-28T11:50:34+00:00 Trev-moz wrote: I did some testing and can confirm that uninstalling another extension resolves the problem - as does any other change to your extensions (enabling/disabling an extension, updating some extension etc). The add- on isn't really uninstalled and stays in the extensions/ directory, the update is actually applied correctly. It is only that the add-on manager temporarily "forgets" about it. I also verified that a minor browser update fixes the issue automatically - it forces the add-on manager to check the list of add-ons again. So far I have only seen one report of this issue (https://addons.mozilla.org/addon/adblock-plus/reviews/313717/), no idea how many Adblock Plus users are affected. Is removing the update from AMO really the best course of action? I am pretty certain that I will receive lots of complains about Adblock Plus not being compatible with Firefox 7 then - install.rdf of Adblock Plus 1.3.9 lists Firefox 7.0a1 as maxVersion which means trouble even if AMO says something different. Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/45 ------------------------------------------------------------------------ On 2011-09-28T14:08:58+00:00 VanillaMozilla wrote: *** Bug 601937 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/46 ------------------------------------------------------------------------ On 2011-09-28T14:20:52+00:00 ashughes wrote: Just want to get a clear set of steps to reproduce this bug so QA can quickly verify the fix. Please confirm these steps: 1) Install Firefox <7.0 2) Install an add-on which is compatible to Firefox 7.0 but not the latest version of the add-on 3) Restart Firefox 4) Check for and download the update for the add-on (DO NOT INSTALL IT) 5) Check for and download the update for Firefox 7.0.1 6) Restart Firefox to install the update Expected Result: Firefox and add-ons updated Please confirm the above steps. Also, what is the expected update path / test for: * 4.* users * 5.* users * 6.* users * 7.0 users * 4b*/ 5b* / 6b* users * 3.6 Major Update Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/47 ------------------------------------------------------------------------ On 2011-09-28T15:16:20+00:00 Dtownsend wrote: (In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #47) > Just want to get a clear set of steps to reproduce this bug so QA can > quickly verify the fix. Please confirm these steps: > > 1) Install Firefox <7.0 > 2) Install an add-on which is compatible to Firefox 7.0 but not the latest > version of the add-on > 3) Restart Firefox > 4) Check for and download the update for the add-on (DO NOT INSTALL IT) > 5) Check for and download the update for Firefox 7.0.1 > 6) Restart Firefox to install the update > > Expected Result: > Firefox and add-ons updated These look like the correct STR to me. I would also suggest a second set of steps for verification: 1) Install Firefox <7.0 2) Install an add-on which is compatible to Firefox 7.0 but not the latest version of the add-on 3) Restart Firefox 4) Check for and download the update for the add-on (DO NOT INSTALL IT) 5) Exit and install Firefox 7.0 6) Check that the add-on is now missing from the add-ons manager 7) Check for and download the update for Firefox 7.0.1 8) Restart Firefox to install the update Expected Result: The add-on that disappeared in step 6 should have reappeared. Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/48 ------------------------------------------------------------------------ On 2011-09-28T16:27:08+00:00 Vlad-mozbugs wrote: Can confirm the fix for upgrading from 6.0 to try server build http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[email protected]/ Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/49 ------------------------------------------------------------------------ On 2011-09-28T17:04:44+00:00 Chimel wrote: I lost AddBlock Plus, had to reinstall manually. http://www.reddit.com/r/firefox/comments/ktvyl/upgrading_to_firefox_7_uninstalls_adblock_plus/ In addition to fixing the bug, can you: 1) Add this test case (add-on that has a pending update) to your normal test cases 2) Notify users of any add-on that was disabled or removed after a Firefox upgrade Given the new fast dev cycle between upgrades, it is really important to log every anomaly instead of just ignoring it. I would have liked to test the patch, but my add-ons are now up to date. It would be great if you could create a test add-on that users can update locally to try and repro this type of bug, instead of relying on actual add-ons that may or may not have been updated. Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/50 ------------------------------------------------------------------------ On 2011-09-28T17:13:43+00:00 Dtownsend wrote: Created attachment 563099 patch rev 2 Made the minor change of adding applyBackgroundUpdates to the list of properties copied across, otherwise identical, probably doesn't need re- review but better safe than sorry Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/51 ------------------------------------------------------------------------ On 2011-09-28T18:47:23+00:00 Dtownsend wrote: Pushed to trunk: https://hg.mozilla.org/mozilla-central/rev/80b55a615ac9 Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/53 ------------------------------------------------------------------------ On 2011-09-28T19:08:02+00:00 Dojnd wrote: *** Bug 690020 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/54 ------------------------------------------------------------------------ On 2011-09-28T19:32:47+00:00 Clegnitto wrote: Comment on attachment 563099 patch rev 2 Approved everywhere. Land all the places! Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/55 ------------------------------------------------------------------------ On 2011-09-28T19:34:19+00:00 Clegnitto wrote: To be clear we'll want to land this on the "default" branch of: releases/mozilla-aurora releases/mozilla-beta releases/mozilla-release as well. Thanks! Reply at: https://bugs.launchpad.net/firefox/+bug/861664/comments/56 ** Changed in: firefox Status: Unknown => Fix Released ** Changed in: firefox Importance: Unknown => High -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/861664 Title: Upgrading Firefox/Thunderbird when an add-on update is waiting to be installed hides the add-on To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/861664/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
