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

RESOLVED FIXED

Status

()

defect
--
major
RESOLVED FIXED
13 years ago
11 years ago

People

(Reporter: WeirdAl, Unassigned)

Tracking

({testcase})

Trunk
x86
Windows XP
Points:
---
Bug Flags:
blocking-firefox2 -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

13 years ago
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:test-update@xulwidgets.mozdev.org">
    <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:test-update@xulwidgets.mozdev.org:1_8_0_x_branch"/>
        <RDF:li RDF:resource="urn:mozilla:extension:test-update@xulwidgets.mozdev.org:1_8_x_branch"/>
      </RDF:Bag>
    </em:updates>
  </RDF:Description>

  <RDF:Description RDF:about="urn:mozilla:extension:test-update@xulwidgets.mozdev.org: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:test-update@xulwidgets.mozdev.org: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.
(Reporter)

Comment 1

13 years ago
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.
(Reporter)

Comment 2

13 years ago
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.
Flags: blocking-firefox2?
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
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.
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.
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.

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.
Flags: blocking-firefox2? → blocking-firefox2-
(Reporter)

Comment 8

13 years ago
This PHP file will redirect the caller to an appropriate RDF file.  My testing shows the update manifest system works well with this.
This should have been fixed by bug 314915.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
(Assignee)

Updated

11 years ago
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.