Closed
Bug 827047
Opened 12 years ago
Closed 12 years ago
A signed packaged app update through Marketplace never triggers Gaia app update notification (see attached testcase)
Categories
(Core Graveyard :: DOM: Apps, defect)
Tracking
(blocking-basecamp:+, firefox19 wontfix, firefox20 wontfix, firefox21 fixed, b2g18 fixed)
People
(Reporter: jsmith, Assigned: daleharvey)
References
Details
(Keywords: testcase)
Attachments
(4 files, 2 obsolete files)
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•12 years ago
|
blocking-basecamp: --- → ?
Reporter | ||
Updated•12 years ago
|
Blocks: market-packaged-apps
Reporter | ||
Comment 1•12 years ago
|
||
Build: B2G 18 1/5/2013
Device: Unagi
Comment 2•12 years ago
|
||
How long did you wait after the manual check? The notification is still shown after a 30sec "grouping timeout" by default.
Comment 3•12 years ago
|
||
Yep, getting the notification exactly 30sec after the manual check here.
This looks like a duplicate of the (minused :/) bug 814055.
Reporter | ||
Comment 4•12 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 | ||
Updated•12 years ago
|
QA Contact: jsmith
Reporter | ||
Comment 6•12 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•12 years ago
|
blocking-basecamp: ? → ---
Reporter | ||
Comment 7•12 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•12 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•12 years ago
|
||
No dice after 10 minutes :(.
Comment 10•12 years ago
|
||
(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•12 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.
Comment 12•12 years ago
|
||
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•12 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•12 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.
Comment 15•12 years ago
|
||
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
Updated•12 years ago
|
blocking-basecamp: ? → +
Reporter | ||
Comment 16•12 years ago
|
||
Confirmed this with Etienne - yeah this shouldn't have anything to do with whether it's manual or automatic.
Assignee | ||
Updated•12 years ago
|
Assignee: nobody → dale
Reporter | ||
Comment 17•12 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 | ||
Comment 18•12 years ago
|
||
Reporter | ||
Comment 19•12 years ago
|
||
Reporter | ||
Comment 20•12 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•12 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)
Comment 21•12 years ago
|
||
(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.
Comment 22•12 years ago
|
||
Rob> have you checked that the ETag changed too ?
Comment 23•12 years ago
|
||
(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)
Comment 24•12 years ago
|
||
(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•12 years ago
|
||
Attachment #699202 -
Flags: review?(fabrice)
Reporter | ||
Updated•12 years ago
|
Component: Gaia::System → DOM: Apps
Product: Boot2Gecko → Core
Version: unspecified → Trunk
Assignee | ||
Comment 26•12 years ago
|
||
Updated to include other instances of application updates
Attachment #699202 -
Attachment is obsolete: true
Attachment #699202 -
Flags: review?(fabrice)
Assignee | ||
Updated•12 years ago
|
Attachment #699211 -
Flags: review?(fabrice)
Comment 27•12 years ago
|
||
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•12 years ago
|
||
Added PackageEvent to commented broadcast messages
Attachment #699211 -
Attachment is obsolete: true
Attachment #699344 -
Flags: checkin?(fabrice)
Assignee | ||
Updated•12 years ago
|
Keywords: checkin-needed
Assignee | ||
Updated•12 years ago
|
Attachment #699344 -
Flags: checkin?(fabrice)
Reporter | ||
Comment 29•12 years ago
|
||
Ed - Can you help land this on inbound and b2g18?
Flags: needinfo?(emorley)
Comment 30•12 years ago
|
||
Flags: needinfo?(emorley)
Keywords: checkin-needed
Comment 31•12 years ago
|
||
status-b2g18:
--- → fixed
status-firefox19:
--- → wontfix
status-firefox20:
--- → wontfix
status-firefox21:
--- → fixed
Target Milestone: --- → mozilla21
Reporter | ||
Comment 32•12 years ago
|
||
inbound + b2g18 = closing.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Comment 33•12 years ago
|
||
Reporter | ||
Updated•12 years ago
|
Reporter | ||
Comment 34•12 years ago
|
||
Looks good - tested this on prod and I got the update to fire.
Status: RESOLVED → VERIFIED
Keywords: verifyme
Updated•7 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•