A signed packaged app update through Marketplace never triggers Gaia app update notification (see attached testcase)

VERIFIED FIXED in Firefox 21

Status

VERIFIED FIXED
6 years ago
a year ago

People

(Reporter: jsmith, Assigned: daleharvey)

Tracking

({testcase})

Trunk
mozilla21
ARM
Gonk (Firefox OS)
testcase
Dependency tree / graph

Firefox Tracking Flags

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

Details

Attachments

(4 attachments, 2 obsolete attachments)

(Reporter)

Description

6 years ago
Created attachment 698335 [details]
Logcat

Followup to bug 823150 after doing a bug verification test. See https://bugzilla.mozilla.org/show_bug.cgi?id=823150#c0 for STR & expected vs. actual results.

Looks like we still do not get the update notification prompt to appear upon trying to do a manual sync. When I check the logcat, it looks like we do know there is an update available:

01-05 13:34:17.870: I/Gecko(109): UpdatePrompt: appsUpdated: 1 apps to update

But no update prompt is showing up in Gaia. The gecko piece of bug 823150 *might* be working, but the Gaia piece definitely isn't.
(Reporter)

Updated

6 years ago
blocking-basecamp: --- → ?
(Reporter)

Updated

6 years ago
Blocks: 823150
(Reporter)

Updated

6 years ago
Blocks: 777048
(Reporter)

Comment 1

6 years ago
Build: B2G 18 1/5/2013
Device: Unagi
How long did you wait after the manual check? The notification is still shown after a 30sec "grouping timeout" by default.
Yep, getting the notification exactly 30sec after the manual check here.
This looks like a duplicate of the (minused :/) bug 814055.
(Reporter)

Comment 4

