808435 - Addon type change deprives users from automatic addon updates

Status: RESOLVED DUPLICATE of bug 782118

(Toolkit :: Add-ons Manager, defect)

Description

[Reşat SABIQ (Reshat)]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20100101 Firefox/16.0
Build ID: 20121010144125

Steps to reproduce:

If an addon type is changed, for instance from type 8 (langpack) to type 2 (extension), as in the following diff chunk (install.rdf):
   <Description about="urn:mozilla:install-manifest"
-               em:type="8"
+               em:type="2"


Actual results:

Then automatic updates of the addon (after Firefox/Thunderbird, etc. upgrade) no longer work, and if the addon's targetApplication maxVersion is below the version to  which the app is upgraded (e.g., 15.* and app is upgraded to 16.0.*), then the addon is disabled indefinitely (unless and until the user installs it again to get the new type value manually (hopefully this works, but still remains to be confirmed)).


Expected results:

The addon should have been and should be updated without regard to the addon type (change (if any)).

ROOT CAUSE
1. Upon upgrade, Firefox (Thunderbird, etc.) makes a request like to check for updated version of the addon, e.g.:
https://versioncheck.addons.mozilla.org/update/VersionCheck.php?reqVersion=2&id={<some_addon_id/>}&version=15.0&maxAppVersion=15.*&status=userEnabled&appID={ec8030f7-c20a-464f-9b0e-13a3a9e97384}&appVersion=16.0.2&appOS=Linux&appABI=x86-gcc3&locale=<some_locale/>&currentAppVersion=15.0.1&updateType=98&compatMode=normal
2. After a change in addon type, the response to the above request changes similar to the diff chunk shown below (shown here is the change from type 8 to type 2, but apparently this is equivalent for pretty much any change in addon type (perhaps everything other than type 2 uses urn:mozilla:item)):
 <?xml version="1.0"?>
 <RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
          xmlns:em="http://www.mozilla.org/2004/em-rdf#">
-    <RDF:Description about="urn:mozilla:item:{...}">
+    <RDF:Description about="urn:mozilla:extension:{...}">
         <em:updates>
             <RDF:Seq>
-                <RDF:li resource="urn:mozilla:item:{...}:16.0"/>
+                <RDF:li resource="urn:mozilla:extension:{...}:16.0"/>
             </RDF:Seq>
         </em:updates>
     </RDF:Description>
 
-    <RDF:Description about="urn:mozilla:item:{...}:16.0">
+    <RDF:Description about="urn:mozilla:extension:{...}:16.0">

So the reason the automatic updates fail in this scenario is because the app doesn't treat the changes from urn:mozilla:item to urn:mozilla:extension seamlessly, and ignores the rest of the response (even if it contains valid em:updateLink, em:updateInfoURL, and em:updateHash).

POSSIBLE FIXES
A. Update the apps to not fail automatic updates because of the urn change mentioned in item 2. above, as long as the {id} matches.
B. Update the response to the request in item 1., to not use different urns for different addon types.

Comment 1

[Reşat SABIQ (Reshat)]

Example addon (as an illustration of the bug (the bug should be reproducible when upgrading from Firefox 15 to any higher major release)):
https://addons.mozilla.org/en-US/firefox/addon/QIRIMTATARCA-til-destesi/

Sample RDF xml for the afore-mentioned addon (after change from type 8 to type 2 (done based on discussions on AMO as a pre-condition to be able to continue to use some non-langpack features such as making the app look from the outside like using Turkish locale (for privacy reasons))):
<?xml version="1.0"?>
<RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:em="http://www.mozilla.org/2004/em-rdf#">
    <RDF:Description about="urn:mozilla:extension:{d5af7e07-9f33-40c7-9234-0b2c2da6ada2}">
        <em:updates>
            <RDF:Seq>
                <RDF:li resource="urn:mozilla:extension:{d5af7e07-9f33-40c7-9234-0b2c2da6ada2}:16.0"/>
            </RDF:Seq>
        </em:updates>
    </RDF:Description>

    <RDF:Description about="urn:mozilla:extension:{d5af7e07-9f33-40c7-9234-0b2c2da6ada2}:16.0">
        <em:version>16.0</em:version>
        <em:targetApplication>
            <RDF:Description>
                <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
                <em:minVersion>16.0a2</em:minVersion>
                <em:maxVersion>16.*</em:maxVersion>
                <em:updateLink>http://releases.mozilla.org/pub/mozilla.org/addons/7420/qirimtatarca_til_destesi_crimean_tatar_lang_pack-16.0-fx.xpi</em:updateLink>
                <em:updateInfoURL>https://addons.mozilla.org/versions/updateInfo/1385504/%APP_LOCALE%/</em:updateInfoURL>
                <em:updateHash>sha256:10c8b7ae720a8e393b098db6441020c02e8466003e796b8ee28b4e507ce1076b</em:updateHash>
            </RDF:Description>
        </em:targetApplication>
    </RDF:Description>
</RDF:RDF>

P.S. I have another addon just like this whose type hasn't been changed yet, and it's updated upon upgrade just fine. Item 2. in the initial details is based on the diff. in the upgrade process while using the 2 addons.

Comment 2

[Axel Hecht]

Moving to the addons-manager, I don't think this is a bug in the RDF engine itself.

Comment 3

[Virgil Dicu [:virgil] [QA]]

IS this a regression in 15?

Comment 4

[Dave Townsend [:mossop]]

This will have been fixed by bug 782118