269259 - When upgrading an extension, its metadata is not updated from the new install.rdf

Status: RESOLVED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Bradley Chapman (not reading bugmail, still gone but not forever)]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

Many users of Firefox 1.0 are reusing their profiles from Firefox 1.0PR; many of
these users have also previously installed Tabbrowser Preferences 0.6.14, whose
install.rdf file specifies the <em:optionsURL> property, pointing to
chrome://tabprefs/content/pref-tabprefs.xul

When these users upgrade TBP 0.6.14 to TBP 0.9.97, which does not contain the
<em:optionsURL> property in its install.rdf, the original <em:optionsURL>
property is retained. This is bad, because the options configuration for TBP
0.9.97 is now part of the Edit->Preferences dialog and should not be accessed
directly. The only way to "flush" the now-invalid property is to uninstall
0.9.97 and reinstall it, which copies the proper install.rdf file into place and
disables the Options button in the Extension Manager.

Reproducible: Always
Steps to Reproduce:
1. Install Firefox 1.0PR
2. Install TBP 0.6.14
3. Upgrade to Firefox 1.0; note that TBP 0.6.14 is disabled
4. Upgrade to TBP 0.9.97
5. Note that the Options button is still active

Actual Results:  
The Options button is still active, due to the presence of the <em:optionsURL>
property.

Expected Results:  
The Options button should be disabled.

This has the opportunity to cause massive user confusion; many users of TBP
0.9.97, used to the old way of accessing the extension options, were clicking
the button and subsequently failing to configure the extension, due to the
changed preferences panel - chrome://tabprefs/content/pref-tabprefs.xul is now
overlaid onto chrome://browser/content/pref/pref.xul, and is not a standalone
dialog as it was previously.

Comment 1

[Ryan VanderMeulen [:RyanVM]]

I've personally been bitten by this bug with TBP. Consider it confirmed.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041108
Firefox/1.0 (MOOX M2)

Comment 2

[Bradley Chapman (not reading bugmail, still gone but not forever)]

Changing OS to All.

Comment 3

[Josh Powell]

This also happens with the extension icon, the problem is that the install.rdf
is pretty much ignored if its already installed, aside from the version number.

Confirming again using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0.

Comment 4

[Ale Mand]

Confirming again using Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0

Solved with freshly new profile.

Comment 5

[Bradley Chapman (not reading bugmail, still gone but not forever)]

The summary change is more descriptive; what other RDF properties end up being
left over?

Comment 6

[Jens Bannmann]

(In reply to comment #5)
> The summary change is more descriptive; what other RDF properties end up being
> left over?

According to comment 3, everything besides the version information is unchanged.

Comment 7

[Ron Goldin]

(In reply to comment #3)
> This also happens with the extension icon, the problem is that the install.rdf
> is pretty much ignored if its already installed, aside from the version number.
> 
> Confirming again using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5)
> Gecko/20041107 Firefox/1.0.

Confirmed again, even the updateURL is ignored.  Kinda sad to change hosts for
an extension and homepage and the only way to update the links is to have the
end user uninstall the old version and then install the new version.  Makes the
automatic update moot.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

Comment 8

[ERG]

Same problem

Comment 9

[Robert Strong (they/them - no direct email)]

Attachment: patch

I believe some of the issues with this bug have been fixed on the trunk in that
the comments where a property isn't updated is no longer true. This patch
should fix the remainder of this bug in that if a property no loner exists it
is removed from the Extensions.rdf. I'm not sure if an sr is required for this
one or who to ask so info regarding this would be appreciated.

Comment 10

[Robert Strong (they/them - no direct email)]

Attachment: patch

Updated to fix a mistake in the Unassert call that I made creating the patch.
Previous comment still holds true.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Checked in.

Comment 12

[Robert Strong (they/them - no direct email)]

I just checked using a beast build that includes the patch and using TBP 0.6.13
from UMO along with TBP 1.2.2 from Bradley's web site. Options were available in
the Extension Manager with 0.6.13 and were no longer available when I upgraded
to 1.2.2. I also verified that em:homepageURL, em:contributor, em:optionsURL,
em:iconURL, and em:updateURL can and are removed using a test extension. Marking
fixed.