Last Comment Bug 825237 - We should not save the ETag if the package is incorrect
: We should not save the ETag if the package is incorrect
Status: RESOLVED FIXED
[qa-]
:
Product: Core
Classification: Components
Component: DOM: Apps (show other bugs)
: Trunk
: ARM Gonk (Firefox OS)
: -- normal (vote)
: mozilla20
Assigned To: Julien Wajsberg [:julienw]
: Jason Smith [:jsmith]
Mentors:
Depends on: 824695
Blocks: app-install
  Show dependency treegraph
 
Reported: 2012-12-28 08:54 PST by Julien Wajsberg [:julienw]
Modified: 2013-01-13 18:59 PST (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
+
fixed
fixed
fixed


Attachments
patch v1 (2.50 KB, patch)
2012-12-29 06:25 PST, Julien Wajsberg [:julienw]
jonas: review+
Details | Diff | Review

Description Julien Wajsberg [:julienw] 2012-12-28 08:54:17 PST
Bug 820630 introduced the support of ETag.

However, we save the ETag value even if the package is bad. Therefore if there is an ETag, the user can retry the download, and the download will be somewhat applied in an inconsistent way.

STR:
* go to http://owapps.cloudfoundry.com
* install the packaged app
=> installation stopped, which is expected because the manifest is not right
* go to the homescreen and restart the download by pressing the icon
=> installation sort of finishes. Except the icon is not right, and the app can't be launched

Nominating but I don't think it should block v1 because the error is correctly written in the log at the first install.

However the fix should be easy (storing the |app.packageEtag| just after |app.appStatus|)
Comment 1 Jonas Sicking (:sicking) PTO Until July 5th 2012-12-28 14:48:59 PST
Julien: Can you take this?
Comment 2 Julien Wajsberg [:julienw] 2012-12-28 14:50:55 PST
Yep :) But not before Monday now.
Comment 3 Julien Wajsberg [:julienw] 2012-12-29 06:25:08 PST
Created attachment 696495 [details] [diff] [review]
patch v1

should be applied after the patch for bug 824695
Comment 4 Jonas Sicking (:sicking) PTO Until July 5th 2012-12-31 00:36:38 PST
https://hg.mozilla.org/integration/mozilla-inbound/rev/90cd09c695ed
Comment 5 Julien Wajsberg [:julienw] 2012-12-31 02:58:18 PST
To whoever will check in to other trees, this need to go in aurora and b2g18 as well.
Comment 6 Ryan VanderMeulen [:RyanVM] 2013-01-01 09:34:46 PST
https://hg.mozilla.org/mozilla-central/rev/90cd09c695ed
Comment 8 Ryan VanderMeulen [:RyanVM] 2013-01-01 12:49:20 PST
(In reply to Julien Wajsberg [:julienw] from comment #5)
> To whoever will check in to other trees, this need to go in aurora and b2g18
> as well.

(FWIW, for bugs marked blocking-basecamp+, I have bug queries to tell me this :)...)

Note You need to log in before you can comment on or make changes to this bug.