Closed Bug 826948 Opened 12 years ago Closed 12 years ago

preloaded external packaged app requires hard-to-determine package_path property

Categories

(Core Graveyard :: DOM: Apps, defect)

x86
All
defect
Not set
normal

Tracking

(blocking-basecamp:+, firefox19 wontfix, firefox20 wontfix, firefox21 fixed, b2g18 fixed)

RESOLVED FIXED
mozilla21
blocking-basecamp +
Tracking Status
firefox19 --- wontfix
firefox20 --- wontfix
firefox21 --- fixed
b2g18 --- fixed

People

(Reporter: myk, Assigned: fabrice)

References

Details

(Whiteboard: [qa-])

Attachments

(1 file)

In order for a preloaded external packaged app to get updated to a newer version available from a server, it appears to need to have a package_path property pointing to the updated version in its update.webapp file, according to build/webapp_manifests.js (and my testing of the update process with and without that property defined). But it's awfully hard to know what that URL is going to be for a third-party app whose updates will be served by Marketplace, since it changes every time an app is updated in the Marketplace. And it doesn't seem like it should be necessary, since that property is specified by the minimanifest, whose URL is available (specified in metadata.json). It's possible that I'm missing something, since I'm trying to reverse-engineer the implementation here while the folks who designed it are away, but it seems like an update check should download the minimanifest for these apps and use the package_path property in the minimanifest to determine the URL of the updated version to download. Otherwise, it's going to be hard to ship preloaded third-party apps that can ever update themselves to a newer version available on Marketplace. Which we want to do. So requesting blocking-basecamp.
Myk, what you describe as desired behavior is what we designed the code to do. Reading the update code again, I think that the bug is that we forgot to save the new update.webapp manifest in https://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.jsm#1117. Note that we do it properly for hosted app at https://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.jsm#1166
Attached patch patch (deleted) — Splinter Review
Myk, can you test with this patch?
Assignee: nobody → fabrice
Attachment #698377 - Flags: review?(myk)
Component: Gaia → DOM: Apps
Product: Boot2Gecko → Core
Version: unspecified → Trunk
Comment on attachment 698377 [details] [diff] [review] patch >+ // Store the new update manifest. >+ let dir = FileUtils.getDir(DIRECTORY_NAME, ["webapps", id], true, true); >+ let manFile = dir.clone(); >+ manFile.append("update.webapp"); >+ this._writeFile(manFile, JSON.stringify(aManifest), function() { }); It works! Except that updatePackagedApp() isn't bound to DOMApplicationRegistry, so the `this` reference in the last line throws "TypeError: this is undefined". updateHostedApp() also references `this`, so it gets invoked with call(): updateHostedApp.call(this, manifest); But updatePackagedApp() is just called directly: updatePackagedApp(manifest); To fix the problem, invoke updatePackagedApp() with call(): updatePackagedApp.call(this, manifest); r=myk with that change!
Attachment #698377 - Flags: review?(myk) → review+
blocking-basecamp: ? → +
Keywords: checkin-needed
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Whiteboard: [qa-]
Whiteboard: [qa-]
Target Milestone: --- → mozilla21
Whiteboard: [qa-]
No longer blocks: market-packaged-apps
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: