877984 - [Buri] Trying to update a hosted app preloading appcache that was preinstalled will fail to update

Status: RESOLVED FIXED

(Core Graveyard :: DOM: Apps, defect, P2)

Description

[sync-1]

AU_LINUX_GECKO_ICS_STRAWBERRY_V1.01.00.01.019.121
 Firefox os  v1.0.1
 Mozilla build ID:20130527070203
 
 DEFECT DESCRIPTION:
 
 STR:
 1. pre-install some 3rd party apps.
 2. flash code to device.
 3. connect to network with wifi.
 4. there will popup apps update available notification.
 5. click Download to update the apps, but the download failed.
 
 Note: Currently "AccuWeather" and "Wikipedia" are failed to update.
 
 
  REPRODUCING PROCEDURES:
 
  EXPECTED BEHAVIOUR:
 
 the apps can be updated.
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 
  For FT PR, Please list reference mobile's behavior:

Comment 1

[sync-1]

Clone from brother

Comment 2

[sync-1]

Attachment: log for update failed.

Clone from brother

Comment 3

[Joe Cheng [:jcheng] (please needinfo)]

karen/jason, what's your thoughts on this? thanks

Comment 4

[Jason Smith [:jsmith]]

(In reply to Joe Cheng [:jcheng] from comment #3)
> karen/jason, what's your thoughts on this? thanks

Uh oh. We recently modified how we preinstall appcache for hosted apps that preinstall appcache. Which Accuweather and Wikipedia happen to fall into that category. Let me see if I can reproduce.

Btw - the log doesn't tell me anything. needinfo on fabrice to see if he has any ideas as well.

Comment 5

[Jason Smith [:jsmith]]

I can reproduce on a Ikura 5/30 build. This is bad.

Comment 6

[Jason Smith [:jsmith]]

Attachment: Webapps JSON - Check for Update, No Update Started

Comment 7

[Jason Smith [:jsmith]]

Attachment: Webapps JSON - After Update Applied

Comment 8

[Jason Smith [:jsmith]]

Attachment: Logcat of Update Failure from jsmith's test

Comment 9

[Jason Smith [:jsmith]]

Trying to do a second update after the update failure causes the download to get stuck at 0.00 bytes. This sounds like a dom apps bug.

Comment 10

[Jason Smith [:jsmith]]

Uh oh. Saw this in the logs during the 0.00 bytes downloading:

05-31 09:44:49.899: E/GeckoConsole(113): Content JS INFO at app://system.gaiamobile.org/js/updatable.js:102 in anonymous: downloadError event, error code is NO_DOWNLOAD_AVAILABLE

Comment 11

[Jason Smith [:jsmith]]

Root cause bug here btw:

Trying to update a hosted app preloading appcache that was preinstalled will fail to update

Comment 12

[[:fabrice] Fabrice Desré]

I installed the spain customization and set debug on in webapps.jsm. When we check for updates I get: 

-*-*- Webapps.jsm : updateHostedApp: updateSvc.checkForUpdate return for http://m.accuweather.com/mozilla.webapp - event is offline-cache-update-available

-*-*- Webapps.jsm : updateHostedApp: updateSvc.checkForUpdate return for https://bits.wikimedia.org/WikipediaMobileFirefoxOS/manifest.webapp - event is offline-cache-update-available

I then only selected accuweather to update:
I/Gecko   ( 1979): -*-*- Webapps.jsm : startDownload for http://m.accuweather.com/mozilla.webapp
I/Gecko   ( 1979): -*-*- Webapps.jsm : appcache found
I/Gecko   ( 1979): -*-*- Webapps.jsm : Saving /data/local/webapps/webapps.json
I/Gecko   ( 1979): -*-*- Webapps.jsm : Creating AppcacheObserver for http://m.accuweather.com - updating
I/Gecko   ( 1979): -*-*- Webapps.jsm : Offline cache state change for http://m.accuweather.com : 5
I/Gecko   ( 1979): -*-*- Webapps.jsm : Offlinecache setStatus to updating with progress 0 for http://m.accuweather.com
I/Gecko   ( 1979): -*-*- Webapps.jsm : Offline cache state change for http://m.accuweather.com : 6
I/Gecko   ( 1979): -*-*- Webapps.jsm : Offlinecache setStatus to updating with progress 0 for http://m.accuweather.com
I/Gecko   ( 1979): -*-*- Webapps.jsm : Offline cache state change for http://m.accuweather.com : 6
I/Gecko   ( 1979): -*-*- Webapps.jsm : Offlinecache setStatus to updating with progress 0 for http://m.accuweather.com
I/Gecko   ( 1979): -*-*- Webapps.jsm : Offline cache state change for http://m.accuweather.com : 6
I/Gecko   ( 1979): -*-*- Webapps.jsm : Offlinecache setStatus to updating with progress 0 for http://m.accuweather.com
I/Gecko   ( 1979): -*-*- Webapps.jsm : Offline cache state change for http://m.accuweather.com : 8
I/Gecko   ( 1979): -*-*- Webapps.jsm : Offlinecache setStatus to updating with progress 512 for http://m.accuweather.com
I/Gecko   ( 1979): -*-*- Webapps.jsm : Offline cache state change for http://m.accuweather.com : 8
I/Gecko   ( 1979): -*-*- Webapps.jsm : Offline cache state change for http://m.accuweather.com : 7
I/Gecko   ( 1979): -*-*- Webapps.jsm : Offline cache state change for http://m.accuweather.com : 8
I/Gecko   ( 1979): -*-*- Webapps.jsm : Offline cache state change for http://m.accuweather.com : 8
I/Gecko   ( 1979): -*-*- Webapps.jsm : Offline cache state change for http://m.accuweather.com : 7
I/Gecko   ( 1979): -*-*- Webapps.jsm : Offline cache state change for http://m.accuweather.com : 8
I/Gecko   ( 1979): -*-*- Webapps.jsm : Offlinecache setStatus to updating with progress 21893 for http://m.accuweather.com
I/Gecko   ( 1979): -*-*- Webapps.jsm : Offline cache state change for http://m.accuweather.com : 8
I/Gecko   ( 1979): -*-*- Webapps.jsm : Offline cache state change for http://m.accuweather.com : 8
I/Gecko   ( 1979): -*-*- Webapps.jsm : Offline cache state change for http://m.accuweather.com : 8
I/Gecko   ( 1979): -*-*- Webapps.jsm : Offline cache state change for http://m.accuweather.com : 8
I/Gecko   ( 1979): -*-*- Webapps.jsm : Offline cache state change for http://m.accuweather.com : 8
I/Gecko   ( 1979): -*-*- Webapps.jsm : Offline cache state change for http://m.accuweather.com : 8
I/Gecko   ( 1979): -*-*- Webapps.jsm : Offlinecache setStatus to updating with progress 41193 for http://m.accuweather.com
I/Gecko   ( 1979): -*-*- Webapps.jsm : Offline cache state change for http://m.accuweather.com : 8
I/Gecko   ( 1979): -*-*- Webapps.jsm : Offline cache state change for http://m.accuweather.com : 8
I/Gecko   ( 1979): -*-*- Webapps.jsm : Offline cache state change for http://m.accuweather.com : 8
I/Gecko   ( 1979): -*-*- Webapps.jsm : Offline cache state change for http://m.accuweather.com : 8
I/Gecko   ( 1979): -*-*- Webapps.jsm : Offline cache state change for http://m.accuweather.com : 8
I/Gecko   ( 1979): -*-*- Webapps.jsm : Offline cache state change for http://m.accuweather.com : 8
I/Gecko   ( 1979): -*-*- Webapps.jsm : Offline cache state change for http://m.accuweather.com : 7
E/GeckoConsole( 1979): Offline cache update done, URL=http://m.accuweather.com/awx.appcache
I/Gecko   ( 1979): -*-*- Webapps.jsm : Offline cache state change for http://m.accuweather.com : 10
I/Gecko   ( 1979): -*-*- Webapps.jsm : Offlinecache setStatus to installed with progress 52690 for http://m.accuweather.com

So everything went fine here also, and I have one less app in the "to update" list. I then selected wikipedia to update, and that worked too.

Comment 13

[Jason Smith [:jsmith]]

Fabrice - What device did you test that on?

I reproduced this on Ikura, FWIW.

Comment 14

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #13)
> Fabrice - What device did you test that on?
> 
> I reproduced this on Ikura, FWIW.

Ikura partner build 5/30 to be specific.

Comment 15

[[:fabrice] Fabrice Desré]

I tested on v1-train with a leo device. I have no 1.01 build ready that I can tweak quickly

Comment 16

[Jason Smith [:jsmith]]

And now I'm not even getting updates for the wikipedia and accuweather apps after restarting the phone and checking for updates on the partner build. Let me flash a clean build and try testing this again.

Comment 17

[Jason Smith [:jsmith]]

Still reproduces for me on a clean flashed 5/30 Ikura partner build.

Comment 18

[Jason Smith [:jsmith]]

Weird. So apparently this problem fixes itself on a restart after applying the update (or we stopped checking for updates entirely). We need to understand which one it is however:

1. Did we complete the update after a restart?
2. Did we give up permanently on trying to find an update after a restart?

Comment 19

[[:fabrice] Fabrice Desré]

I checked on a buri with a current 1.0.1 build (I had to rebuild gecko to add debug info) and this worked like expected. I'm confused.

Comment 20

[Jason Smith [:jsmith]]

I flashed a different customization this time (before was latam, this time I did spain) for Ikura. Still can reproduce this bug with Accuweather and Wikipedia.

This time I tested this with a spain customization on a 5/28 partner build.

Comment 22

[Joe Cheng [:jcheng] (please needinfo)]

i am seeing the same thing on Buri partner build just as reported and as Jason

Comment 23

[Kai-Chih Hu [:khu]]

It looks like a tef+ bug to me.

Comment 24

[Kai-Chih Hu [:khu]]

(In reply to Fabrice Desré [:fabrice] from comment #19)
> I checked on a buri with a current 1.0.1 build (I had to rebuild gecko to
> add debug info) and this worked like expected. I'm confused.

Fabrice, did you use partner customized build? Thanks.

Comment 25

[Walter Chen[:ypwalter][:wachen]]

I can reproduce this bug in both Buri and Ikura.

Comment 26

[Karen Ward [:kward]]

Moved to TEF+ based on discussion with Carrier (Shira - Stephan F)

Comment 27

[Jason Smith [:jsmith]]

(In reply to [e-mail] from comment #26)
> Moved to TEF+ based on discussion with Carrier (Shira - Stephan F)

Agreed.

(In reply to khu from comment #24)
> (In reply to Fabrice Desré [:fabrice] from comment #19)
> > I checked on a buri with a current 1.0.1 build (I had to rebuild gecko to
> > add debug info) and this worked like expected. I'm confused.
> 
> Fabrice, did you use partner customized build? Thanks.

I'm think the testing Fabrice is doing here is with debug builds to see if he can reproduce generally on our own builds. Which it looks like we cannot reproduce it on own builds. But we can reproduce it on partner builds. This is definitely strange.

I'll debug with this with Fabrice today.

Comment 28

[Jason Smith [:jsmith]]

Some context from discussion with fabrice in IRC:

fabrice	jsmith: I reproed the update issue. Not sure yet if it's a gecko or gaia issue, but it seems gaia restarts updates for already updated apps and that fails
jsmith	fabrice: Hmm okay. Did you reproduce it on the partner build or your own build?
fabrice	jsmith: partner build, but what happens is : first update went fine, but then gaia still insists that we can update the app, and this fails
fabrice	something is definitely wrong somewhere
jsmith	fabrice: That's really strange. So that actually explains why then if I restart the phone, I never find that I have an update available.
fabrice	yes

Comment 29

[[:fabrice] Fabrice Desré]

I re-tested using a partner build (P752D04_TME_FOR_PARTENER_20130602), where the only change I made was enabling debug output in Webapps.jsm and adding some in Webapps.js

Here's what I saw:
1) At first check for updates, I'm offered 7 updates, including accuweather and wikipedia that use appcache.
2) I updated accuweather only, that went fine. 6 updates remaining.
3) I updated wikipedia only, that went fine, but I still have 6 updates remaining: accuweather is once again said to be updatable.
4) I tried to update accuweather again, and here I got the never ending throbber with a 0.00 download progress.

The logs for this last step shows this:
I/Gecko   ( 2273): -*-*- Webapps.jsm : startDownload for http://m.accuweather.com/mozilla.webapp
I/Gecko   ( 2273): -*-*- Webapps.jsm : No download available, bailing out with Webapps:PackageEvent canceled
I/Gecko   ( 2421): Webapps.js : canceled, donwloaderror = NO_DOWNLOAD_AVAILABLE
I/Gecko   ( 2273): Webapps.js : canceled, donwloaderror = NO_DOWNLOAD_AVAILABLE
I/Gecko   ( 2273): Webapps.js : canceled, donwloaderror = NO_DOWNLOAD_AVAILABLE
I/Gecko   ( 2273): Webapps.js : canceled, donwloaderror = NO_DOWNLOAD_AVAILABLE

So it looks everything is ok on the gecko side, and webapps.json is consistent with that observation. We need someone to debug the gaia side at this point.

Comment 30

[Jason Smith [:jsmith]]

Hmm...okay. Julien is on PTO.

Etienne - Can you help with debugging this on the Gaia side?

Comment 31

[Jason Duell]

cc'ing honza in case there's gecko bits involved here--but sounds like this is prob a gaia bug.

Comment 32

[Tim Guan-tin Chien [:timdream] (please needinfo)]

I am |console.log| through the updatable.js in Gaia ... so far I got errorCallback filed for Wikipedia update.

Comment 33

[Tim Guan-tin Chien [:timdream] (please needinfo)]

I tried to reproduce this on unagi without success; they both updated successfully on the second try.

Comment 34

[Jason Smith [:jsmith]]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #33)
> I tried to reproduce this on unagi without success; they both updated
> successfully on the second try.

Testing we've done here so far has revealed that only reproduces on partner builds, not builds we make.

Comment 35

[Tim Guan-tin Chien [:timdream] (please needinfo)]

OK, here is the STR and the bug I saw, specifically on Gaia (and maybe Gecko on it's API design) is that

0. On a Unagi
1. Latest OTA Gecko, do |make reset-gaia| on Gaia v1.0.1 with Accuweather and Wikipedia copied to external-apps.
2. Wait for some time and the update dialog will pop-up, for update are offered (Here map, Marketplace, Accuweather and Wikipedia).
3. Press "update all"
4. Marketplace and Here map will fail with error code NO_DOWNLOAD_AVAILABLE, Wikipedia and Accuweather will be updated.

Expected

1. Two "update failed" banner will be shown. The update hint on the utility tray will stop offer Wikipedia and Accuweather, but give the user a change to re-try Here map and Marketplace.

Actual

1. The update hint on the utility tray stay the same, offers four app updates.
2. As soon as I press the the "update all" again, the same expected update error will shown for Marketplace and Here map
3. But for Wikipedia and Accuweather, no callback (error nor success) will ever fired by Gecko.
4. The UI will keep showing "downloading... 0.00 bytes downloaded." and never finish.

Comment 36

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Jason Smith [:jsmith] from comment #34)
> (In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #33)
> > I tried to reproduce this on unagi without success; they both updated
> > successfully on the second try.
> 
> Testing we've done here so far has revealed that only reproduces on partner
> builds, not builds we make.

OK, maybe the bug of previous comment is unrelated?

If this only happens on partner build, I will not be able to debug it because I cannot remount the system partition.

Comment 37

[James Lal [:lightsofapollo]]

Attachment: Debugging code for gaia

Comment 38

[James Lal [:lightsofapollo]]

Did some initial investigation and was able to reproduce on partner build... I was not able to come up with a quick fix before my EOD- debug patch attached above maybe this will be somewhat helpful... If there is not a patch by the morning I will continue looking into it.

Comment 39

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Update: I think Etienne or anyone would be happy to deliver a fix if this bug explicitly is about what I mentioned on comment 35.

I don't want to push for a unrelated fix on the same place and not actually fix the bug.

Comment 40

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Rudy and I is now working on reproduce the bug on pvt build.

Comment 41

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #40)
> Rudy and I is now working on reproduce the bug on pvt build.

I am currently having trouble reproducing this on pvt build because the phone does not offer me an update.

Comment 42

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Jason Smith [:jsmith] from comment #28)
> Some context from discussion with fabrice in IRC:
> 
> fabrice	jsmith: I reproed the update issue. Not sure yet if it's a gecko or
> gaia issue, but it seems gaia restarts updates for already updated apps and
> that fails
> jsmith	fabrice: Hmm okay. Did you reproduce it on the partner build or your
> own build?
> fabrice	jsmith: partner build, but what happens is : first update went fine,
> but then gaia still insists that we can update the app, and this fails
> fabrice	something is definitely wrong somewhere
> jsmith	fabrice: That's really strange. So that actually explains why then if
> I restart the phone, I never find that I have an update available.
> fabrice	yes

Base on this comment I would say we somehow manage to reproduce the same thing (comment 35) but with different steps. I am now trying to find a way to fix that issue, but the original author (Etienne) should work on this in if he is available.

Comment 43

[Tim Guan-tin Chien [:timdream] (please needinfo)]

I am now convinced that Gecko is at fault here.

UpdateManager kepts all the reference of available-for-update app in |UpdateManager.updatesQueue|, and the reference is supposed to be removed once there is no update available (i.e. update is applied).

If you update 2 apps at the same time, when the #1 app completes it's update, we do removed the apps in |removeFromUpdatesQueue()|; that part of the code didn't fail. However, The #1 app is being add back to the queue by |checkStatuses()| as soon as all #2 is downloaded and the queue is empty.

https://github.com/mozilla-b2g/gaia/blob/88277996/apps/system/js/update_manager.js#L461

|checkStatuses()| will look for |app.downloadAvailable| flag, and the flag is true for the updated app, so it's being add back to the queue.

Comment 44

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #43)
> |checkStatuses()| will look for |app.downloadAvailable| flag, and the flag
> is true for the updated app, so it's being add back to the queue.

Long story short: |app.downloadAvailable| flag did not flip to false after a successful app update.

Comment 45

[Etienne Segonzac (:etienne)]

Summing up the comments it looks like the fundamental issue is that we have an app in the |UpdateManager.updatesQueue| that shouldn't be here anymore.
If true rebooting the phone should fix the problem (since we don't persist the updates queue on the gaia side).

Looking at the gecko code it looks like the app object is always updated properly before the success/error callback is called. So not sure what's causing the updates queue to get out of sync.

That said, an easy and safe change would be to remove any app where |!app.downloadAvailable| from the updates queue in the |checkStatuses()| method.

I'll send a WIP asap but I'll need QA.

Comment 46

[Etienne Segonzac (:etienne)]

So, scratch Comment 45 :) (Thanks Tim!)

Looks like the gecko code updates the |app.downloadAvailable| properly for Webapps:PackageEvent messages but not for Webapps:OfflineCache messages [1].

So in gaia we see that, even if there was an error, |app.downloadAvailable| is still true so we keep the app in the updates queue [2].

[1] https://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.js#567
[2] https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/updatable.js#L107

Comment 47

[Etienne Segonzac (:etienne)]

Attachment: WIP

Last time I tried to write a quick patch for Webapps.jsm it didn't end well :)

But I _think_ this could help.

Comment 48

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Etienne Segonzac (:etienne) from comment #47)
> Created attachment 757904 [details] [diff] [review]
> WIP
> 
> Last time I tried to write a quick patch for Webapps.jsm it didn't end well
> :)
> 
> But I _think_ this could help.

Wrong patch?

Comment 49

[Etienne Segonzac (:etienne)]

Attachment: WIP

The good patch.

Comment 50

[Etienne Segonzac (:etienne)]

Leaving breadcrumbs for Fabrice.

- I'm not able to reproduce the issue in tests :/
- looks like the downloadAvailable flag should already be correctly taken care of for AppCache apps [1].

[1] https://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.jsm#1496

Comment 51

[Etienne Segonzac (:etienne)]

(In reply to Etienne Segonzac (:etienne) from comment #50)
> Leaving breadcrumbs for Fabrice.
> 
> - I'm not able to reproduce the issue in tests :/

But I'm not sure I understand the test.
The comments says we should always have a new update and then asserts that we never get a |ondownloadavailable| callback [1].


[1] https://mxr.mozilla.org/mozilla-central/source/dom/apps/tests/test_app_update.html?force=1#151

Comment 52

[[:fabrice] Fabrice Desré]

Attachment: patch

This is the simplest and safest patch to fix that. This ensure that https://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.jsm#3204 and https://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.js#567 are kept in sync.

We should also fix the bug in gaia where we don't honor the downloaderror after doing a startDownload() while downloadAvailable is false.

Comment 53

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Fabrice Desré [:fabrice] from comment #52)
> We should also fix the bug in gaia where we don't honor the downloaderror
> after doing a startDownload() while downloadAvailable is false.

errorCallback didn't fire in this case; Gecko should have fire the callback when |startDownload()| is call while downloadAvailable is false. Anyhow, let's fix the |downloadAvailable| first.

Comment 54

[[:fabrice] Fabrice Desré]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #53)
> (In reply to Fabrice Desré [:fabrice] from comment #52)
> > We should also fix the bug in gaia where we don't honor the downloaderror
> > after doing a startDownload() while downloadAvailable is false.
> 
> errorCallback didn't fire in this case; Gecko should have fire the callback
> when |startDownload()| is call while downloadAvailable is false. Anyhow,
> let's fix the |downloadAvailable| first.

I'm sorry Tim but that's not true. I have debug traces showing gecko firing the event in this case (see comment 29,  but you did not try to repro these steps).

Comment 55

[Gene Lian (I already quit Mozilla)]

Comment on attachment 758062 [details] [diff] [review]
patch

I'm helping land this to all the needed branches.

Comment 56

[Gene Lian (I already quit Mozilla)]

https://hg.mozilla.org/projects/birch/rev/c8e85b2b4cce
https://hg.mozilla.org/releases/mozilla-b2g18/rev/d380b5f79cc4
https://hg.mozilla.org/releases/mozilla-b2g18_v1_1_0_hd/rev/50526cfc0100
https://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/2a92e4932728

Comment 57

[Gene Lian (I already quit Mozilla)]

(In reply to Gene Lian [:gene] from comment #56)
> https://hg.mozilla.org/projects/birch/rev/c8e85b2b4cce
> https://hg.mozilla.org/releases/mozilla-b2g18/rev/d380b5f79cc4
> https://hg.mozilla.org/releases/mozilla-b2g18_v1_1_0_hd/rev/50526cfc0100

Sorry, I just saw bug 810099, comment #61 after landing this. I won't land patches to v1_1_0_hd next time.

> https://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/2a92e4932728

Comment 58

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Fabrice Desré [:fabrice] from comment #54)
> I'm sorry Tim but that's not true. I have debug traces showing gecko firing
> the event in this case (see comment 29,  but you did not try to repro these
> steps).

Hum, I am seeing the entire opposite in Gaia :-/

Comment 59

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/c8e85b2b4cce

Comment 60

[Honza Bambas (:mayhemer)]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #58)
> (In reply to Fabrice Desré [:fabrice] from comment #54)
> > I'm sorry Tim but that's not true. I have debug traces showing gecko firing
> > the event in this case (see comment 29,  but you did not try to repro these
> > steps).
> 
> Hum, I am seeing the entire opposite in Gaia :-/

Can you please clearly state if there is anything wrong in Gecko?

If so, please open a new bug (CC me) and put reliable and as much as possible simple STR, thanks.

Comment 61

[[:fabrice] Fabrice Desré]

(In reply to Honza Bambas (:mayhemer) from comment #60)
> 
> Can you please clearly state if there is anything wrong in Gecko?
> 
> If so, please open a new bug (CC me) and put reliable and as much as
> possible simple STR, thanks.

Honza, there was no problem with the appcache implementation itself here.

Comment 62

[Honza Bambas (:mayhemer)]

(In reply to Fabrice Desré [:fabrice] from comment #61)
> Honza, there was no problem with the appcache implementation itself here.

Thanks.

Comment 63

[Etienne Segonzac (:etienne)]

(In reply to Fabrice Desré [:fabrice] from comment #52)
> We should also fix the bug in gaia where we don't honor the downloaderror
> after doing a startDownload() while downloadAvailable is false.

We do honor it, we always display the error banner and remove the app from the active downloads.

We just don't remove the app from the _available_ updates if the app still has downloadAvailable set to true.

Comment 64

[Jason Smith [:jsmith]]

On a 6/6 Buri 1.01 build, this patch doesn't work for me. I'm still failing to update Accuweather and Wikipedia.

Comment 65

[Jason Smith [:jsmith]]

Followup filed in bug 880826.