Closed
Bug 827750
Opened 12 years ago
Closed 12 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
Categories
(Core Graveyard :: DOM: Apps, defect)
Tracking
(blocking-basecamp:+, firefox19 wontfix, firefox20 wontfix, firefox21 fixed, b2g18 fixed)
People
(Reporter: jsmith, Assigned: etienne)
References
Details
Attachments
(2 files, 2 obsolete files)
1.14 MB,
text/plain
|
Details | |
3.32 KB,
patch
|
fabrice
:
review+
|
Details | Diff | Splinter Review |
Build: B2G 18 1/8/2013
Device: Unagi
Steps:
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
Expected:
The app contents that launch should be the new version of the packaged app.
Actual:
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)
Reporter | ||
Updated•12 years ago
|
blocking-basecamp: --- → ?
Reporter | ||
Updated•12 years ago
|
Blocks: market-packaged-apps, b2g-app-updates
Comment 1•12 years ago
|
||
Etienne could you check if it's still reproducible and if it isn't a dup ?
Assignee: nobody → etienne
Whiteboard: DUPEME
Reporter | ||
Comment 2•12 years ago
|
||
It's not a dupe. There's no bug open about this. See the other associated bugs for the discussion on this.
Whiteboard: DUPEME
Assignee | ||
Comment 3•12 years ago
|
||
Still reproducible, and probably gecko.
(I added some logs on the gaia side, we call |mgmt.applyDownload(app)| with no problem).
Updated•12 years ago
|
Assignee: etienne → fabrice
blocking-basecamp: ? → +
Component: Gaia::System → DOM: Apps
Product: Boot2Gecko → Core
Assignee | ||
Comment 4•12 years ago
|
||
We're not passing this condition when calling applyDownload:
applyDownload: function(aApp) {
if (!aApp.readyToApplyDownload) {
(in Webapp.js)
Assignee | ||
Comment 5•12 years ago
|
||
(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...
Assignee | ||
Comment 6•12 years ago
|
||
Okay, thanks to Jason we now have some HTTP Logging.
I installed the app, then updated it ->
1074189560[40404160]: uri=http://gomette.com/webapps/apps/packagedApp/application.zip
1074189560[40404160]: uri=http://gomette.com/webapps/apps/packagedApp/application.zip
1074189560[40404160]: GET /webapps/apps/packagedApp/application.zip 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=http://gomette.com/webapps/apps/packagedApp/application.zip]
1074189560[40404160]: uri=http://gomette.com/webapps/apps/packagedApp/application.zip
1074189560[40404160]: uri=http://gomette.com/webapps/apps/packagedApp/application.zip
23797880[47b900f0]: ParseContentType [type=application/zip]
1074189560[40404160]: nsHttpChannel::ReadFromCache [this=4b3a7c00] Using cached copy of: http://gomette.com/webapps/apps/packagedApp/application.zip
Here I'm greping on "application.zip", and it looks very much like the second time we're reading from cache instead of fetching the updated application.zip.
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?
Assignee | ||
Comment 7•12 years ago
|
||
Comment 8•12 years ago
|
||
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 application.zip in the cache in the first place (seems like a waste of disk space?)
Assignee | ||
Comment 9•12 years ago
|
||
Assignee: fabrice → etienne
Attachment #699210 -
Flags: superreview?(fabrice)
Assignee | ||
Updated•12 years ago
|
Attachment #699210 -
Flags: superreview?(fabrice) → review?(fabrice)
Comment 10•12 years ago
|
||
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-
Assignee | ||
Comment 11•12 years ago
|
||
Using the inhibit flag instead
Attachment #699210 -
Attachment is obsolete: true
Attachment #699210 -
Flags: review?(fabrice)
Attachment #699245 -
Flags: review?(fabrice)
Comment 12•12 years ago
|
||
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)
Assignee | ||
Comment 13•12 years ago
|
||
inhibit all the things
Attachment #699245 -
Attachment is obsolete: true
Attachment #699615 -
Flags: review?(fabrice)
Updated•12 years ago
|
Attachment #699615 -
Flags: review?(fabrice) → review+
Assignee | ||
Updated•12 years ago
|
Keywords: checkin-needed
Comment 14•12 years ago
|
||
Keywords: checkin-needed
Comment 15•12 years ago
|
||
Comment 16•12 years ago
|
||
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
Reporter | ||
Comment 17•12 years ago
|
||
Verified - I got an update to happen to apply the update correctly.
Status: RESOLVED → VERIFIED
Keywords: verifyme
Updated•12 years ago
|
status-firefox21:
--- → fixed
Reporter | ||
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
•