desktop-packages team mailing list archive

[Bug Watch Updater <861664@xxxxxxxxxxxxxxxxxx>]

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/dtownsend@xxxxxxxxxxx-1cb2d7c3b19b

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/dtownsend@xxxxxxxxxxx-1cb2d7c3b19b/

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 Desktop
Packages, which is subscribed to thunderbird in 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

Status in The Mozilla Firefox Browser:
  Fix Released
Status in “firefox” package in Ubuntu:
  Triaged
Status in “thunderbird” package in Ubuntu:
  Triaged
Status in “firefox” source package in Oneiric:
  Triaged
Status in “thunderbird” source package in Oneiric:
  Triaged

Bug description:
  This affects users by temporarily hiding their addon until another
  addon update/install prompts the addon manifest to be rebuilt.

To manage notifications about this bug go to:
https://bugs.launchpad.net/firefox/+bug/861664/+subscriptions