Closed Bug 802016 Opened 12 years ago Closed 12 years ago

[OTA update] Force update check during offline connection still returns an available update to the user

Categories

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

ARM
Gonk (Firefox OS)
defect

Tracking

(blocking-basecamp:+, firefox17 wontfix, firefox18 fixed, firefox19 fixed)

RESOLVED FIXED
blocking-basecamp +
Tracking Status
firefox17 --- wontfix
firefox18 --- fixed
firefox19 --- fixed

People

(Reporter: tchung, Assigned: bbondy)

References

Details

(Whiteboard: [dogfooding-blocker])

Attachments

(3 files, 1 obsolete file)

Attached image screenshot (deleted) —
When the device is offline, force checking for update is still finding the update.xml, but it fails to download as expected. I'm not sure where its finding the update.xml, but the system update notification does appear in the notifications window. Then tapping it will try to download, instead of erroring out. Dogfood blocker, because of the confusing system notification update on the homescreen and toolbar. But when the user clicks it, they wont get an update nor is there an error that the update failed. See screenshot for the downloading screen. logcat: (device is offline the whole time) 10-15 22:13:39.419: I/Gecko(109): *** AUS:SVC Checker:getUpdateURL - update URL: http://update.boot2gecko.org/nightly/update.xml?force=1 10-15 22:13:39.419: E/GeckoConsole(109): AUS:SVC Checker:getUpdateURL - update URL: http://update.boot2gecko.org/nightly/update.xml?force=1 10-15 22:13:39.419: I/Gecko(109): *** AUS:SVC gCanCheckForUpdates - able to check for updates 10-15 22:13:39.419: E/GeckoConsole(109): AUS:SVC gCanCheckForUpdates - able to check for updates 10-15 22:13:39.429: I/Gecko(109): *** AUS:SVC Checker:checkForUpdates - sending request to: http://update.boot2gecko.org/nightly/update.xml?force=1 10-15 22:13:39.429: E/GeckoConsole(109): AUS:SVC Checker:checkForUpdates - sending request to: http://update.boot2gecko.org/nightly/update.xml?force=1 10-15 22:13:39.969: I/Gecko(109): *** AUS:SVC Checker:onProgress - 571/571 10-15 22:13:39.969: E/GeckoConsole(109): AUS:SVC Checker:onProgress - 571/571 10-15 22:13:39.969: I/Gecko(109): *** AUS:SVC Checker:onLoad - request completed downloading document 10-15 22:13:39.969: E/GeckoConsole(109): AUS:SVC Checker:onLoad - request completed downloading document 10-15 22:13:39.999: I/Gecko(109): *** AUS:SVC Checker:getUpdateURL - update URL: http://update.boot2gecko.org/nightly/update.xml?force=1 10-15 22:13:39.999: E/GeckoConsole(109): AUS:SVC Checker:getUpdateURL - update URL: http://update.boot2gecko.org/nightly/update.xml?force=1 10-15 22:13:39.999: I/Gecko(109): *** AUS:SVC Checker:onLoad - number of updates available: 1 10-15 22:13:40.009: E/GeckoConsole(109): AUS:SVC Checker:onLoad - number of updates available: 1 10-15 22:13:40.019: I/Gecko(109): *** AUS:SVC gCanApplyUpdates - testing write access /data/local/update.test 10-15 22:13:40.029: E/GeckoConsole(109): AUS:SVC gCanApplyUpdates - testing write access /data/local/update.test 10-15 22:13:40.029: I/Gecko(109): *** AUS:SVC gCanApplyUpdates - able to apply updates 10-15 22:13:40.029: E/GeckoConsole(109): AUS:SVC gCanApplyUpdates - able to apply updates 10-15 22:13:40.029: I/Gecko(109): *** AUS:SVC UpdateService:_selectAndInstallUpdate - prompting because silent install is disabled 10-15 22:13:40.039: E/GeckoConsole(109): AUS:SVC UpdateService:_selectAndInstallUpdate - prompting because silent install is disabled 10-15 22:14:05.809: I/Gecko(109): *** AUS:SVC readStringFromFile - file doesn't exist: /data/local/updates/0/update.status 10-15 22:14:05.809: E/GeckoConsole(109): AUS:SVC readStringFromFile - file doesn't exist: /data/local/updates/0/update.status 10-15 22:14:05.809: I/Gecko(109): *** AUS:SVC readStatusFile - status: null, path: /data/local/updates/0/update.status 10-15 22:14:05.809: E/GeckoConsole(109): AUS:SVC readStatusFile - status: null, path: /data/local/updates/0/update.status 10-15 22:14:05.879: I/Gecko(109): *** AUS:SVC Downloader:downloadUpdate - downloading from http://update.boot2gecko.org/nightly/b2g_update_2012-10-15_170411.mar to /data/local/updates/0/update.mar 10-15 22:14:05.879: E/GeckoConsole(109): AUS:SVC Downloader:downloadUpdate - downloading from http://update.boot2gecko.org/nightly/b2g_update_2012-10-15_170411.mar to /data/local/updates/0/update.mar 10-15 22:14:06.149: I/Gecko(109): *** AUS:SVC Downloader:onStartRequest - original URI spec: http://update.boot2gecko.org/nightly/b2g_update_2012-10-15_170411.mar, final URI spec: http://update.boot2gecko.org/nightly/b2g_update_2012-10-15_170411.mar 10-15 22:14:06.149: E/GeckoConsole(109): AUS:SVC Downloader:onStartRequest - original URI spec: http://update.boot2gecko.org/nightly/b2g_update_2012-10-15_170411.mar, final URI spec: http://update.boot2gecko.org/nightly/b2g_update_2012-10-15_170411.mar 10-15 22:14:06.209: I/Gecko(109): *** AUS:SVC Downloader:onStopRequest - original URI spec: http://update.boot2gecko.org/nightly/b2g_update_2012-10-15_170411.mar, final URI spec: http://update.boot2gecko.org/nightly/b2g_update_2012-10-15_170411.mar, status: 2152398864 10-15 22:14:06.209: E/GeckoConsole(109): AUS:SVC Downloader:onStopRequest - original URI spec: http://update.boot2gecko.org/nightly/b2g_update_2012-10-15_170411.mar, final URI spec: http://update.boot2gecko.org/nightly/b2g_update_2012-10-15_170411.mar, status: 2152398864 10-15 22:14:06.209: I/Gecko(109): *** AUS:SVC Downloader:onStopRequest - non-verification failure 10-15 22:14:06.209: E/GeckoConsole(109): AUS:SVC Downloader:onStopRequest - non-verification failure 10-15 22:14:06.209: I/Gecko(109): *** AUS:SVC getStatusTextFromCode - transfer error: Network is offline (go online), code: 2152398864 10-15 22:14:06.209: E/GeckoConsole(109): AUS:SVC getStatusTextFromCode - transfer error: Network is offline (go online), code: 2152398864 10-15 22:14:06.209: I/Gecko(109): *** AUS:SVC Downloader:onStopRequest - setting state to: download-failed 10-15 22:14:06.219: E/GeckoConsole(109): AUS:SVC Downloader:onStopRequest - setting state to: download-failed 10-15 22:14:06.309: I/Gecko(109): *** AUS:SVC Downloader:onStopRequest - all update patch downloads failed 10-15 22:14:06.309: E/GeckoConsole(109): AUS:SVC Downloader:onStopRequest - all update patch downloads failed Repro: 1) install 10-15-2012 unagi nightly build ** Gaia: 589c7f8f7df88766f7a5fa944f6bb05eef04b8c3 ** Gecko: 1ec4bdea9de7c0567810fd09cb55b02304b3186d 2) disable wifi and carrier data service (or enable airplane mode) 3) system > device info > force check for update 4) Verify the update notification appears 5) Tap the notification, and verify the update fails. However there's no failure, but instead just a progress bar saying it's downloading.. (but it isn't!) Expected: - offline means you shoudlnt get any update notifications and never clickable. Actual: - offline still gets a update.xml ping, and sends the user a notification to click on.
Summary: [OTA update] system notification never reappears after dismissing "Later" and then force updating → [OTA update] Force update check during offline connection still returns an available update to the user
Attached image screenshot on homescreen (deleted) —
notice its still on airplane mode! yet the notifications appear after restarting.
Until we're out of the woods (almost there!) on updater, I'll keep throwing these bugs to Marshall first to determine what the next steps are.
Assignee: nobody → marshall
Assignee: marshall → netzen
Just adding a couple notes for findings so far: - This problem is not reproducible with a desktop build on OSX if you use the JS console and the exact same code. Cache is not used. - I thought initially maybe no-cache wasn't supported by the server and maybe we needed something like 'this._request.setRequestHeader("Pragma", "no-cache");' but it seems more like a client side caching problem. - A quick fix to this would be to append a random request URL parameter at the end of the URL, something like &timestamp=blah My device is still setting up, so I'm only able to try things in a desktop environment for now.
> - A quick fix to this would be to append a random request URL parameter at the > end of the URL, something like &timestamp=blah rstrong and releng are OK with this workaround. I have no proof that it will work but I think we should try and then file a follow up which is not a blocker to investigate why the Cache-Control header is not working as we expect. I need sign off from metrics first, I pinged them in #metrics but no response yet. If anyone has a contact I can CC in on this bug that would be appreciated.
Hi Metrics, please see Comment 4. I want to make sure adding a URL parameter here wouldn't mess up anything you are measuring.
Ignore I found a proper fix for this. The problem is that Cache-Control: no-cache is only interpreted by proxies (and possibly the final destination). If the object is already cached then Necko will return it to us. I asked in #necko and they confirmed. They suggested I use the LOAD_BYPASS_CACHE load flag :D
Attached patch Patch v1. (obsolete) (deleted) — Splinter Review
Please treat as high priority if possible. Thanks!
Attachment #672115 - Flags: review?(robert.bugzilla)
Attached patch Patch v2. (deleted) — Splinter Review
Fixed comment.
Attachment #672115 - Attachment is obsolete: true
Attachment #672115 - Flags: review?(robert.bugzilla)
Comment on attachment 672116 [details] [diff] [review] Patch v2. Looks fine. Do you think this has to do more with the desktop AUS servers supporting Cache-Control and the test server not?
Attachment #672116 - Flags: review+
(In reply to Robert Strong [:rstrong] (do not email) from comment #9) > Comment on attachment 672116 [details] [diff] [review] > Patch v2. > > Looks fine. Do you think this has to do more with the desktop AUS servers > supporting Cache-Control and the test server not? Thanks for the super quick review. No, I think that what happened is the device already had the update.xml cached. Cache-Control: no-cache has no effect for client side caching. I think the reason I wasn't seeing this on desktop is because on B2G we were getting an offline error and on desktop I was testing by turning off my wifi so I probably was getting a socket error. Either that or I didn't have it cached locally for whatever reason. I probably would have reproduced if I would have changed the remote manifest though and didn't test disconnecting at all. For what it's worth, the workaround that I had originally planned would have also fixed this. I think this problem does happen on desktop as well though, and I think that there is a chance people could be upgrading to an older version sometimes. But since our cache is corrupted on 10% of startups on Windows and 25% on Linux we probably don't see that problem often.
Please do not land this work until I run it through try.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: