Closed Bug 838909 Opened 12 years ago Closed 7 years ago

[Intermittent] If you run out of space when downloading an app, the wifi can enter a lame network state, resulting in bug 830447

Categories

(Firefox OS Graveyard :: Wifi, defect)

Product:
Firefox OS Graveyard
Component:
Wifi
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(tracking-b2g:backlog, b2g18+ affected, b2g18-v1.0.1 wontfix)

Status:
RESOLVED WONTFIX
Project Flags:
tracking-b2g backlog
Tracking Flags:
Tracking Status
b2g18 + affected
b2g18-v1.0.1 --- wontfix

People

(Reporter: jsmith, Unassigned)

References

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

Logcat with NSPR logging
16.73 KB, text/plain
Details
Build: B2G 18 2/6/2013 Device: Unagi Steps: 1. Reduce your remaining space down to 18 MB 2. Start installing an app that's 20 MB ** Note - If packaged, install this without the size parameter specified 3. Wait patiently Expected: We should fail with an insufficient storage error. Actual: We get hung during download usually (highly probable, but not always). When this happens, let's say I restart my phone. In one case, I ended up with an icon on the homescreen making it "appear" like the app was installed, but clicking it does nothing. On a different case, I got the generic icon on the homescreen that when clicked, would fail download immediately. Something tells me we've entered a bad state... During download I have: "{d9e3a75b-5a9c-447c-8a0c-a1afc7a3faa5}": { "name": "Large Appcache Preload", "csp": "", "installOrigin": "http://mozqa.com", "origin": "http://mozqa.com", "receipts": [], "installTime": 1360200324688, "manifestURL": "http://mozqa.com/webapi-permissions-tests/largeappcacheprelo ad.webapp", "appStatus": 1, "removable": true, "id": "{d9e3a75b-5a9c-447c-8a0c-a1afc7a3faa5}", "localId": 1022, "basePath": "/data/local/webapps", "progress": 0, "installState": "pending", "downloadAvailable": true, "downloading": true, "readyToApplyDownload": false, "downloadSize": 0, "lastUpdateCheck": 1360200324688, "etag": "\"254048-19d-4d400e45978c0\"", "manifestHash": "0e413f01994d0b1700cf0bf25af47bbd", "installerAppId": 1011, "installerIsBrowser": true } After restarting the phone with the generic icon I have: "{d9e3a75b-5a9c-447c-8a0c-a1afc7a3faa5}": { "name": "Large Appcache Preload", "csp": "", "installOrigin": "http://mozqa.com", "origin": "http://mozqa.com", "receipts": [], "installTime": 1360200324688, "manifestURL": "http://mozqa.com/webapi-permissions-tests/largeappcacheprelo ad.webapp", "appStatus": 1, "removable": true, "id": "{d9e3a75b-5a9c-447c-8a0c-a1afc7a3faa5}", "localId": 1022, "basePath": "/data/local/webapps", "progress": 6701052, "installState": "pending", "downloadAvailable": false, "downloading": false, "readyToApplyDownload": false, "downloadSize": 0, "lastUpdateCheck": 1360200324688, "etag": "\"254048-19d-4d400e45978c0\"", "manifestHash": "0e413f01994d0b1700cf0bf25af47bbd", "installerAppId": 1011, "installerIsBrowser": true }
Blocks: app-install
blocking-b2g: --- → tef?
Keywords: regression
The big weird thing I'm seeing here is that progress value has ended up in an odd state - the first has 0, which makes sense obviously. The second has 6701052, which means that something partially downloaded, but not fully. Something strange is going on here...
Packaged app out of space test for comparison. During download: "{7b64cdd9-51a1-4cf6-9690-d265ce030118}": { "name": "Test Large Web Packaged App", "csp": "", "installOrigin": "http://mozqa.com", "origin": "app://{7b64cdd9-51a1-4cf6-9690-d265ce030118}", "receipts": [], "installTime": 1360201011845, "manifestURL": "http://mozqa.com/webapi-permissions-tests/largepackagedappwi thsize.manifest", "appStatus": 1, "removable": true, "id": "{7b64cdd9-51a1-4cf6-9690-d265ce030118}", "localId": 1023, "basePath": "/data/local/webapps", "progress": 0, "installState": "pending", "downloadAvailable": false, "downloading": false, "readyToApplyDownload": false, "downloadSize": 20000467, "lastUpdateCheck": 1360201011845, "etag": "\"25404a-171-4d400e45978c0\"", "manifestHash": "383ae0174d765825952666be20005a0b", "installerAppId": 1011, "installerIsBrowser": true } After phone restart: "{7b64cdd9-51a1-4cf6-9690-d265ce030118}": { "name": "Test Large Web Packaged App", "csp": "", "installOrigin": "http://mozqa.com", "origin": "app://{7b64cdd9-51a1-4cf6-9690-d265ce030118}", "receipts": [], "installTime": 1360201011845, "manifestURL": "http://mozqa.com/webapi-permissions-tests/largepackagedappwi thsize.manifest", "appStatus": 1, "removable": true, "id": "{7b64cdd9-51a1-4cf6-9690-d265ce030118}", "localId": 1023, "basePath": "/data/local/webapps", "progress": 0, "installState": "pending", "downloadAvailable": false, "downloading": false, "readyToApplyDownload": false, "downloadSize": 20000467, "lastUpdateCheck": 1360201011845, "etag": "\"25404a-171-4d400e45978c0\"", "manifestHash": "383ae0174d765825952666be20005a0b", "installerAppId": 1011, "installerIsBrowser": true }
+Doug in case something blew up in the device storage dept
I have a strong hunch something in the progress events is getting hung. I've managed to even reproduce this with a large hosted app preloading appcache with space on the device after the device returned from a low space state. Something really strange is going on here.
was this caused by 834595?
While investigating Bug 838823, I've seen that downloadSize is sometimes reset to 0 at (what I think) inappropriate times. For example, when we check for an update, I think this is reset to 0 in some cases... without even checking if a download is current.
(In reply to Doug Turner (:dougt) from comment #5) > was this caused by 834595? I don't think, we fixed that in bug 836045
We're marking as tef+ specifically to resolve the fact that the user can't ever install the application after getting into this situation. Our goal should be to make sure this works after uninstall or on phone restart (lowest risk fix wins).
Assignee: nobody → ferjmoreno
blocking-b2g: tef? → tef+
Summary: Installing an app that will not fit on the device during download gets hung during download → If you run out of space when downloading an app, you can never install the app
(hoping you have the time to resolve this Fernando)
Note that this may be related to Bug 838823 (fix in review), Bug 839071 (for the fact that we have an icon as if it was installed), and Bug 838337 (fix ready to be checked in). I think uninstalling/reinstalling the app would work anyway though... jsmith did you try this ?
(In reply to Julien Wajsberg [:julienw] from comment #10) > Note that this may be related to Bug 838823 (fix in review), Bug 839071 (for > the fact that we have an icon as if it was installed), and Bug 838337 (fix > ready to be checked in). > > I think uninstalling/reinstalling the app would work anyway though... jsmith > did you try this ? Yes, that didn't work for me with a hosted app with appcache.
Is this bug progressing towards a fix?
Flags: needinfo?
I am looking into it right now. Sorry for the delay, but I realized today that this bug was assigned to me on comment 8.
Flags: needinfo?
(In reply to Jason Smith [:jsmith] from comment #0) > Expected: > > We should fail with an insufficient storage error. From my tests I can see that we do fail with that error if the download is not stopped unexpectedly for other reasons. > > Actual: > > We get hung during download usually (highly probable, but not always). When > this happens, let's say I restart my phone. In one case, I ended up with an > icon on the homescreen making it "appear" like the app was installed, but > clicking it does nothing. That's because of the issue mentioned in bug 839071 > On a different case, I got the generic icon on the > homescreen that when clicked, would fail download immediately. Something > tells me we've entered a bad state... That's because we are setting "downloadAvailable" to false, which I think is correct in this case. See my explanation below. The problem that I could reproduce (only for packaged apps so far) is not related with insufficient storage in the device but with large downloads with a not so good connection (I could only reproduce it while tethering from other device). The issue that I am seeing (not easy to reproduce) is that, for some reason that I still don't know, we are stopping the HTTP request in the middle of the download. Note the "onStopRequest 0" from this log: I/Gecko ( 109): -*-*- Webapps.jsm : onProgress: 3312057/98948661 I/Gecko ( 109): -*-*- Webapps.jsm : Saving /data/local/webapps/webapps.json I/Gecko ( 109): -*-*- FreeSpaceWatcher.jsm : Free bytes: 18366464 I/Gecko ( 109): -*-*- Webapps.jsm : onProgress: 3405957/98948661 I/Gecko ( 109): -*-*- Webapps.jsm : Saving /data/local/webapps/webapps.json I/Gecko ( 109): -*-*- FreeSpaceWatcher.jsm : Free bytes: 18280448 I/Gecko ( 109): -*-*- Webapps.jsm : onProgress: 3524529/98948661 I/Gecko ( 109): -*-*- Webapps.jsm : Saving /data/local/webapps/webapps.json I/Gecko ( 109): -*-*- FreeSpaceWatcher.jsm : Free bytes: 18145280 I/Gecko ( 109): -*-*- Webapps.jsm : onStopRequest 0 I/Gecko ( 109): -*-*- FreeSpaceWatcher.jsm : Free bytes: 18083840 I/Gecko ( 109): -*-*- Webapps.jsm : packageHash=a893832e589c17072eb1a8a96ebf0b9c I/Gecko ( 109): -*-*- Webapps.jsm : aRv 2152857611 I/Gecko ( 109): -*-*- Webapps.jsm : Cleanup: INVALID_SIGNATURE I/Gecko ( 109): -*-*- AppDownloadManager.jsm : Getting http://apptester.eu01.aws.af.cm/apps/bigPackagedApp/manifest.webapp I/Gecko ( 109): -*-*- Webapps.jsm : Saving /data/local/webapps/webapps.json I/Gecko ( 109): -*-*- AppDownloadManager.jsm : Removing http://apptester.eu01.aws.af.cm/apps/bigPackagedApp/manifest.webapp I/Gecko ( 109): -*-*- AppDownloadManager.jsm : Removing http://apptester.eu01.aws.af.cm/apps/bigPackagedApp/manifest.webapp As you can see, the file is not fully downloaded when we receive the notification of the stopped request, which makes the signature validation fail and leave the app with the following state: "{65e8a42f-9c2f-4738-945e-ccbfc065a520}": { "name": "Big Packaged App", "csp": "", "installOrigin": "http://apptester.eu01.aws.af.cm", "origin": "app://{65e8a42f-9c2f-4738-945e-ccbfc065a520}", "receipts": [], "installTime": 1360746449611, "manifestURL": "http://apptester.eu01.aws.af.cm/apps/bigPackagedApp/manifest.webapp", "appStatus": 1, "removable": true, "id": "{65e8a42f-9c2f-4738-945e-ccbfc065a520}", "localId": 1025, "basePath": "/data/local/webapps", "progress": 3625413, "installState": "pending", "downloadAvailable": false, "downloading": false, "readyToApplyDownload": false, "downloadSize": 0, "lastUpdateCheck": 1360746449612, "etag": "4fa85a90282b927fcc428c943127bfca", "manifestHash": "ccf0c88b9451c9b701a87b23afbe0590", "installerAppId": 1002, "installerIsBrowser": true, "retryingDownload": true } IMO the app state is correct. We should not be setting 'downloadAvailable' to true here if the file is corrupted (we need to notify about this, not about an invalid signature though). The current app state will make the download fail as soon as the user clicks in the icon again. Uninstalling the app would allow its download again. I only added a check for the NS_ERROR_FILE_CORRUPTED (Note the "aRv 2152857611" log above. http://james-ross.co.uk/mozilla/misc/nserror?0x8052000B) to throw the appropriate error, but that does not solve the issue. I am gonna need some help here to check why the download is being cut in the middle of the process and reported as a success. Not sure if Jason or Honza are familiar with this HTTP request code. (We are getting the unexpected stopped request notification at https://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.jsm#2152). The same download fails as expected with the INSUFFICIENTE_STORAGE error when the request is not interrupted: I/Gecko (10199): -*-*- Webapps.jsm : onProgress: 25196037/98948661 I/Gecko (10199): -*-*- Webapps.jsm : OnStatus: 2152398854 I/Gecko (10199): -*-*- Webapps.jsm : onProgress: 25197425/98948661 I/Gecko (10199): -*-*- Webapps.jsm : OnStatus: 2152398854 I/Gecko (10199): -*-*- Webapps.jsm : onProgress: 25202977/98948661 I/Gecko (10199): -*-*- Webapps.jsm : OnStatus: 2152398854 I/Gecko (10199): -*-*- Webapps.jsm : onProgress: 25204365/98948661 I/Gecko (10199): -*-*- FreeSpaceWatcher.jsm : Free bytes: 5140480 I/Gecko (10199): -*-*- FreeSpaceWatcher.jsm : New status: full I/Gecko (10199): -*-*- AppDownloadManager.jsm : Disk space is now full I/Gecko (10199): -*-*- Webapps.jsm : cancelDownload http://apptester.eu01.aws.af.cm/apps/bigPackagedApp/manifest.webapp I/Gecko (10199): -*-*- AppDownloadManager.jsm : Getting http://apptester.eu01.aws.af.cm/apps/bigPackagedApp/manifest.webapp I/Gecko (10199): -*-*- Webapps.jsm : Saving /data/local/webapps/webapps.json I/Gecko (10199): -*-*- AppDownloadManager.jsm : Removing http://apptester.eu01.aws.af.cm/apps/bigPackagedApp/manifest.webapp I/Gecko (10199): -*-*- Webapps.jsm : onStopRequest 2152398850 I/Gecko (10199): -*-*- Webapps.jsm : Cleanup: NETWORK_ERROR The error is shown in Gaia and the app state is correct at that point (the user can restart the download by clicking in the app icon): "{1aada570-eb83-4905-98aa-b07202956c70}": { "name": "Big Packaged App", "csp": "", "installOrigin": "http://apptester.eu01.aws.af.cm", "origin": "app://{1aada570-eb83-4905-98aa-b07202956c70}", "receipts": [], "installTime": 1360751569750, "manifestURL": "http://apptester.eu01.aws.af.cm/apps/bigPackagedApp/manifest.webapp", "appStatus": 1, "removable": true, "id": "{1aada570-eb83-4905-98aa-b07202956c70}", "localId": 1022, "basePath": "/data/local/webapps", "progress": 0, "installState": "pending", "downloadAvailable": true, "downloading": false, "readyToApplyDownload": false, "downloadSize": 0, "lastUpdateCheck": 1360751569750, "etag": "4fa85a90282b927fcc428c943127bfca", "manifestHash": "ccf0c88b9451c9b701a87b23afbe0590", "installerAppId": 1002, "installerIsBrowser": true, "isCanceling": true } Same thing for hosted apps: Gecko (10199): -*-*- Webapps.jsm : Offline cache state change for http://apptester.eu01.aws.af.cm : 8 I/Gecko (10199): -*-*- Webapps.jsm : Offline cache state change for http://apptester.eu01.aws.af.cm : 8 I/Gecko (10199): -*-*- FreeSpaceWatcher.jsm : Free bytes: 5058560 I/Gecko (10199): -*-*- FreeSpaceWatcher.jsm : New status: full I/Gecko (10199): -*-*- AppDownloadManager.jsm : Disk space is now full I/Gecko (10199): -*-*- Webapps.jsm : cancelDownload http://apptester.eu01.aws.af.cm/apps/bigHostedApp/manifest.webapp I/Gecko (10199): -*-*- AppDownloadManager.jsm : Getting http://apptester.eu01.aws.af.cm/apps/bigHostedApp/manifest.webapp I/Gecko (10199): -*-*- Webapps.jsm : Saving /data/local/webapps/webapps.json I/Gecko (10199): -*-*- AppDownloadManager.jsm : Removing http://apptester.eu01.aws.af.cm/apps/bigHostedApp/manifest.webapp I/Gecko (10199): -*-*- Webapps.jsm : Offline cache state change for http://apptester.eu01.aws.af.cm : 1 I/Gecko (10199): -*-*- AppDownloadManager.jsm : Removing http://apptester.eu01.aws.af.cm/apps/bigHostedApp/manifest.webapp I/Gecko (10199): -*-*- Webapps.jsm : Offlinecache setError to APP_CACHE_DOWNLOAD_ERROR I/Gecko (10199): -*-*- Webapps.jsm : Saving /data/local/webapps/webapps.json "{6da3dd91-4863-47e7-bae4-30e8aee6a340}": { "name": "BigHostedApp", "csp": "", "installOrigin": "http://apptester.eu01.aws.af.cm", "origin": "http://apptester.eu01.aws.af.cm", "receipts": [], "installTime": 1360752645808, "manifestURL": "http://apptester.eu01.aws.af.cm/apps/bigHostedApp/manifest.webapp", "appStatus": 1, "removable": true, "id": "{6da3dd91-4863-47e7-bae4-30e8aee6a340}", "localId": 1023, "basePath": "/data/local/webapps", "progress": 0, "installState": "pending", "downloadAvailable": true, "downloading": false, "readyToApplyDownload": false, "downloadSize": 0, "lastUpdateCheck": 1360752645808, "etag": "2f8241624ee25077d2c7ccabfedea4a3", "manifestHash": "bbafaf6dbd1228e49d5b552d63102097", "installerAppId": 1002, "installerIsBrowser": true }
Flags: needinfo?(jduell.mcbugs)
Flags: needinfo?(honzab.moz)
(In reply to Fernando Jiménez Moreno [:ferjm] from comment #14) > > The problem that I could reproduce (only for packaged apps so far) is not > related with insufficient storage in the device but with large downloads > with a not so good connection (I could only reproduce it while tethering > from other device). The issue that I am seeing (not easy to reproduce) is > that, for some reason that I still don't know, we are stopping the HTTP > request in the middle of the download. That sounds like Bug 830447. > > IMO the app state is correct. We should not be setting 'downloadAvailable' > to true here if the file is corrupted (we need to notify about this, not > about an invalid signature though). The current app state will make the > download fail as soon as the user clicks in the icon again. Uninstalling the > app would allow its download again. Bug 839491 should make all this more clear for the user. I'm not sure this will go into v1 though.
(In reply to Julien Wajsberg [:julienw] from comment #15) > (In reply to Fernando Jiménez Moreno [:ferjm] from comment #14) > > > > > The problem that I could reproduce (only for packaged apps so far) is not > > related with insufficient storage in the device but with large downloads > > with a not so good connection (I could only reproduce it while tethering > > from other device). The issue that I am seeing (not easy to reproduce) is > > that, for some reason that I still don't know, we are stopping the HTTP > > request in the middle of the download. > > That sounds like Bug 830447. I don't think so. That bug mentions a download getting stuck. The issue that I am seeing is the download being cut unexpectedly and reported as a successful download. > > > > > IMO the app state is correct. We should not be setting 'downloadAvailable' > > to true here if the file is corrupted (we need to notify about this, not > > about an invalid signature though). The current app state will make the > > download fail as soon as the user clicks in the icon again. Uninstalling the > > app would allow its download again. > > Bug 839491 should make all this more clear for the user. I'm not sure this > will go into v1 though. Yes, that would be a better UX. I would say that removing the icon would be even better, but that is a different discussion.
This log contains the app state, the logcat output and the last part of the NSPR log.
Hmm...I'm wondering if we are describing the same bug. It sorta sounds like we are describing something similar, but what I hit showed progress = 0 during download at some point - but that might be something similar to what you are describing with the "stop request." That resulted in a hang during download. It isn't the weak network as you describe too. I could go do more testing if need be. But when I was testing this, it reproduced pretty consistently.
So I'm trying to follow the bug here. Here's what I'm hearing (correct me if I'm wrong): - We initially thought this was a bug for apps failing and being uninstallable afterward if the disk is full. Now we think that case works (error msg shown and app can be installed OK later if space cleared up for it). - Now this has morphed into a bug about the HTTP connection stopping before the download is complete, and at that point we can't install it again. (If true we should change the title of this bug) > The issue that I am seeing is the download being cut unexpectedly and reported > as a successful download. > ... > (We are getting the unexpected stopped request notification at > https://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.jsm#2152). So are you seeing status=NS_OK here, or something else? I do see in the NSPR log that we've got a transaction (this=47e977f0) that seems to be doing the download, then another transaction/pipeline gets canceled (reason=80004004 == NS_ERROR_ABORT), after which the download transaction is ending, with NS_OK status: nsHttpTransaction::HandleContent [this=47e977f0 count=124 read=124 mContentRead=7639268 mContentLength=98948661] nsHttpConnection::CloseTransaction[this=489e5110 trans=471f1104 reason=80470002] nsHttpPipeline::Close [this=471f1100 reason=0] nsHttpTransaction::Close [this=47e977f0 reason=0] Assessing red penalty to apptester.eu01.aws.af.cm class 3 for event 131080. Penalty now 0, throttle[3] = 7003 nsHttpPipeline::Close [this=471f1100 reason=80004004] already closed nsHttpConnectionMgr::ReclaimConnection [conn=489e5110] nsHttpConnectionMgr::OnMsgReclaimConnection [conn=489e5110] nsHttpConnectionMgr::ConditionallyStopTimeoutTick armed=1 active=0 nsHttpConnectionMgr::ConditionallyStopTimeoutTick stop==true nsHttpChannel::OnDataAvailable [this=47264800 request=47aa1ab0 offset=7636368 count=2900] sending status notification [this=47264800 status=804b0006 progress=7639268/98948661] nsHttpChannel::OnStopRequest [this=47264800 request=47aa1ab0 status=0] nsHttpTransaction::DeleteSelfOnConsumerThread [this=47e977f0] Destroying nsHttpTransaction @47e977f0 calling OnStopRequest connection cannot be reused; closing connection It's not clear if the ABORT of the other transaction is related to the download ending or not---:mcmanus or :mayhemer are more likely to know that. This might also be bug 838988? > We should not be setting 'downloadAvailable' to true here if the file is > corrupted I'm not sure that's right. If the error is transient (and it sounds like it is, then we do want to allow the user to try to download again, right?
Flags: needinfo?(jduell.mcbugs)
Comment on attachment 713370 [details] [diff] [review] Add APP_PACKAGE_CORRUPTED error Review of attachment 713370 [details] [diff] [review]: ----------------------------------------------------------------- ::: dom/apps/src/Webapps.jsm @@ +2205,5 @@ > if (Components.isSuccessCode(aRv)) { > isSigned = true; > + zipReader = aZipReader; > + } else if (aRv == Cr.NS_ERROR_FILE_CORRUPTED) { > + throw "APP_PACKAGE_CORRUPTED"; So I assume what's going on here is that you 1) get NS_OK during OnStopRequest 2) somehow determine the file is bad (length wrong or checksum, etc) and that's how you get this FILE_CORRUPTED error 3) throwing here does something that alerts the user and also allows them to try to install again?
(In reply to Jason Smith [:jsmith] from comment #19) > Hmm...I'm wondering if we are describing the same bug. It sorta sounds like > we are describing something similar, but what I hit showed progress = 0 > during download at some point - but that might be something similar to what > you are describing with the "stop request." That resulted in a hang during > download. Yes, sorry, I cannot reproduce the exact issue that you are describing in comment 0. I am *always* getting the notification of a download canceled because of low device storage, *unless* the download is being unexpectedly stopped. It never hungs. I am getting progress = 0 (*in the apps registry*, not in the progress events notifications) during hosted app downloads (not sure if this is expected or not, Fabrice?), but not for packaged ones. You mentioned progress = 0 in both cases (comment 0 and comment 2), which seems weird, unless the packaged app download from your tests made no progress at all. A logcat with webapps debug activated would be helpful in this case :). Let me know if you need a build with apps debug activated. > > It isn't the weak network as you describe too. > > I could go do more testing if need be. But when I was testing this, it > reproduced pretty consistently. Yes, please. If you are still seeing the exact issue that you describe, I'll file a different one for the download being unexpectedly cut.
(In reply to Fernando Jiménez Moreno [:ferjm] from comment #22) > I am getting progress = 0 (*in the apps registry*, not in the progress > events notifications) during hosted app downloads (not sure if this is > expected or not, Fabrice?), but not for packaged ones. sounds like Bug 839071 this time ;) I guess that never comes in the progress events notifications because we send those when we get an actual progress event from the underlying download mechanism, and so we're setting a new progress here.
(In reply to Jason Duell (:jduell) from comment #20) > So I'm trying to follow the bug here. Here's what I'm hearing (correct me if > I'm wrong): > > - We initially thought this was a bug for apps failing and being > uninstallable afterward if the disk is full. Now we think that case works > (error msg shown and app can be installed OK later if space cleared up for > it). > > - Now this has morphed into a bug about the HTTP connection stopping before > the download is complete, and at that point we can't install it again. (If > true we should change the title of this bug) Yes. I cannot reproduce the disk full situation. As I mentioned in the comment above, every download that I tried with bigger size than the device free space was canceled and reported as a failure because of the low storage situation, *unless* the download gets cut and internally reported as successful, which triggered the incorrect INVALID_SIGNATURE error that I changed for the APP_PACKAGE_CORRUPTED one in the attached patch. > > > The issue that I am seeing is the download being cut unexpectedly and reported > > as a successful download. > > ... > > (We are getting the unexpected stopped request notification at > > https://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.jsm#2152). > > So are you seeing status=NS_OK here, or something else? Yes. > > I do see in the NSPR log that we've got a transaction (this=47e977f0) that > seems to be doing the download, then another transaction/pipeline gets > canceled (reason=80004004 == NS_ERROR_ABORT), after which the download > transaction is ending, with NS_OK status: > > nsHttpTransaction::HandleContent [this=47e977f0 count=124 read=124 > mContentRead=7639268 mContentLength=98948661] > nsHttpConnection::CloseTransaction[this=489e5110 trans=471f1104 > reason=80470002] > nsHttpPipeline::Close [this=471f1100 reason=0] > nsHttpTransaction::Close [this=47e977f0 reason=0] > Assessing red penalty to apptester.eu01.aws.af.cm class 3 for event > 131080. Penalty now 0, throttle[3] = 7003 > nsHttpPipeline::Close [this=471f1100 reason=80004004] > already closed > nsHttpConnectionMgr::ReclaimConnection [conn=489e5110] > nsHttpConnectionMgr::OnMsgReclaimConnection [conn=489e5110] > nsHttpConnectionMgr::ConditionallyStopTimeoutTick armed=1 active=0 > nsHttpConnectionMgr::ConditionallyStopTimeoutTick stop==true > nsHttpChannel::OnDataAvailable [this=47264800 request=47aa1ab0 > offset=7636368 count=2900] > sending status notification [this=47264800 status=804b0006 > progress=7639268/98948661] > nsHttpChannel::OnStopRequest [this=47264800 request=47aa1ab0 status=0] > nsHttpTransaction::DeleteSelfOnConsumerThread [this=47e977f0] > Destroying nsHttpTransaction @47e977f0 > calling OnStopRequest > connection cannot be reused; closing connection > > It's not clear if the ABORT of the other transaction is related to the > download ending or not---:mcmanus or :mayhemer are more likely to know that. > > This might also be bug 838988? > Might be! I'll check with the suggested fix. > > We should not be setting 'downloadAvailable' to true here if the file is > > corrupted > > I'm not sure that's right. If the error is transient (and it sounds like it > is, then we do want to allow the user to try to download again, right? All that we have in the apps implementation at that point (https://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.jsm#2221) is that the download was successful but the package is corrupted, so this seems to me like unrecoverable situation, unless the package is changed in the server. IMHO letting the user download again with this condition would not be the best UX. Not reporting the download as successful when it is not seems to me like the correct way to solve this instead.
(In reply to Jason Duell (:jduell) from comment #21) > Comment on attachment 713370 [details] [diff] [review] > Add APP_PACKAGE_CORRUPTED error > > Review of attachment 713370 [details] [diff] [review]: > ----------------------------------------------------------------- > > ::: dom/apps/src/Webapps.jsm > @@ +2205,5 @@ > > if (Components.isSuccessCode(aRv)) { > > isSigned = true; > > + zipReader = aZipReader; > > + } else if (aRv == Cr.NS_ERROR_FILE_CORRUPTED) { > > + throw "APP_PACKAGE_CORRUPTED"; > > So I assume what's going on here is that you > > 1) get NS_OK during OnStopRequest > 2) somehow determine the file is bad (length wrong or checksum, etc) and > that's how you get this FILE_CORRUPTED error Yes > 3) throwing here does something that alerts the user and also allows them to > try to install again? Yes, but, since this is an unrecoverable situation unless there are app changes in the server, the download is not allowed again unless the user uninstalls the app. The current UX for this kind of situations is being discussed in bug 821209. Thanks for your help!
Keywords: regressionwindow-wanted → qawanted
QA Contact: jsmith
Our suspicion is that the bugs resolved in comment 10 may have had an impact on the state of this issue (tef+->tef?). Looks like Jason is going to attempt to repro, at which point we can either block again or -.
blocking-b2g: tef+ → tef?
(In reply to Jason Duell (:jduell) from comment #20) > nsHttpTransaction::HandleContent [this=47e977f0 count=124 read=124 > mContentRead=7639268 mContentLength=98948661] > nsHttpConnection::CloseTransaction[this=489e5110 trans=471f1104 > reason=80470002] 80470002 is NS_BASE_STREAM_CLOSED, this is a graceful close of the connection. It means the server disconnected us or the file is served in a wrong way (bad C-L header?). If that is a zip package then, since just 10% has downloaded, it is corrupted. > This might also be bug 838988? I don't think it is. We convert NS_BASE_STREAM_CLOSED to NS_OK, which is correct.
Flags: needinfo?(honzab.moz)
Just managed to reproduce on the 2/14 build with a large packaged app. We get hung with progress = 0. There really is something trippy going on in Mt View's networks with the phone lately...
Here's what I think I'm seeing: Some weird wifi/data connection bug is causing the network connection to be enter a "lame network" state that causes me to end up seeing bug 830447. The other bugs Julien cite are resulting caveats that are unrelated to the core issue here. Together the whole pieces looked bad, but now that I understand it, the root problem is a wifi problem, not a core dom apps API problem. Let me do some bug magic cleanup to get this clarified.
Keywords: qawanted
Assignee: ferjmoreno → nobody
No longer blocks: app-install
Component: DOM: Apps → Wifi
Product: Core → Boot2Gecko
Summary: If you run out of space when downloading an app, you can never install the app → [Intermittent] If you run out of space when downloading an app, the wifi can enter a lame network state, resulting in bug 830447
Version: Trunk → unspecified
Blocks: 840612
This could potentially be the same issue as bug 840612. I'm going to break out a different bug for the patch this bug had a side tangent about.
blocking-b2g: tef? → ---
I've filed bug 841631 for the side tangent that's being talked about here.
Blocks: 840612
Blocks: 840612
Attachment #713370 - Attachment is obsolete: true
No longer blocks: 840612
tracking-b2g18: --- → ?
blocking-b2g: --- → backlog
blocking-b2g: backlog → ---
tracking-b2g: --- → backlog
Closing all intermittent test failures for Firefox OS (since we're not focusing on it anymore). Please reopen if my search included your bug by mistake.
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: