Build: B2G18 12/18/2012 Device: Unagi Steps: 1. Install a hosted app from testmanifest.com with default manifest: { "name":"Test App ({subdomain})", "description":"This app has been automatically generated by testmanifest.com", "version":"1.0", "icons":{ "16":"http://testmanifest.com/icon-16.png", "48":"http://testmanifest.com/icon-48.png", "128":"http://testmanifest.com/icon-128.png" }, "installs_allowed_from":[ "*" ], "developer":{ "name":"Gregory Koberger", "url":"http://gkoberger.net" } } 2. On testmanifest.com, modify the manifest to not include an icon: { "name":"Test App ({subdomain})", "description":"This app has been automatically generated by testmanifest.com", "version":"1.0", "installs_allowed_from":[ "*" ], "developer":{ "name":"Gregory Koberger", "url":"http://gkoberger.net" } } 3. Go to settings --> device info --> check for updates 4. Try restarting every app process on the phone Expected: Assuming bug 822855 didn't happen, I'd expect an update available notification to fire. Upon accepting to download the update, I'd expect each of my apps utilizing data from that app are updated respectively. Actual: The update doesn't apply until each particular app is killed and restarted. For example, this means that if I removed the app icon in the updated manifest as shown above, then doing an update won't show the updated icon until after I restart the phone. This is a poor user experience - we shouldn't be requiring users to restart an entire phone to apply an app update correctly.

Jason, I'm don't understand what you mean by "each of my apps utilizing data from that app". There's no way to track resources between hosted apps, so I don't see anything actionable here.

(In reply to Fabrice Desré [:fabrice] from comment #1) > Jason, I'm don't understand what you mean by "each of my apps utilizing data > from that app". There's no way to track resources between hosted apps, so I > don't see anything actionable here. I don't mean resources. I mean other apps using the app manifest data for a particular app for a particular reason. So for example: The homescreen uses the "name" and "icon" properties to display the app on the homescreen. If that name and icon changes in the manifest, the homescreen will not update the name and icon until after a restart of the phone. So we can't apply an app manifest update then while the app process is active.

(In reply to Jason Smith [:jsmith] from comment #2) > (In reply to Fabrice Desré [:fabrice] from comment #1) > > Jason, I'm don't understand what you mean by "each of my apps utilizing data > > from that app". There's no way to track resources between hosted apps, so I > > don't see anything actionable here. > > I don't mean resources. I mean other apps using the app manifest data for a > particular app for a particular reason. So for example: > > The homescreen uses the "name" and "icon" properties to display the app on > the homescreen. If that name and icon changes in the manifest, the > homescreen will not update the name and icon until after a restart of the > phone. So we can't apply an app manifest update then while the app process > is active. Mean to say - we don't apply the app manifest update to the homescreen while the homescreen is active.

Ha ok, that's a different issue, which should be fixed by the patch in bug 823040, but I'd rather keep this one open since 823040 only deals with the gecko side, and we must also make sure that gaia is reacting properly.

If this is an icon issue, it should be in the Homescreen component.

I think the only issue is about icon (now that we disable entry points) so I think this should not be blocking. That said, is that a dupe of Bug 822855 ?

Triage: BB-, tracking-b2g+. minor if only the icon not updated

(In reply to Julien Wajsberg [:julienw] from comment #6) > I think the only issue is about icon (now that we disable entry points) so I > think this should not be blocking. > > That said, is that a dupe of Bug 822855 ? It's not just about the icon. It's about any app that uses app manifest data. The app icon example is just one example of the problem. Here's another: 1. I install an app with developer name+url 2. I launch app permissions in settings - dev name+url is there 3. I update the app on the server to change the dev name+url 4. I do a check for updates 5. I launch app permissions in settings - notice the old dev name+url is there 6. Kill the settings process and restart it 7. Launch app permissions in settings - notice the new dev name+url is there So basically we aren't updating manifest values until the process is killed that references those manifest values. The particular case about the restart of the phone for the homescreen with a combination of giving the user no notification that the update was received basically leaves the user in the dark that any update has happened and what to do. So I do think this blocks as it stands as you can't do a work-around if you can't know to do it.

We don't expect people will update their app manifest in first launch

QA Wanted for retest to see what happens after the gecko patch lands.

Looks like it isn't fixed with the gecko patch alone. There's gaia work to do on-demand updating while the app process is alive.

There are different issues discussed here. I'd like to handle the homescreen issue first (even if I agree there are other issues eg in settings, let's file a new bug for that; Jason, would you do it please ?). To me, fixing the homescreen issue would help making Bug 860681 a lot less frequent (see bug 860681 comment 28) so I'd like to nominate this one as tef+ instead of Bug 860681, because we have a clearer path to fix here.

(In reply to Julien Wajsberg [:julienw] from comment #14) > There are different issues discussed here. > > I'd like to handle the homescreen issue first (even if I agree there are > other issues eg in settings, let's file a new bug for that; Jason, would you > do it please ?). > > To me, fixing the homescreen issue would help making Bug 860681 a lot less > frequent (see bug 860681 comment 28) so I'd like to nominate this one as > tef+ instead of Bug 860681, because we have a clearer path to fix here. Actually, in that case, let me close this bug, reopen bug 863337 to track the homescreen fix and file a new bug for the settings fix.