Last Comment Bug 842725 - install to device via b2gremote throws "appInfo is null"
: install to device via b2gremote throws "appInfo is null"
[apps watch list]
Product: Firefox OS
Classification: Client Software
Component: General (show other bugs)
: unspecified
: x86 Mac OS X
-- normal (vote)
: B2G C4 (2jan on)
Assigned To: [:fabrice] Fabrice Desré
Depends on:
  Show dependency treegraph
Reported: 2013-02-19 12:52 PST by Myk Melez [:myk] [@mykmelez]
Modified: 2013-03-06 13:58 PST (History)
7 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---

patch (2.41 KB, patch)
2013-02-21 23:03 PST, [:fabrice] Fabrice Desré
ferjmoreno: review+
myk: feedback+
Details | Diff | Splinter Review

Description User image Myk Melez [:myk] [@mykmelez] 2013-02-19 12:52:06 PST
After using b2gremote to push a packaged app to an Unagi device running a nightly build from a b2g18 branch, the app doesn't appear on the homescreen until after a device restart, even though B2G notifies me that the app was installed; and the following error messages show up in logcat:

02-19 12:34:30.650 E/GeckoConsole(  394): [JavaScript Error: "appInfo is null" {file: "jar:file:///system/b2g/omni.ja!/components/AppProtocolHandler.js" line: 68}]
02-19 12:34:30.660 E/GeckoConsole(  394): [JavaScript Error: "NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS: '[JavaScript Error: "appInfo is null" {file: "jar:file:///system/b2g/omni.ja!/components/AppProtocolHandler.js" line: 68}]' when calling method: [nsIProtocolHandler::newChannel]" {file: "app://" line: 158}]
02-19 12:34:30.660 E/GeckoConsole(  394): [JavaScript Error: "NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS: '[JavaScript Error: "appInfo is null" {file: "jar:file:///system/b2g/omni.ja!/components/AppProtocolHandler.js" line: 68}]' when calling method: [nsIProtocolHandler::newChannel]" {file: "app://" line: 158}]

My device is currently running today's nightly build from the 1.0.1 branch (OS version, Build Identifier 20130219070200), but I also noticed this behavior on today's nightly build from the 1.1 branch (which I was running until my phone automatically "updated" to the 1.0.1 build).

The problem is reproducible.  At one point, I stopped being able to reproduce after installing an app to the device a number of times.  But rebooting the device brought the problem back.

It doesn't happen with hosted apps, just packaged ones.  I have reproduced with two different packaged apps (test_apps/template and external-dogfood-apps/packstubtest).
Comment 1 User image [:fabrice] Fabrice Desré 2013-02-21 23:03:00 PST
Created attachment 716958 [details] [diff] [review]

Myk, can you test with this patch? That should fix a race condition where the oninstall handler is called before we had a chance to update the child processes with the new app data.
Comment 2 User image Myk Melez [:myk] [@mykmelez] 2013-02-23 00:22:49 PST
I don't yet have a build environment for building B2G for my device, but since these are JS-only changes, perhaps I can use adb to push them to my device.  I'll look into it!
Comment 3 User image Myk Melez [:myk] [@mykmelez] 2013-02-27 17:03:53 PST
Ok, I put together a build environment, built B2G, and flashed it to my Unagi.  But now b2gremote doesn't trigger the remote debugging confirmation prompt on the device when it calls Debugger.init(6000), even though I enabled "remote debugging in its settings).  So the b2gremote Debugger never becomes ready, and I can't push an app to the device.

If I flash today's nightly build to the device and enable remote debugging, however, then the prompt does appear, and I can push apps to the device (but still have the problem described by this bug report).
Comment 4 User image Myk Melez [:myk] [@mykmelez] 2013-02-27 17:49:36 PST
Comment on attachment 716958 [details] [diff] [review]

One difference between the builds was that my custom build was VARIANT=eng, while the nightly build is VARIANT=user.  So I rebuilt my custom build as VARIANT=user and tried again.

Initially, that didn't seem to make a difference.  But after toggling the remote debugging setting a few times and reconnecting to the device a few times, suddenly the device started accepting install requests (although, strangely, it doesn't prompt me to accept the remote debugging connection first).  And packaged apps show up on the homescreen immediately upon being installed.

So it looks like this patch does fix the problem.
Comment 5 User image [:fabrice] Fabrice Desré 2013-02-28 13:33:45 PST
Comment 6 User image Ryan VanderMeulen [:RyanVM] 2013-02-28 19:40:49 PST
Comment 7 User image Myk Melez [:myk] [@mykmelez] 2013-03-04 10:54:01 PST
Comment on attachment 716958 [details] [diff] [review]

[Approval Request Comment]
Bug caused by (feature/regressing bug #): unknown; behavior seems longstanding.

User impact if declined: The known impact here is on developers, whose attempts to push apps to a device for testing will appear to fail (even though they will actually have succeeded).  It's possible that the bug will also affect users who install apps under certain circumstances, although we have no verified cases of that at the moment.

Testing completed: I tested Fabrice's patch on my Unagi device, after which Fabrice pushed it through inbound to central, where it has been baking for the last four days.

Risk to taking this patch (and alternatives if risky): The patch seems low-risk.  I don't know of any alternatives.

String or UUID changes made by this patch: None.
Comment 8 User image Alex Keybl [:akeybl] 2013-03-04 16:21:24 PST
Given the low risk of regression and impact to development, approving for uplift.
Comment 9 User image Ryan VanderMeulen [:RyanVM] 2013-03-06 13:58:40 PST

Note You need to log in before you can comment on or make changes to this bug.