Update fails for Latch app

NEW
Unassigned

Status

Firefox OS
General
3 years ago
3 years ago

People

(Reporter: joseenrique.alvarezfernandez, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

3 years ago
Similar to Hubii bug (see https://bugzilla.mozilla.org/show_bug.cgi?id=1145614)

Testing on SORA update to v2.0 I receive some notification updates being Latch one of them.

The app version that was preloaded BEFORE the update was Latch 0.3.0 that is the last version published on the marketplace. It's weird to receive an update if the last version is the one preloaded
Nevertheless, I've updated all them and the one that fails is Latch.

In this case, Hubii updates prefectly.
(Reporter)

Comment 1

3 years ago
Created attachment 8586041 [details]
latch.txt

Here is a logcat of what happened while trying to update Latch by accepting the update notification. Hope it helps

Updated

3 years ago
Assignee: nobody → mpillard
Priority: -- → P2
(Reporter)

Comment 2

3 years ago
Hi guys

I've provided again more information on bug https://bugzilla.mozilla.org/show_bug.cgi?id=1145614 as it seems that the same context is affecting both apps.

In this case I'm testing with SORA with v.20

Please follow the steps described:
1. Start the device for the first time (make a factory reset if necessary)and connect it to Wifi/3G
2. Check that Latch app is placed correctly and working fine (it is).Wait for the update notification
3. I received a message of 3 updates available: Hubii,  Line, Latch
4. Tap on Download
5. Downloading starts
6. All apps update adequately BUT Latch. A message appears "There was an error while downloading the updates"
7. Latch app is not updated as a red icon with an arrow appears where the app was.
8. By tapping on that red icon, a message asking if you want to download the app appears. If you tap on download it seems to start downloading until a message "There was an error while downloading the updates"
Priority: P2 → P1
Hi,

Since I don't have your device or your build it's hard for me to reproduce. The logs you pasted does not include enough info, so can you try reproducing and pasting the adb logcat, but with the following done first:
- Console enabled in settings > developer > debug menu
- "dom.mozApps.debug" preference set to true (you can use this script https://github.com/julienw/config-files/blob/master/addpref to enable it, by just launching "addpref logs")

Thanks.
Priority: P1 → P2
(Reporter)

Comment 4

3 years ago
Hi guys

I'll try do send them to you tomorrow but I may need more info on how to set the "dom.mozApps.debug" to true.

Could you please provide to me a step by step process?
(Reporter)

Comment 5

3 years ago
Hi Mathieu

I'm not going to be able to make a logcat as you request because I need to have a rooted device and I cannot root it.

Is there any other way I can help you with? any other way I can make a logcat that helps you?
Without this, logcat is useless to me :(

Alternatively, I'd need to have a look at the code of the build you are using, to at least see if the preloaded apps configuration looks correct.
(Reporter)

Comment 7

3 years ago
Going to try to provide you with that information
Dear Ling Ling, 

Seems a similar issue than raised in bug #1145614. Can you please take a look?

Thanks, 
David
Flags: needinfo?(zhaolingling)

Comment 9

3 years ago
Sorry for the late response.

Please see my comment in https://bugzilla.mozilla.org/show_bug.cgi?id=1145614#c31.

Thanks.
Flags: needinfo?(zhaolingling)

Comment 10

3 years ago
Created attachment 8596527 [details]
log&json.zip

Hi,

I can reproduce this issue in both Sora and Midori device, and has set "dom.mozApps.debug" preference to true in the device. 

Please see the log and webapps.json from /data/local/webapps/ in device. 
note: In the attachment I add both of them in these two devices because more logs are enabled in the SW in my Midori device, so maybe it can provide more useful information.
Flags: needinfo?(mpillard)
The logs from your Sora device don't tell much, but the log from your Midori device, together the webapps.json from both devices, do seem to indicate that somehow your devices don't think they have the latest version of the app even though they have the latest etags. So when they look for an update, the server returns them the etag they already have, and you end up getting a PACKAGED_UNCHANGED error.

So it looks like something is wrong on the Firefox OS side, not on the Marketplace side. This looks *very* similar to bug 1150442.
Flags: needinfo?(mpillard)

Comment 12

3 years ago
Although they looks very similar, but as I explained in Comment 31 in bug 1145614, bug 1150442 is caused by a special test patch which is not merged into the offical SW. 
I also test this bug in the Midori device including the patch for bug 1150442, but the issue still happens.
We need more investigation.

Comment 13

3 years ago
Created attachment 8597058 [details]
zip&json&log.zip

Hi  Mathieu,

I attached the packages of latch before and after the update along with webapps.json and log.

Comparing these two packages, application.zip and manifest.webapp are the same. So although there is something difference in the latest manifest.webapp(etag is changed), no update for it in fact.

I make another test: get the latest Pinteret app and modify some strings in etag filed in its metadata.json, then preinstall this app in my device. After check the update, update available for Pinterest is included in the notification. Click the Download button, the same issue happens.

I think what we should do here is to try to make the app work as previous, but not show a message asking if you want to download the app.
So you already have the 0.3.0 version before you attempt the update, but the etag you have for the manifest is wrong (it may have come from an older version, or from a wrong copy/paste).

I agree that Firefox OS should not present the user with an update then, but on the other hand, if we want to fix this now, it's simply fix the etag for the preloaded apps that don't behave correctly.

Anyway, that's not a Marketplace bug, so I'll update the product&component and reset priority.
Assignee: mpillard → nobody
Component: Developer Pages → General
OS: Windows 7 → All
Priority: P2 → --
Product: Marketplace → Firefox OS
Hardware: x86 → All
Version: Avenir → unspecified

Updated

3 years ago
Duplicate of this bug: 1145614

Comment 16

3 years ago
Hi Mathieu,

I donot think the etag before the update in my side is wrong, because it also came from https://marketplace.firefox.com/app/134b968d-3566-4564-9b78-e02369eb9d01/manifest.webapp and without any modification. Maybe the developer modifies it later, I am not sure.

Simply fix the etag for Latch may work, but maybe similar issue happens again on other apps. It is neccesary to fix it adically.
Flags: needinfo?(mpillard)

Comment 17

3 years ago
Hi Mathieu,

I find this issue has been fixed already:
http://mxr.mozilla.org/mozilla-b2g32_v2_0/source/dom/apps/src/Webapps.jsm?rev=a8ebdfd96f95#3500

I will take this patch in my side.

Comment 18

3 years ago
Oh....
Actually the code
if (aError == "PACKAGE_UNCHANGED") 
should be
if (aError == "Error: PACKAGE_UNCHANGED")
(In reply to Lingling Zhao from comment #17)
> Hi Mathieu,
> 
> I find this issue has been fixed already:
> http://mxr.mozilla.org/mozilla-b2g32_v2_0/source/dom/apps/src/Webapps.
> jsm?rev=a8ebdfd96f95#3500
> 
> I will take this patch in my side.

Hi Lingling, would you help confirm, if the patch you found works for this issue now? Thanks!
Flags: needinfo?(zhaolingling)

Comment 20

3 years ago
Hi Wesly,

Because we lack some other patches in our side in this file, so I need to modify the patch as Comment 18, then it works. 

I find Wookduck has this patch(without any modification) already and this issue is not reproduce in Wookduck, so that shows it really works.
Flags: needinfo?(zhaolingling)
(In reply to Lingling Zhao from comment #20)
> Hi Wesly,
> 
> Because we lack some other patches in our side in this file, so I need to
> modify the patch as Comment 18, then it works. 
> 
> I find Wookduck has this patch(without any modification) already and this
> issue is not reproduce in Wookduck, so that shows it really works.

Sounds great, thanks Lingling!
re comment 16, our etags may have been affected briefly by bug 1145160 ; there is a few days window during which we served outdated mini-manifests with wrong etags.

So it all depends on when the manifest was downloaded to build the image with the preloaded apps.
Flags: needinfo?(mpillard)
You need to log in before you can comment on or make changes to this bug.