Closed
Bug 809948
Opened 12 years ago
Closed 12 years ago
[Webapps] Check for enough device storage before starting app download
Categories
(Core Graveyard :: DOM: Apps, defect)
Core Graveyard
DOM: Apps
Tracking
(blocking-basecamp:+, firefox18 fixed, firefox19 fixed)
People
(Reporter: ferjm, Assigned: ferjm)
References
Details
(Whiteboard: [qa-])
Attachments
(2 files, 3 obsolete files)
(deleted),
patch
|
fabrice
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
fabrice
:
review+
|
Details | Diff | Splinter Review |
Currently, we have to start downloading the app and wait for it to fail due to insufficient device storage before triggering the 'ondownloaderror' event. We probably want to check that there is enough device storage *before* starting to download any data.
Updated•12 years ago
|
Component: General → DOM: Apps
Product: Boot2Gecko → Core
Assignee | ||
Updated•12 years ago
|
Assignee: nobody → ferjmoreno
Updated•12 years ago
|
blocking-basecamp: --- → ?
Comment 1•12 years ago
|
||
Should cover the install and update cases. Blocking+ for required feature work: AppUpdates-005 "As a user, I want the system to check that there is enough storage before beginning to download apps, so that I can avoid "not enough storage" errors."
blocking-basecamp: ? → +
Assignee | ||
Updated•12 years ago
|
Blocks: app-install
Assignee | ||
Comment 2•12 years ago
|
||
With this patch the platform checks if there is enough free device storage before starting to download a package and triggers a 'ondownloaderror' in case that there is not enough space. I've made the patch to simply trigger the 'ondownloaderror' because that is what we agreed to do, but this way the UI won't know if the download failed because of insufficient device storage, a connection error or whatever. If we want to show the specific cause of the download failure we might want to either add more information to 'ondownloaderror' or trigger a new type of event. What do you think?
Attachment #681440 -
Flags: review?(fabrice)
Assignee | ||
Comment 3•12 years ago
|
||
Attachment #681440 -
Attachment is obsolete: true
Attachment #681440 -
Flags: review?(fabrice)
Attachment #681441 -
Flags: review?(fabrice)
Assignee | ||
Comment 5•12 years ago
|
||
Comment on attachment 681457 [details] Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/6401 This patch allows the system app to have permissions for accessing apps device storage.
Attachment #681457 -
Flags: review?(fabrice)
Assignee | ||
Comment 6•12 years ago
|
||
(In reply to Fernando Jiménez Moreno [:ferjm] from comment #2) > Created attachment 681440 [details] [diff] [review] > v1 > I've made the patch to simply trigger the 'ondownloaderror' because that is > what we agreed to do, but this way the UI won't know if the download failed > because of insufficient device storage, a connection error or whatever. If > we want to show the specific cause of the download failure we might want to > either add more information to 'ondownloaderror' or trigger a new type of > event. What do you think? Please, ignore this comment. I've just realized that the error details are exposed via 'mozIDOMApplication.downloadError' :)
Assignee | ||
Comment 7•12 years ago
|
||
Added the fix to include the app manifest along with the 'ondownloaderror' event.
Attachment #681441 -
Attachment is obsolete: true
Attachment #681441 -
Flags: review?(fabrice)
Attachment #681555 -
Flags: review?(fabrice)
Assignee | ||
Updated•12 years ago
|
Attachment #681555 -
Attachment is patch: true
Comment 8•12 years ago
|
||
Comment on attachment 681555 [details] [diff] [review] v2 Review of attachment 681555 [details] [diff] [review]: ----------------------------------------------------------------- ::: dom/apps/src/Webapps.jsm @@ +1360,5 @@ > + onProgress: function notifProgress(aRequest, aContext, > + aProgress, aProgressMax) { > + debug("onProgress: " + aProgress + "/" + aProgressMax); > + app.progress = aProgress; > + DOMApplicationRegistry.broadcastMessage("Webapps:PackageEvent", Nit: now that you have "self", you can use it there also.
Attachment #681555 -
Flags: review?(fabrice) → review+
Assignee | ||
Comment 9•12 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/d95d4e953df5
Comment 10•12 years ago
|
||
Marking leave-open until the PR for Gaia lands after the gecko pieces land.
Whiteboard: [leave-open]
Comment 12•12 years ago
|
||
If storage space check fails during app install, the user needs to be prompted. I've created a bug for that here: https://bugzilla.mozilla.org/show_bug.cgi?id=812369 This is per the Oct 11 spec, page 8, here: https://www.dropbox.com/sh/b0kyykhzcfkpm8b/ReFTX_E72X
Comment 13•12 years ago
|
||
Comment on attachment 681457 [details] Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/6401 Hm, I really don't like that we have to give a content permission to make some chrome content work. I understand that this because you used browser.contentWindow.navigator, but we need to fix that. Can we just use wm.getMostRecentWindow("...").navigator instead ?
Attachment #681457 -
Flags: review?(fabrice) → review-
Assignee | ||
Comment 14•12 years ago
|
||
You are absolutely right. Thanks!
Attachment #681457 -
Attachment is obsolete: true
Attachment #682427 -
Flags: review?(fabrice)
Updated•12 years ago
|
Attachment #682427 -
Flags: review?(fabrice) → review+
Assignee | ||
Comment 15•12 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/d0562b40fc01
Assignee | ||
Comment 17•12 years ago
|
||
With the follow up landed there is no need for any other Gaia patch, so I am removing the [leave-open] flag and closing as fixed.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Whiteboard: [leave-open]
Comment 18•12 years ago
|
||
https://hg.mozilla.org/releases/mozilla-beta/rev/7332ccca94de https://hg.mozilla.org/releases/mozilla-beta/rev/3bac8a2ea386
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
•