6 years ago
(In reply to Etienne Segonzac (:etienne) from comment #3)
> Yep, getting the notification exactly 30sec after the manual check here.
> This looks like a duplicate of the (minused :/) bug 814055.

I'll try again, but when I tried this, I didn't get a notification at all for at least 10 minutes.
(Reporter)

Comment 5

6 years ago
Marking qawanted for a retest.
Keywords: qawanted
(Reporter)

Updated

6 years ago
QA Contact: jsmith
(Reporter)

Comment 6

6 years ago
Btw Etienne - How did you test this? I've been testing the packaged app update mechanism through marketplace dev with signed packaged apps. Are you testing this differently possibly than the way I'm testing it?
(Reporter)

Updated

6 years ago
blocking-basecamp: ? → ---
(Reporter)

Comment 7

6 years ago
re-tested with the existing app I already have installed that's v1.0 - no update found, still get same issue:

01-06 10:39:26.759: I/Gecko(507): UpdatePrompt: appsUpdated: 1 apps to update

And no notification. I've waited 10 minutes and I'm not seeing an update available.

I think we're going to need to get understanding of the difference on how I'm testing this through marketplace vs. how you are testing it. It's possible that this only reproduces through marketplace because of something marketplace is doing to serve the update.
blocking-basecamp: --- → ?
Keywords: qawanted
(Reporter)

Comment 8

6 years ago
Well 4 minutes so far, actually. But I'll drop a comment if I see something pop up.

Adding Rob to see if he explain what marketplace is doing when I decide to push a packaged app public from 1.0 --> 1.1. 

Test app being used - https://marketplace-dev.allizom.org/app/privileged-app-test-6/?src=mkt-search
Summary: Followup on bug 823150 - Installing signed packaged app, update it on server, do manual sync - no update notification found → Followup on bug 823150 - Installing signed packaged app, update it on server, do manual sync - no update notification found through Firefox Marketplace
(Reporter)

Comment 9

6 years ago
No dice after 10 minutes :(.
(In reply to Jason Smith [:jsmith] from comment #6)
> Btw Etienne - How did you test this? I've been testing the packaged app
> update mechanism through marketplace dev with signed packaged apps. Are you
> testing this differently possibly than the way I'm testing it?

Yep I'm testing with a classic packaged app on my own server (note that this part of gaia is not making any difference between certified package apps and classic packaged apps).

Getting some marketplace credentials might be useful here, who should I ask?
(Reporter)

Comment 11

6 years ago
(In reply to Etienne Segonzac (:etienne) from comment #10)
> (In reply to Jason Smith [:jsmith] from comment #6)
> > Btw Etienne - How did you test this? I've been testing the packaged app
> > update mechanism through marketplace dev with signed packaged apps. Are you
> > testing this differently possibly than the way I'm testing it?
> 
> Yep I'm testing with a classic packaged app on my own server (note that this
> part of gaia is not making any difference between certified package apps and
> classic packaged apps).
> 
> Getting some marketplace credentials might be useful here, who should I ask?

Rob Hudson should be able to get you access to marketplace dev.

Let's talk in the morning - I have access to marketplace dev, so let's see if we can debug what's going on here.
Blocking- due to requiring manual update check. If updates never occur on the typical use-case (schedule update checks), then re-nom.
blocking-basecamp: ? → -
(Reporter)

Comment 13

6 years ago
(In reply to Dietrich Ayala (:dietrich) from comment #12)
> Blocking- due to requiring manual update check. If updates never occur on
> the typical use-case (schedule update checks), then re-nom.

They don't ever happen. Ever. I don't think this has anything to do with whether it's manual or automatic - see the comment 0 for why. It's finding the update, but the user can't complete it.

Renoming to block.
blocking-basecamp: - → ?
(Reporter)

Comment 14

6 years ago
On a different random note - I'd actually don't think the rationale to not block on manual sync makes sense anyways. That's directly part of v1 requirements, how people in the work week will be generally testing updates, etc. We need this fixed - I don't want our 3rd party app update team getting blocked by this.
(Reporter)

Updated

6 years ago
Keywords: qablocker
Thanks for clarifying -> +
Summary: Followup on bug 823150 - Installing signed packaged app, update it on server, do manual sync - no update notification found through Firefox Marketplace → Signed packaged app updates through Marketplace never trigger Gaia app update notification
blocking-basecamp: ? → +
(Reporter)

Comment 16

6 years ago
Confirmed this with Etienne - yeah this shouldn't have anything to do with whether it's manual or automatic.
(Assignee)

Updated

6 years ago
Assignee: nobody → dale
(Reporter)

Comment 17

6 years ago
Apparently this doesn't fail with all possible packaged app updates - it fails with the test case I had in the original bug this was tied to.

When I tried this with a different test app combo, I got the update notification.
Keywords: qablocker
Summary: Signed packaged app updates through Marketplace never trigger Gaia app update notification → A signed packaged app update through Marketplace never triggers Gaia app update notification (see testcase in bug 823150)
(Reporter)

Updated

6 years ago
Keywords: testcase
(Reporter)

Comment 18

6 years ago
Created attachment 698657 [details]
Privileged App v1.0
(Reporter)

Comment 19

6 years ago
Created attachment 698658 [details]
Privileged App v1.1
(Reporter)

Comment 20

6 years ago
I'm starting to wonder if this is a gecko issue. Putting needsinfo on Fabrice to see what he thinks.
Flags: needinfo?(fabrice)
(Reporter)

Updated

6 years ago
Summary: A signed packaged app update through Marketplace never triggers Gaia app update notification (see testcase in bug 823150) → A signed packaged app update through Marketplace never triggers Gaia app update notification (see attached testcase)
(In reply to Jason Smith [:jsmith] from comment #8)
> Adding Rob to see if he explain what marketplace is doing when I decide to
> push a packaged app public from 1.0 --> 1.1. 

When a reviewer pushes to public behind the scenes we:
* Sign the package with the public certs which also copies them on the filesystem to the correct path to be available publicly.
* Update the mini-manifest so it contains information about the new version and points to the correct download path.
* Updates the search index so the details about the package are updated while searching.

I've verified previously that pushing to public updates the manifest and the file almost immediately after pushing it by using curl/wget to fetch the manifest and zip file.
Rob> have you checked that the ETag changed too ?
(In reply to Jason Smith [:jsmith] from comment #20)
> I'm starting to wonder if this is a gecko issue. Putting needsinfo on
> Fabrice to see what he thinks.

If you see the "01-06 10:39:26.759: I/Gecko(507): UpdatePrompt: appsUpdated: 1 apps to update" log, this means that the checkForUpdate() call effectively found an update. What we could do is check that gaia effectively received the app manifest url that needs to be updated.
Flags: needinfo?(fabrice)
(In reply to Fabrice Desré [:fabrice] from comment #23)
> (In reply to Jason Smith [:jsmith] from comment #20)
> > I'm starting to wonder if this is a gecko issue. Putting needsinfo on
> > Fabrice to see what he thinks.
> 
> If you see the "01-06 10:39:26.759: I/Gecko(507): UpdatePrompt: appsUpdated:
> 1 apps to update" log, this means that the checkForUpdate() call effectively
> found an update. What we could do is check that gaia effectively received
> the app manifest url that needs to be updated.

Gaia only use ondownloadavailable callback BTW we're not looking a the mozchromeevent details.
(Assignee)

Comment 25

6 years ago
Created attachment 699202 [details] [diff] [review]
Send checkForUpdate messages to all registered listeners
Attachment #699202 - Flags: review?(fabrice)
(Reporter)

Updated

6 years ago
Component: Gaia::System → DOM: Apps
Product: Boot2Gecko → Core
Version: unspecified → Trunk
(Assignee)

Comment 26

6 years ago
Created attachment 699211 [details] [diff] [review]
Send successful checkForUpdate messages to all registered listeners

Updated to include other instances of application updates
Attachment #699202 - Attachment is obsolete: true
Attachment #699202 - Flags: review?(fabrice)
(Assignee)

Updated

6 years ago
Attachment #699211 - Flags: review?(fabrice)
Comment on attachment 699211 [details] [diff] [review]
Send successful checkForUpdate messages to all registered listeners

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

::: dom/apps/src/Webapps.jsm
@@ +831,5 @@
>    // Webapps:RemoveApp
>    // Webapps:Install:Return:OK
>    // Webapps:Uninstall:Return:OK
>    // Webapps:OfflineCache
> +  // Webapps:checkForUpdate:Return:OK

Nit: can you also add Webapps:PackageEvent to the list?
Attachment #699211 - Flags: review?(fabrice) → review+
(Assignee)

Comment 28

6 years ago
Created attachment 699344 [details] [diff] [review]
Send successful checkForUpdate messages to all registered listeners

Added PackageEvent to commented broadcast messages
Attachment #699211 - Attachment is obsolete: true
Attachment #699344 - Flags: checkin?(fabrice)
(Assignee)

Updated

6 years ago
Keywords: checkin-needed
(Assignee)

Updated

6 years ago
Attachment #699344 - Flags: checkin?(fabrice)
(Reporter)

Comment 29

6 years ago
Ed - Can you help land this on inbound and b2g18?
Flags: needinfo?(emorley)
https://hg.mozilla.org/releases/mozilla-b2g18/rev/a07224438b0c
status-b2g18: --- → fixed
status-firefox19: --- → wontfix
status-firefox20: --- → wontfix
status-firefox21: --- → fixed
Target Milestone: --- → mozilla21
(Reporter)

Comment 32

6 years ago
inbound + b2g18 = closing.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
(Reporter)

Updated

6 years ago
Keywords: verifyme
(Reporter)

Updated

6 years ago
Blocks: 728081
No longer blocks: 777048
(Reporter)

Comment 34

6 years ago
Looks good - tested this on prod and I got the update to fire.
Status: RESOLVED → VERIFIED
Keywords: verifyme

Updated

a year ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.