Closed Bug 812584 Opened 12 years ago Closed 12 years ago

[OTA update] When network issues interrupt the update, the UI still incorrectly says "Downloading updates..." forever and ever

Categories

(Firefox OS Graveyard :: General, defect, P1)

x86_64
Linux
defect

Tracking

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

RESOLVED FIXED
B2G C3 (12dec-1jan)
blocking-basecamp +
Tracking Status
firefox19 --- fixed
firefox20 --- fixed
b2g18 --- fixed

People

(Reporter: dholbert, Assigned: marshall)

References

Details

(Keywords: b2g-testdriver, unagi)

Attachments

(6 files)

I just tried to get the OTA update from the last stable dogfood build (2012-11-06 20:52:24) to the one that was just released.  I happened to get temporarily disconnected and then reconnected from WiFi, very briefly, which apparently interrupted the update.

That's fine -- that happens.

HOWEVER -- I only knew the update had stopped because I was watching the logcat output.  The updater UI, on the other hand, **still acted like it was updating**.

Even now, about 5 minutes later, the status indication *still* says "Downloading updates..." and it has no indication that anything went wrong.  That's really bad, especially for users on spotty wifi / data connections -- if they hit a network blip, we should let them know as soon as possible, rather than stringing them along indefinitely.

Here's the logcat output from when my WiFi indication was interrupted, FWIW.  In particular, notice the line about
> "Downloader:onStopRequest - setting state to: download-failed"
I would expect that should trigger a notification of some sort (or at least a removal of the no-longer-accurate "Downloading updates..." indicator)
{
I/Gecko   (  109): *** AUS:SVC Downloader:onProgress - progress: 17089533/49974276
E/GeckoConsole(  109): AUS:SVC Downloader:onProgress - progress: 17089533/49974276
I/wpa_supplicant(  362): wlan0: CTRL-EVENT-DISCONNECTED bssid=d8:c7:c8:eb:0d:50 reason=0
I/Gecko   (  109): *** AUS:SVC Downloader:onProgress - progress: 17100000/49974276
E/GeckoConsole(  109): AUS:SVC Downloader:onProgress - progress: 17100000/49974276
I/Gecko   (  109): *** AUS:SVC Downloader:onStopRequest - original URI spec: http://update.boot2gecko.org/stable/b2g_stable_update_2012-11-15_102959.mar?build_id=
20121115094950&version=18.0a2&dogfooding_prerelease_id=14162, final URI spec: http://update.boot2gecko.org/stable/b2g_stable_update_2012-11-15_102959.mar?build_id
=20121115094950&version=18.0a2&dogfooding_prerelease_id=14162, status: 2152398862
E/GeckoConsole(  109): AUS:SVC Downloader:onStopRequest - original URI spec: http://update.boot2gecko.org/stable/b2g_stable_update_2012-11-15_102959.mar?build_id=
20121115094950&version=18.0a2&dogfooding_prerelease_id=14162, final URI spec: http://update.boot2gecko.org/stable/b2g_stable_update_2012-11-15_102959.mar?build_id
=20121115094950&version=18.0a2&dogfooding_prerelease_id=14162, status: 2152398862
I/Gecko   (  109): *** AUS:SVC Downloader:onStopRequest - non-verification failure
E/GeckoConsole(  109): AUS:SVC Downloader:onStopRequest - non-verification failure
I/Gecko   (  109): *** AUS:SVC getStatusTextFromCode - transfer error: Connection timed out, code: 2152398862
E/GeckoConsole(  109): AUS:SVC getStatusTextFromCode - transfer error: Connection timed out, code: 2152398862
I/Gecko   (  109): *** AUS:SVC Downloader:onStopRequest - setting state to: download-failed
E/GeckoConsole(  109): AUS:SVC Downloader:onStopRequest - setting state to: download-failed
I/wpa_supplicant(  362): wlan0: Trying to associate with SSID 'Mozilla-G'
}
STEPS TO REPRODUCE:
 1. Be on an old dogfood build (so that an update is available)
 2. While connected over WiFi, check for updates.
 3. Accept the update, so you get the "Downloading updates..." entry in the notification pulldown area.
 4. Turn WiFi off and on.

