This bug has two implications: * the update notification toaster is not appearing * calling checkForUpdates from the app (for example https://github.com/julienw/self-updating-packaged-app) will not return that an update is available However we correctly have the update notification in the notification panel because the system app keeps the information. I think this may be fixed by sending a "downloadavailable" event even when we get a 304 status from the server, if app.downloadAvailable is true.

Needs more info to make blocking call. Does this always reproduce? On a specific testcase? On stubs only? Can you give a minddump of info here?

This always reproduce from an app which controls its own update mechanism, like the stubs yes. I asked a nomination because it seems to be a safe patch. However I agree this is a minor case.

(In reply to Julien Wajsberg [:julienw] from comment #2) > This always reproduce from an app which controls its own update mechanism, > like the stubs yes. > > I asked a nomination because it seems to be a safe patch. However I agree > this is a minor case. Okay. We do have do stubs for v1 for preloads though, which actually does make me think this blocks. Screwing up a download once and then not being able to recover for a preload would probably not make Rick happy.

That should block.

Comment on attachment 703663 [details] [diff] [review] patch tested and approved ! works for me, thanks

Comment on attachment 703663 [details] [diff] [review] patch [Triage Comment]

Landed on mozilla-b2g18/gaia master prior to the 1/25 branching to mozilla-b2g18_v1_0_0/v1.0.0, updating status-b2g-v1.0.0 to fixed.