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)
Tracking
(blocking-basecamp:+, firefox19 wontfix, firefox20 wontfix, firefox21 fixed, b2g18 fixed)
People
(Reporter: myk, Assigned: fabrice)
References
Details
(Whiteboard: [qa-])
Attachments
(1 file)
(deleted),
patch
|
myk
:
review+
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 1•12 years ago
|
||
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
Assignee | ||
Comment 2•12 years ago
|
||
Myk, can you test with this patch?
Assignee: nobody → fabrice
Attachment #698377 -
Flags: review?(myk)
Updated•12 years ago
|
Component: Gaia → DOM: Apps
Product: Boot2Gecko → Core
Version: unspecified → Trunk
Reporter | ||
Comment 3•12 years ago
|
||
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+
Updated•12 years ago
|
blocking-basecamp: ? → +
Updated•12 years ago
|
Keywords: checkin-needed
Blocks: b2g-app-updates
Assignee | ||
Comment 4•12 years ago
|
||
Keywords: checkin-needed
Assignee | ||
Comment 5•12 years ago
|
||
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Updated•12 years ago
|
Whiteboard: [qa-]
Comment 6•12 years ago
|
||
Whiteboard: [qa-]
Target Milestone: --- → mozilla21
Updated•12 years ago
|
status-b2g18:
--- → fixed
status-firefox19:
--- → wontfix
status-firefox20:
--- → wontfix
status-firefox21:
--- → fixed
Updated•12 years ago
|
Whiteboard: [qa-]
Updated•12 years ago
|
No longer blocks: market-packaged-apps
Updated•7 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•