Closed Bug 558823 Opened 15 years ago Closed 15 years ago

Migrate compatibility information from extensions.rdf

Categories

(Toolkit :: Add-ons Manager, defect, P1)

defect

Tracking

()

VERIFIED FIXED
mozilla1.9.3a5

People

(Reporter: mossop, Assigned: mossop)

References

Details

(Whiteboard: [rewrite][AOMTestday])

Attachments

(1 file)

Without the compatibility information from extensions.rdf migrated to the new database nightly testers switching to the new add-ons manager will see many of their extensions get disabled until the next regular update check.
Mmh, I did a test last week by manually checking for updates but no compatibility update gets downloaded. I wasn't able to re-activate the add-ons by that time.
Blocks: 557956
Flags: in-testsuite?
This doesn't block bug 557956, it's basically a simple fix that will ease the transition for nightly testers. (In reply to comment #1) > Mmh, I did a test last week by manually checking for updates but no > compatibility update gets downloaded. I wasn't able to re-activate the add-ons > by that time. That sounds like a separate issue. I'm pretty sure that works on the API side and we have tests for it so it may be a UI issue.
No longer blocks: 557956
(In reply to comment #2) > That sounds like a separate issue. I'm pretty sure that works on the API side > and we have tests for it so it may be a UI issue. I have filed bug 559808.
Attached patch patch rev 1 (deleted) — Splinter Review
Don't really like how much RDF is leaking out into the main code, I might move it all into its own module, EvilCode.jsm or something at some point soon. Right now it is either this or reproduce the same utility functions in a bunch of places. This migrates the target app compatibility when we re-discover the add-ons on startup and modifies the existing test to cover this.
Attachment #439620 - Flags: review?(robert.bugzilla)
Flags: in-testsuite? → in-testsuite+
Whiteboard: [rewrite] → [rewrite][fixed-in-addonsmgr][needs-review]
Comment on attachment 439620 [details] [diff] [review] patch rev 1 >diff --git a/toolkit/mozapps/extensions/XPIProvider.jsm b/toolkit/mozapps/extensions/XPIProvider.jsm >--- a/toolkit/mozapps/extensions/XPIProvider.jsm >+++ b/toolkit/mozapps/extensions/XPIProvider.jsm >... >@@ -237,74 +241,94 @@ function isUsableAddon(aAddon) { > if (!aAddon.matchingTargetApplication) > return false; > } > if (XPIProvider.checkUpdateSecurity && !aAddon.providesUpdatesSecurely) > return false; > return aAddon.blocklistState != Ci.nsIBlocklistService.STATE_BLOCKED; > } > >+var gRDF; >+ >+function EM_R(aProperty) { >+ return gRDF.GetResource(PREFIX_NS_EM + aProperty); >+} >+ >+/** >+ * Converts an RDF literal, resource or integer into a string. >+ * >+ * @param aLiteral >+ * The RDF object to convert >+ * @return a string if the object could be converted or null >+ */ >+function getRDFValue(aLiteral) { >+ if (aLiteral instanceof Ci.nsIRDFLiteral) >+ return aLiteral.Value; >+ if (aLiteral instanceof Ci.nsIRDFResource) >+ return aLiteral.Value; >+ if (aLiteral instanceof Ci.nsIRDFInt) >+ return aLiteral.Value; >+ return null; >+} >+ >+/** >+ * Gets an RDF property as a string >+ * >+ * @param aDs >+ * The RDF datasource to read the property from >+ * @param aSource >+ * The RDF reosurce to read the property from nit: aResource? >+ * @param aProperty >+ * The property to read >+ * @return a string if the property existed or null >+ */ >+function getRDFProperty(aDs, aSource, aProperty) { >+ return getRDFValue(aDs.GetTarget(aSource, EM_R(aProperty), true)); >+} >+ > /** > * Reads an AddonInternal object from an RDF stream. > * > * @param aUri > * The URI that the manifest is being read from > * @param aStream > * An open stream to read the RDF from > * @return an AddonInternal object > * @throws if the install manifest in the RDF stream is corrupt or could not > * be read > */ > function loadManifestFromRDF(aUri, aStream) { >- let RDF = Cc["@mozilla.org/rdf/rdf-service;1"]. >- getService(Ci.nsIRDFService); >- const RDFURI_INSTALL_MANIFEST_ROOT = "urn:mozilla:install-manifest"; >- const PREFIX_NS_EM = "http://www.mozilla.org/2004/em-rdf#"; >- >- function EM_R(aProperty) { >- return RDF.GetResource(PREFIX_NS_EM + aProperty); >- } >- >- function getValue(aLiteral) { >- if (aLiteral instanceof Ci.nsIRDFLiteral) >- return aLiteral.Value; >- if (aLiteral instanceof Ci.nsIRDFResource) >- return aLiteral.Value; >- if (aLiteral instanceof Ci.nsIRDFInt) >- return aLiteral.Value; >- return null; >- } >- >- function getProperty(aDs, aSource, aProperty) { >- return getValue(aDs.GetTarget(aSource, EM_R(aProperty), true)); >+ if (!gRDF) { >+ gRDF = Cc["@mozilla.org/rdf/rdf-service;1"]. >+ getService(Ci.nsIRDFService); > } How about just using a lazy getter instead?
Comment on attachment 439620 [details] [diff] [review] patch rev 1 r=me with nits addressed.
Attachment #439620 - Flags: review?(robert.bugzilla) → review+
Whiteboard: [rewrite][fixed-in-addonsmgr][needs-review] → [rewrite][fixed-in-addonsmgr]
Whiteboard: [rewrite][fixed-in-addonsmgr] → [rewrite][fixed-in-addonsmgr][needs-landing]
We should be verifying upgrades manually. http://hg.mozilla.org/mozilla-central/rev/500cea9ee7fd
Status: NEW → RESOLVED
Closed: 15 years ago
Flags: in-litmus?
Resolution: --- → FIXED
Whiteboard: [rewrite][fixed-in-addonsmgr][needs-landing] → [rewrite]
Target Milestone: --- → mozilla1.9.3a5
Dave, what's the best way for a manual test here? I would assume I have to search for at least one compatible and one not compatible version of an extension. Both would have to be installed in a build with the old manager and tested with the new addons manager afterward. Eventually we should simply put some example extensions into our Litmus test storage to have a passing manual test for the next couple of months.
I would suggest 4 extensions: 1. An extension that is incompatible with old and new 2. An extension that is compatible with old and new 3. An extension that is compatible with old and incompatible with new 4. An extension that is compatible with old and needs a compatibility update to be compatible with new
(In reply to comment #10) > 1. An extension that is incompatible with old and new > 2. An extension that is compatible with old and new > 3. An extension that is compatible with old and incompatible with new > 4. An extension that is compatible with old and needs a compatibility update to > be compatible with new Dave, we are thinking about to create our own extensions for testing. What would we have to do for case 4 to keep it passing even with upcoming Firefox releases? Something possible without having AMO involved? Marking as verified fixed because those cases have been proven to work in the last couple of months.
Status: RESOLVED → VERIFIED
Whiteboard: [rewrite] → [rewrite][AOMTestday]
(In reply to comment #11) > (In reply to comment #10) > > 1. An extension that is incompatible with old and new > > 2. An extension that is compatible with old and new > > 3. An extension that is compatible with old and incompatible with new > > 4. An extension that is compatible with old and needs a compatibility update to > > be compatible with new > > Dave, we are thinking about to create our own extensions for testing. What > would we have to do for case 4 to keep it passing even with upcoming Firefox > releases? Something possible without having AMO involved? A purely automated way would be to have some PHP script act as the update.rdf. In the add-ons updateURL you'd include some parameters for the script, the version of Firefox and the version of the add-on. The script could then output compatibility information that declared the add-on was compatible with the version of Firefox querying. Then when you install the add-on in the old version it looks up compatibility info and sees it is compatible, when the new version of Firefox runs it will see it as incompatible but on checking the update.rdf it will see new compatibility info.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: