349324 - Extension manager only accepts the last em:updates>RDF:Seq>RDF:li

Status: RESOLVED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Alex Vincent [:WeirdAl]]

In developing XUL Widgets, I made the general assumption that I could do this:

<?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 RDF:about="urn:mozilla:extension:[e-mail]">
    <em:updates>
      <RDF:Bag>
<!-- In Firefox 1.5.0.x, having both of the below RDF:li elements breaks the update scheme. -->
        <RDF:li RDF:resource="urn:mozilla:extension:[e-mail]:1_8_0_x_branch"/>
        <RDF:li RDF:resource="urn:mozilla:extension:[e-mail]:1_8_x_branch"/>
      </RDF:Bag>
    </em:updates>
  </RDF:Description>

  <RDF:Description RDF:about="urn:mozilla:extension:[e-mail]:1_8_0_x_branch">
    <em:version>0.5.6.3</em:version>
    <em:targetApplication>
      <RDF:Description>
        <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
        <em:minVersion>1.5</em:minVersion>
        <em:maxVersion>1.5.0.*</em:maxVersion>
        <em:updateLink>http://localhost/install/test-update.xpi</em:updateLink>
      </RDF:Description>
    </em:targetApplication>
  </RDF:Description>

  <RDF:Description RDF:about="urn:mozilla:extension:[e-mail]:1_8_x_branch">
    <em:version>0.5.6.3</em:version>
    <em:targetApplication>
      <RDF:Description>
        <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
        <em:minVersion>2.0b1</em:minVersion>
        <em:maxVersion>2.0.*</em:maxVersion>
        <em:updateLink>http://localhost/install/test-update.xpi</em:updateLink>
      </RDF:Description>
    </em:targetApplication>
  </RDF:Description>
</RDF:RDF>

However, in my testing on Firefox 1.5.0.6, it appears the second em:updates>RDF:Seq>RDF:li is the only one to apply - the first, which holds the update information for Firefox 1.5.0.*, is ignored completely.

If needed, I can post a complete set of XPI's and update.rdf for the XPI's to XUL Widgets.

Steps to reproduce:
(1) Create an XPI package with an install.rdf stating the package's version is 0.1, and pointing at your update.rdf.
(2) Create a copy of the XPI package with the package version set to 0.2.
(3) Set your update.rdf for version 0.2, where it has RDF:li's for update in the above order.  Give it an extra RDF:li at the end of the RDF:Seq for Firefox version 500.0.0 ;)
(4) Install the 0.1 version into your Firefox 1.5.0.x and restart.
(5) Open the extension manager.
(6) Open the context menu on your test extension and ask it to find an update.

Expected results:

It finds the update for version 0.2 for Firefox 1.5.0.x.

Actual results:
No update found.

Comment 1

[Alex Vincent [:WeirdAl]]

Thanks to mossop for verifying this is a bug in EM and not in my update.rdf.  Also note bug 314915, which he says this bug isn't exactly a dupe of.

Comment 2

[Alex Vincent [:WeirdAl]]

Requesting blocking-firefox2:  If this bug is fixed for Gecko 1.8.1 branch and trunk, then extension authors have a workaround.  They make the Gecko 1.8.0.x entry the last RDF:li entry, and the others they place at will.

Comment 3

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

Dave or Alex, could you provide the differences between this bug and bug 314915? They are quite closely related and though they aren't exactly the same as far as symptoms go they may both be due to the same underlying problem of requiring the order in the rdf to be the same. Thanks

Comment 4

[Dave Townsend [:mossop]]

I believed that they were different enough to warrant separate consideration though I imagine that fixing both at the same time will be not much more than fixing either one.

The key is that while bug 314915 could be fixed by simply returning the update with the newest version that would not resolve this situation. You have to return the newest version that matches the application.

For instance if the update rdf listed updates 2 and 1 in the that order but 1 was for Fx 1.5 and 2 for Fx 2.0, returning only the newest version would still make firefox 1.5 miss update 1.

Comment 5

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

The current code prevents returning a version that is not compatible with the application so fixing bug 314915 should also fix this unless I am mistaken.

Comment 6

[Dave Townsend [:mossop]]

Unless Im reading this code wrong (entirely possible), the update rdf is parsed entirely by _parseV20UpdateInfo which returns a single update out of the rdf. While it will select the last update in the rdf that has a targetApplication for the current app's ID, at no point does it check that that update's min/maxversion meet the current app. That appears to happen afterwards.

So delivering different updates for different applications appears possible, but different updates for different versions of the same application does not appear to be possible currently.

Comment 7

[Mike Connor [:mconnor]]

Based on the following pieces, not going to block on this.

- AMO is not affected by this bug, as it issues different RDFs per app version
- Most extensions that have the same update.rdf don't seem to have different updates for different versions (even fixing this doesn't completely help 1.0/1.5 users without continuing to work around the bug)
- There is an unknown amount of risk for a bug that doesn't seem to be causing a lot of real-world pain.

Comment 8

[Alex Vincent [:WeirdAl]]

Attachment: work-around (PHP script)

This PHP file will redirect the caller to an appropriate RDF file.  My testing shows the update manifest system works well with this.

Comment 9

[Dave Townsend [:mossop]]

This should have been fixed by bug 314915.