Closed Bug 827750 Opened 8 years ago Closed 8 years ago

Installing a privileged packaged app, updating it on the server, applying the update, launch app - privileged app is still the old version even after restart


(Core Graveyard :: DOM: Apps, defect)

Gonk (Firefox OS)
Not set


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

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


(Reporter: jsmith, Assigned: etienne)




(2 files, 2 obsolete files)

Build: B2G 18 1/8/2013
Device: Unagi


1. Install a privileged packaged app from marketplace
2. Update that packaged app to a new version
3. Check for updates (manual or automatic)
4. Apply the packaged app update
5. Launch the app


The app contents that launch should be the new version of the packaged app.


The app contents that launch uses the old version of the packaged app.

Additional Notes:

This is an obvious blocker - the feature doesn't work. Interestingly enough, here's we've found so far after talking with Fabrice, Myk, and Etienne:

* This only reproduces with installed packaged apps. This does not reproduce with preloads.
* The issue *might* be a problem in Gaia because we might not be applying the update correctly (i.e. the way we call the function)
blocking-basecamp: --- → ?
Etienne could you check if it's still reproducible and if it isn't a dup ?
Assignee: nobody → etienne
Whiteboard: DUPEME
It's not a dupe. There's no bug open about this. See the other associated bugs for the discussion on this.
Whiteboard: DUPEME
Still reproducible, and probably gecko.
(I added some logs on the gaia side, we call |mgmt.applyDownload(app)| with no problem).
Assignee: etienne → fabrice
blocking-basecamp: ? → +
Component: Gaia::System → DOM: Apps
Product: Boot2Gecko → Core
We're not passing this condition when calling applyDownload:

  applyDownload: function(aApp) {
    if (!aApp.readyToApplyDownload) {

(in Webapp.js)
(In reply to Etienne Segonzac (:etienne) from comment #4)
> We're not passing this condition when calling applyDownload:
>   applyDownload: function(aApp) {
>     if (!aApp.readyToApplyDownload) {
> (in Webapp.js)

Mmmhh... I always reproduce the app not being updated, but just went trough this condition with no problem...
Okay, thanks to Jason we now have some HTTP Logging.
I installed the app, then updated it ->

1074189560[40404160]: uri=
1074189560[40404160]: uri=
1074189560[40404160]:   GET /webapps/apps/packagedApp/ HTTP/1.1
23793168[40404400]: nsHttpTransaction::ParseLine [Content-Type: application/zip]
23793168[40404400]: ParseContentType [type=application/zip]
23793168[40404400]:   Content-Type: application/zip
1074189560[40404160]: Preparing to write data into the cache [uri=]
1074189560[40404160]: uri=
1074189560[40404160]: uri=
23797880[47b900f0]: ParseContentType [type=application/zip]
1074189560[40404160]: nsHttpChannel::ReadFromCache [this=4b3a7c00] Using cached copy of:

Here I'm greping on "", and it looks very much like the second time we're reading from cache instead of fetching the updated

So we're updating the app with... the current version.

I'll attach the complete HTTP log, I don't know who can take this?
Attached file http log
Apparently the one-line fix here is to set nsIRequest.VALIDATE_ALWAYS.  That may work, but I'm curious as to why the caching logic didn't even ask the webserver for a last-modified time.  I'd need to see a wireshark log to know for sure.

I wonder if we should also be setting INHIBIT_CACHING so that we don't store the in the cache in the first place (seems like a waste of disk space?)
Attached patch Patch proposal (obsolete) — Splinter Review
Assignee: fabrice → etienne
Attachment #699210 - Flags: superreview?(fabrice)
Attachment #699210 - Flags: superreview?(fabrice) → review?(fabrice)
Comment on attachment 699210 [details] [diff] [review]
Patch proposal

Review of attachment 699210 [details] [diff] [review]:

Etienne confirms that things work if we use just INHIBIT_CACHING alone.  I'd prefer to do that--setting VALIDATE_ALWAYS seems superfluous and a bit of a hack.  In general if we wind ourselves using VALIDATE_ALWAYS to work around the cache not doing what we think it should do, we should investigate what's going on.
Attachment #699210 - Flags: feedback-
Attached patch Patch v2 (obsolete) — Splinter Review
Using the inhibit flag instead
Attachment #699210 - Attachment is obsolete: true
Attachment #699210 - Flags: review?(fabrice)
Attachment #699245 - Flags: review?(fabrice)
Comment on attachment 699245 [details] [diff] [review]
Patch v2

Review of attachment 699245 [details] [diff] [review]:

Can you do the same in other places where we currently use VALIDATE_ALWAYS?
Attachment #699245 - Flags: review?(fabrice)
Attached patch Patch v3Splinter Review
inhibit all the things
Attachment #699245 - Attachment is obsolete: true
Attachment #699615 - Flags: review?(fabrice)
Attachment #699615 - Flags: review?(fabrice) → review+
Keywords: checkin-needed
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
Keywords: verifyme
QA Contact: jsmith
Verified - I got an update to happen to apply the update correctly.
Keywords: verifyme
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.