EXPECTED RESULTS:
 "Downloading updates..." notification is replaced with "Update download failed." or something like that.

ACTUAL RESULTS:
 "Downloading updates..." notification remains indefinitely, even though the update download has failed.
NOTE: After successfully receiving an update (to 2012-11-14 09:49:28), I was offered another update, and I was able to reproduce this using prev. comment's STR while that update was downloading. So: this bug affects dogfood builds at least as new as that 2012-11-14 build. (and I suspect it probably affects bleeding-edge trunk as well)
CCing Brian Bondy, who's been working on the download fail over logic for AUS + B2G.
Could you provide the full log for 5 minutes?

This message is expected and it's not a problem:
> "Downloader:onStopRequest - setting state to: download-failed"

How connection interrupts work as of bug 791829, if there is a connection interrupt, you'll get that log message and it'll retry in 2 seconds.  If there are 10 such *consecutive* blips in a row, then it'll actually fail the download.

When the phone is offline though it'll say downloading until it is online again and then it'll continue, but I don't see evidence of your phone being offline for the part of the log that you pasted.

I suspect your phone went into offline mode, but I'm not sure.  I'm not sure how else it could be trying for 5 minutes.
(In reply to Brian R. Bondy [:bbondy] from comment #4)
> Could you provide the full log for 5 minutes?

Nope, I've since updated successfully.

> This message is expected and it's not a problem:
> > "Downloader:onStopRequest - setting state to: download-failed"

Right, I agree. The problem is that it's not propagated to the UI.

> How connection interrupts work as of bug 791829, if there is a connection
> interrupt, you'll get that log message and it'll retry in 2 seconds.

I've never gotten any retries. I ended up needing to reboot the phone whenever I got a disconnect.

> When the phone is offline though it'll say downloading until it is online
> again and then it'll continue, but I don't see evidence of your phone being
> offline for the part of the log that you pasted.

What about:
I/wpa_supplicant(  362): wlan0: CTRL-EVENT-DISCONNECTED bssid=d8:c7:c8:eb:0d:50 reason=0
(that looks like I'm going offline
I/wpa_supplicant(  362): wlan0: Trying to associate with SSID 'Mozilla-G'
(that looks like I'm going online again)



> 
> I suspect your phone went into offline mode, but I'm not sure.  I'm not sure
> how else it could be trying for 5 minutes.
Sorry, forgot to repspond to that last part. As far as I can tell, it's not actually "trying" for 5 minutes -- it fails and then never retries.
sounds like you're going offline and the online observer is never firing.

> This message is expected and it's not a problem:
> > "Downloader:onStopRequest - setting state to: download-failed"

> Right, I agree. The problem is that it's not propagated to the UI.

For connection blips I don't think we should update the UI to let them know each time there is a blip.

For offline mode, I agree that can be improved.
(In reply to Brian R. Bondy [:bbondy] from comment #7)
> sounds like you're going offline and the online observer is never firing.
> 
> > This message is expected and it's not a problem:
> > > "Downloader:onStopRequest - setting state to: download-failed"
> 
> > Right, I agree. The problem is that it's not propagated to the UI.
> 
> For connection blips I don't think we should update the UI to let them know
> each time there is a blip.

Neither do I -- that'd be silly.  But if the blip ends up resulting in the update failing to download altogether (as it did for me every time I hit a blip), then I think we should update the UI.
I don't think this is an app udpater bug, I think this is a bug with the online observer not being fired when it should on b2g.  There's a spin off bug we can do to give the user an indication that they're in offline mode, but I don't think that should be a blocker.
As far as I can tell the update didn't fail, that log message is given for connection blips and does not indicate that the connection actually failed. It is an internal log message only for people that look at the code. 

From what I know so far it seems like the online observer topic wasn't fired, and that means that the update didn't try to reconnect again because it was waiting for that observer topic to fire.
(In reply to Brian R. Bondy [:bbondy] from comment #4)
> How connection interrupts work as of bug 791829, if there is a connection
> interrupt, you'll get that log message and it'll retry in 2 seconds.  If
> there are 10 such *consecutive* blips in a row, then it'll actually fail the
> download.

hmm... actually, I reported this using the 2012-11-06 dogfood build (which only received an update today), and it looks like bug 791829 just landed on aurora two days ago, so that build wouldn't have had the new post-bug-791829 behavior, right?

maybe it won't be possible to set this w/ bug 791829's code (on the dogfooding channel at least) until the next stable upgrade is offered.
FWIW, I reflashed to the 2012-11-06 build to get an update-with-blips log before I realized  that 2012-11-06 likely doesn't have the new code (per Comment 11).

Let me know whether or not you'd still like that log... If so, I can make one, if not, I'll just go ahead and upgrade again.
Ya please post the log on the next upgrade, sounds like we should wait until the next upgrade.
If it's not a lot of work feel free to post the log for the 2012-11-06 build and I can verify.
Depends on: 812686
OK, here's a logcat log showing what I described in comment 0, running the 11-06 build.

Here's what happened during this log:
 - I turned on my unagi dogfood device (running 11-06 stable build)
 - It auto-connected to Mozilla-Guest and an update notification appeared
 - I accepted the update
 - After a few seconds of update-downloading, I turned WiFi off & on.
 - After a few more seconds, the device re-connected to WiFi
 - I left the phone alone for 5+ minutes.
 - Just for fun, at the very end I did two manual "check for updates". ADB shows that these found an update, but i had no way of accepting it -- the phone still said "Downloading updates..."
 - Finally, I rebooted the phone.
Confirmed, this is not using the new code. I don't see the new log messages in your log.
Here's the same issue while running the stable build that came after that 11/06 one,  w/ build identifier 20121115094949.  (this is the one I hit this bug with in comment 2)

(Pretty sure bbondy's patch landed after this build; just posting this for thoroughness.)

The update that I interrupted in this log is the update that would bring me fully up-to-date, FWIW.
Component: Gaia → Gaia::System
Depends on: 791829
I saw this yesterday when working on bug 813451 with inbound and latest gaia.  Definitely still happening after bug 791829.
Looking for a log with the problem using the new code post bug 791829.
Can email full log if it's needed.

The gaia "Downloading ..." spinner doesn't change during this process.  However, I do get an "Error downlaoding update" notification.

I/Gecko   (  106): *** AUS:SVC Checker: checkForUpdates, force: true
I/Gecko   (  106): *** AUS:SVC Checker:getUpdateURL - update URL: http://192.168.1.64/~cjones/update/update.xml?force=1
I/Gecko   (  106): *** AUS:SVC gCanCheckForUpdates - able to check for updates
I/Gecko   (  106): *** AUS:SVC Checker:checkForUpdates - sending request to: http://192.168.1.64/~cjones/update/update.xml?force=1
I/Gecko   (  106): *** AUS:SVC Checker:onProgress - 594/594
I/Gecko   (  106): *** AUS:SVC Creating UpdateService
I/Gecko   (  106): *** AUS:SVC Checker:onLoad - request completed downloading document
I/Gecko   (  106): *** AUS:SVC Checker:getUpdateURL - update URL: http://192.168.1.64/~cjones/update/update.xml?force=1
I/Gecko   (  106): *** AUS:SVC Checker:onLoad - number of updates available: 1
I/Gecko   (  106): *** AUS:SVC Checker: checkForUpdates, force: false
I/Gecko   (  106): *** AUS:SVC Checker:getUpdateURL - update URL: http://192.168.1.64/~cjones/update/update.xml
I/Gecko   (  106): *** AUS:SVC Checker:checkForUpdates - sending request to: http://192.168.1.64/~cjones/update/update.xml
I/Gecko   (  106): *** AUS:SVC Checker:onProgress - 594/594
I/Gecko   (  106): *** AUS:SVC Checker:onLoad - request completed downloading document
I/Gecko   (  106): *** AUS:SVC Checker:getUpdateURL - update URL: http://192.168.1.64/~cjones/update/update.xml
I/Gecko   (  106): *** AUS:SVC Checker:onLoad - number of updates available: 1
I/Gecko   (  106): *** AUS:SVC gCanApplyUpdates - testing write access /data/local/update.test
I/Gecko   (  106): *** AUS:SVC gCanApplyUpdates - able to apply updates
I/Gecko   (  106): *** AUS:SVC UpdateService:_selectAndInstallUpdate - prompting because silent install is disabled
I/Gecko   (  106): *** AUS:SVC Creating Downloader
I/Gecko   (  106): *** AUS:SVC UpdateService:_downloadUpdate
I/Gecko   (  106): *** AUS:SVC readStringFromFile - file doesn't exist: /data/local/updates/0/update.status
I/Gecko   (  106): *** AUS:SVC readStatusFile - status: null, path: /data/local/updates/0/update.status
I/Gecko   (  106): *** AUS:SVC Downloader:downloadUpdate - downloading from http://192.168.1.64/~cjones/update/b2g-gecko-update.mar to /data/local/updates/0/update.mar
I/Gecko   (  106): *** AUS:SVC Downloader:onStartRequest - original URI spec: http://192.168.1.64/~cjones/update/b2g-gecko-update.mar, final URI spec: http://192.168.1.64/~cjones/update/b2g-gecko-update.mar
I/Gecko   (  106): *** AUS:SVC Downloader:onProgress - progress: 512/49998414
I/Gecko   (  106): *** AUS:SVC Downloader:onProgress - progress: 1179648/49998414
I/Gecko   (  106): *** AUS:SVC Downloader:onProgress - progress: 1966080/49998414
I/Gecko   (  106): *** AUS:SVC Downloader:onProgress - progress: 2752512/49998414
I/Gecko   (  106): *** AUS:SVC Downloader:onProgress - progress: 3932160/49998414
I/Gecko   (  106): *** AUS:SVC Downloader:onProgress - progress: 5111808/49998414
I/Gecko   (  106): *** AUS:SVC Downloader:onProgress - progress: 6291456/49998414
I/Gecko   (  106): *** AUS:SVC Downloader:onProgress - progress: 7077888/49998414
I/Gecko   (  106): *** AUS:SVC Downloader:onProgress - progress: 7864320/49998414
I/Gecko   (  106): *** AUS:SVC Downloader:onProgress - progress: 8361924/49998414
I/Gecko   (  106): *** AUS:SVC Downloader:onStopRequest - original URI spec: http://192.168.1.64/~cjones/update/b2g-gecko-update.mar, final URI spec: http://192.168.1.64/~cjones/update/b2g-gecko-update.mar, status: 2152398862
I/Gecko   (  106): *** AUS:SVC Downloader:onStopRequest - status: 2152398862, current fail: 0, max fail: 10, retryTimeout: 2000
I/Gecko   (  106): *** AUS:SVC Downloader:onStopRequest - socket error, shouldRetrySoon: true
I/Gecko   (  106): *** AUS:SVC Downloader:onStopRequest - setting state to: downloading
I/Gecko   (  106): *** AUS:SVC Downloader:onStopRequest - Retrying soon
I/Gecko   (  106): *** AUS:SVC readStatusFile - status: downloading, path: /data/local/updates/0/update.status
I/Gecko   (  106): *** AUS:SVC Checker: checkForUpdates, force: false
I/Gecko   (  106): *** AUS:SVC Checker:getUpdateURL - update URL: http://192.168.1.64/~cjones/update/update.xml
I/Gecko   (  106): *** AUS:SVC Checker:checkForUpdates - sending request to: http://192.168.1.64/~cjones/update/update.xml
I/Gecko   (  106): *** AUS:SVC UpdateService:_attemptResume
I/Gecko   (  106): *** AUS:SVC UpdateService:_attemptResume - _patch.state: downloading
I/Gecko   (  106): *** AUS:SVC Creating Downloader
I/Gecko   (  106): *** AUS:SVC UpdateService:_downloadUpdate
I/Gecko   (  106): *** AUS:SVC readStatusFile - status: downloading, path: /data/local/updates/0/update.status
I/Gecko   (  106): *** AUS:SVC Downloader:_selectPatch - found existing patch with state: downloading
I/Gecko   (  106): *** AUS:SVC Downloader:_selectPatch - resuming download
I/Gecko   (  106): *** AUS:SVC Downloader:downloadUpdate - downloading from http://192.168.1.64/~cjones/update/b2g-gecko-update.mar to /data/local/updates/0/update.mar
I/Gecko   (  106): *** AUS:SVC UpdateService:_attemptResume - downloadUpdate status: downloading
blocking-basecamp: ? → +
Priority: -- → P3
Assignee: nobody → etienne
Marshall, shouldn't we send an update-error mozChromeEvent to gaia in this case?
(In reply to Brian R. Bondy [:bbondy] from comment #19)
> Looking for a log with the problem using the new code post bug 791829.

Not sure if Chris's log already satisfied this request, but just in case it didn't, here's mine, which I think (?) includes bug 791829's patch. (Hoping bbondy can confirm)

This log was generated using the latest stable dogfood build as of this morning -- 20121115145434.  I accepted an update to the just-released new stable build, and (as before) I interrupted it by turning WiFi off & on.  This resulted in the download silently failing, w/ the "Downloading updates..." notification persisting forever.
> > (In reply to Brian R. Bondy [:bbondy] from comment #19)
> > Looking for a log with the problem using the new code post bug 791829.
>
> Not sure if Chris's log already satisfied this request, but just in case it didn't,
> here's mine, which I think (?) includes bug 791829's patch. (Hoping bbondy can confirm)

Confirmed that this log does not include bug 791829.

The log in Comment 20 does include bug 791829 but for the snippet that is included it looks like the download was resumed because of a connection outage, and I can't see what happened after that because there is not enough log. If you still have the full log please attach cjones.   Also it's not clear to me from Comment 20 if the update hung there forever, or if it failed, or if it in the end resumed. During connection outages like that there should be no UI notification until the connection is resumed.   You mentioned 'I do get an "Error downlaoding update" notification.', did you get this in the UI or are you getting this info from the logs? or?

It would help if we had xpcshell tests up so we could see if the test for this is passing or not on b2g.
Priority: P3 → P1
Target Milestone: --- → B2G C2 (20nov-10dec)
So let's recap:
* When, during a system update download, we switch the wifi off and on, the downloads restarts properly, the UI shows progress, no problem.

* After a few retry the download is considered a failure [1], *but* the UI is still spinning. This is because gaia never got the "update-error" mozChromeEvent.

Not familiar with this code but it looks like we never call showUpdateError [2] (triggering the update-error mozChromeEvent for b2g) since we started a background download [3].

If gaia is notified of the failure, the UI will stop spinning.

Can somebody on the platform side have a look?

[1] AUS:SVC Downloader:onStopRequest - setting state to: download-failed
[2] https://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/nsUpdateService.js#3651
[3] https://mxr.mozilla.org/mozilla-central/source/b2g/components/UpdatePrompt.js#271
Assignee: etienne → nobody
Component: Gaia::System → General
The error event is not sent for updates when entering offline mode.
Instead it waits for an online event to happen and then it resumes the update from where it left off.

For other types of connection errors it will retry up to 10 times without notification.  Once it reaches 10 it will send the error notification.

We need a log like the one in Comment 20, but more complete.  The other logs are from older builds and follow a different error sequence.
Hi, Brian, are you the best person to own this case? Or someone else? 
Thanks!
Flags: needinfo?(netzen)
1. Do we support "resume update" after the network is off & on after that? 
2. When the screen goes off, the network might be off also. In this case, should we do something for it? If we support resume, this might be not a problem.
Marshall are you able to look at this? At this point I'm fully converted to working on Metro again.  Or if you want, I can look at it but can you get me the log I mentioned in Comment 23 and Comment 25?
Flags: needinfo?(netzen)
Blocks: 811357
(In reply to Brian R. Bondy [:bbondy] from comment #28)
> Marshall are you able to look at this? At this point I'm fully converted to
> working on Metro again.  Or if you want, I can look at it but can you get me
> the log I mentioned in Comment 23 and Comment 25?

I'll grab this and try to track it down.
Assignee: nobody → marshall
(note that dogfooders like myself won't be able to provide a log anytime soon, since only the most recent dogfood build includes bbondy's code from bug 791829, and IIUC the next stable update will require flashing instead of being OTA)
No longer depends on: 812686
Be a little less aggressive about retrying, and allow more errors before we
mark an update download as "failed". See comments for more info
Attachment #688933 - Flags: review?(fabrice)
Comment on attachment 688932 [details] [diff] [review]
Part 1: forward update errors - v1

Review of attachment 688932 [details] [diff] [review]:
-----------------------------------------------------------------

::: toolkit/mozapps/update/nsUpdateService.js
@@ +3656,5 @@
> +        // We always forward errors in B2G, since Gaia controls the update UI
> +        var prompter = Cc["@mozilla.org/updates/update-prompt;1"].
> +                       createInstance(Ci.nsIUpdatePrompt);
> +        prompter.showUpdateError(this._update);
> +#endif

So I don't think this explain why the updates spinned forever though.  For connection retries it should retry and then send an error, and for offline mode errors it should register an observer and wait for it to be fired. 

What will the UI do in this case?  Will it say failed but still do a retry? Won't this still lead to updates never resuming?
Attached file Gaia pull request 6855
Attachment #689219 - Flags: review?(etienne)
Comment on attachment 689219 [details] [review]
Gaia pull request 6855

r=me
Attachment #689219 - Flags: review?(etienne) → review+
Attachment #688933 - Flags: review?(fabrice) → review+
Comment on attachment 688932 [details] [diff] [review]
Part 1: forward update errors - v1

Review of attachment 688932 [details] [diff] [review]:
-----------------------------------------------------------------

Reviewed in Comment 33
Attachment #688932 - Flags: review?(netzen)
(In reply to Brian R. Bondy [:bbondy] from comment #33)
> So I don't think this explain why the updates spinned forever though.  For
> connection retries it should retry and then send an error, and for offline
> mode errors it should register an observer and wait for it to be fired. 

There are a few things going on here:
1) Actual download failures are never making their way to Gaia, because of the "fgdl" flag check that we aren't setting. This is the problem I'm trying to address with this set of patches. I can add a new notification for "reconnecting" here if you think that is valid as well (that will further mitigate the incorrect "Downloading..." status)

2) For offline retry Gaia messages, Etienne and I have worked out a scheme in Bug 817821
 
> What will the UI do in this case?  Will it say failed but still do a retry?
> Won't this still lead to updates never resuming?

The update is removed from the notification tray, and an error message is shown to the user. The update can be tried again from another check, but I'm not sure what else can be done in the case of "hard failure".

When the updater code attempts to reconnect, we could change the status in Gaia from "Downloading.." to "Reconnecting" or something similar. Tagging Josh and Etienne for any additional feedback there..
Flags: needinfo?(jcarpenter)
(In reply to Marshall Culpepper [:marshall_law] from comment #37)
> I can add a new notification for
> "reconnecting" here if you think that is valid as well (that will further
> mitigate the incorrect "Downloading..." status)
> 
> When the updater code attempts to reconnect, we could change the status in
> Gaia from "Downloading.." to "Reconnecting" or something similar. Tagging
> Josh and Etienne for any additional feedback there..

I got a little ahead of myself here. We are using a "stalled" state from Bug 817821 to cover when the connection stalls for some reason (be it retrying a connection, or because the network is offline).

That should cover the UI for both offline and connection retries.
Flags: needinfo?(jcarpenter)
> ...because of the "fgdl" flag check that we aren't setting

I don't know what that is, but I guess you're saying you're setting it by passing on that notification. 

> I can add a new notification for "reconnecting" here if you think that is 
> valid as well (that will further mitigate the incorrect "Downloading..." status)

Yes I think that is more valid and can be used for non b2g as well for any UI interested in this information.

So will updates actually resume after this path?  Or will it just say failed?

> I got a little ahead of myself here. We are using a "stalled" state 
> from Bug 817821 to cover when the connection stalls for some reason (be it 
> retrying a connection, or because the network is offline).
> That should cover the UI for both offline and connection retries.

I don't really understand this, nothing landed in bug 817821 yet.
Nice -- this is at least partly WFM now, w/ steps from Comment 1.  (updating from first "beta" release 20121203114956 to the next one)  If I disable & re-enable wifi, the download appears to resume after a few seconds.  (Download counter in ADB & in status message starts incrementing again.)

This was the first build I've tested that included bug 791829's patch. Not sure why others aren't seeing the behavior I'm seeing -- maybe there are other complicating factors.
(In reply to Brian R. Bondy [:bbondy] from comment #39)
> 
> I don't really understand this, nothing landed in bug 817821 yet.

Bug 817821 should be seen as a follow up to this
So did you mean to say: 'We will be using a "stalled" state from Bug 817821'  instead of ' We are using a "stalled" state from Bug 817821'?
(In reply to Brian R. Bondy [:bbondy] from comment #43)
> So did you mean to say: 'We will be using a "stalled" state from Bug 817821'
> instead of ' We are using a "stalled" state from Bug 817821'?

Yup, that's exactly what I meant :)
> Actual download failures are never making their way to Gaia, 
> because of the "fgdl" flag check that we aren't setting.

So where does this fgdl flag check (or set) happen? I don't see how this patch will give you what you want in that regard. Please advise.
(In reply to Brian R. Bondy [:bbondy] from comment #45)
> > Actual download failures are never making their way to Gaia, 
> > because of the "fgdl" flag check that we aren't setting.
> 
> So where does this fgdl flag check (or set) happen? I don't see how this
> patch will give you what you want in that regard. Please advise.

Sorry -- the name of the flag is "foregroundDownload". There are actually two checks in the original code. The first checks that the most recent update window doesn't exist -- this is specific to the XUL update UI I assume. The second checks for this foregroundDownload flag.

This logic is directly above my patch in nsUpdateService.js, here's a link:

https://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/nsUpdateService.js#3640

My patch just short circuits these checks and reports the error directly, but only for Gonk.
Comment on attachment 688932 [details] [diff] [review]
Part 1: forward update errors - v1

Review of attachment 688932 [details] [diff] [review]:
-----------------------------------------------------------------

I see, OK I guess I'm ok with this for now.
Attachment #688932 - Flags: review+
\o/ to these reviews. Let's try to get this work landed today.
Target Milestone: B2G C2 (20nov-10dec) → B2G C3 (12dec-1jan)
Attachment mime type: text/plain → text/x-github-pull-request
Even if I interrupt my internet connection, it's still stalled, never registers a failed connection.  I assume nothing is happening during the stalled 'Downloading Firefox' process which will run all day if my computer is left on.  IS there something I need to do on my end?  Don't see any resolution from my end.
Sue, it sounds like you're talking about Firefox (on a computer), correct?

If so, please file a new bug; this bug is about Firefox OS (an operating system that runs on phones), which is different. (and this particular issue was resolved nearly a year ago)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: