1044333 - Wrong appID (36) is returned for apps in B2G-emulator

Status: RESOLVED WONTFIX

(Core :: Networking, defect)

Description

[Valentin Gosu [:valentin] (he/him)]

Attachment: test_appid.patch

While writing a test for bug 1029352 I encountered an odd behaviour in the way apps/tests run on the B2G emulator.

It seems that apps calling to NeckoParent::GetValidatedAppInfo with the serialized appID 4, get the appID 36 as that's the only PBrowserParent returned by aContent->ManagedPBrowserParent().
Also, when doing the same with appID 15, it also returns appID 36.

This allows cookies and other app-private data to be shared between apps.
The patch in bug 1029352 fixes that, but it also makes dom/apps/tests/test_app_update.html fail.

I need to note that this behaviour isn't present for desktop builds, where GetValidatedAppInfo always seems to return the correct appID.

What we need to determine if there is actually a problem in the way the appID is checked on the B2G emulator (and on real devices), or if this is only an issues in tests that use remote iframes.

Comment 1

[[:fabrice] Fabrice Desré]

Valentin, while you have the emulator running, can you pull the /data/local/webapps/webapps.json file with adb?

Comment 2

[Valentin Gosu [:valentin] (he/him)]

http://pastebin.mozilla.org/5625184

I guess you're interested in what app 36 is? It seems to be http://mochi.test:8888/manifest.webapp
So creating an iframe with a src that goes to mochi.test, would give it appID 36? But only on the emulator (as probably on devices) ?

Comment 3

[Valentin Gosu [:valentin] (he/him)]

Also, if it's the case that remote iframes don't work on B2G, is there a way to test cookie isolation on this platform?

Also, I'm writing a patch to disable test_app_update.html since it runs into the aforementioned bug/feature.

Comment 4

[[:fabrice] Fabrice Desré]

Remote iframes work on b2g, this is how we run apps. I'm more and more convinced that the test is not setup properly. 

And I really would like to not disable test_app_update.html . What's wrong with it?

Comment 5

[Valentin Gosu [:valentin] (he/him)]

(In reply to Fabrice Desré [:fabrice] from comment #4)
> Remote iframes work on b2g, this is how we run apps. I'm more and more
> convinced that the test is not setup properly. 
> 
> And I really would like to not disable test_app_update.html . What's wrong
> with it?

The problem is that those iframes call NeckoParent::GetValidatedAppInfo with serialized appID 1001 or 1002, and the method returns 36 (the appID of the mochitest app). 1001 and 1002 aren't in the list PBrowserParents returned by aContent->ManagedPBrowserParent(), so presumably loading content that belongs to those apps should be denied. That's what bug 1029352. 

test_app_update.html along with the test I attached to this bug, have this behaviour in the emulator. If we apply the fix from bug 1029352, we will see both of them fail (the child process is killed, it the IDs don't match). This leads me to think that there may be something wrong we do in the tests.

Also, I fnd it very odd that by running the attached test on linux-desktop, and on B2G-emulator, the iframes' appIDs get different values. On linux-desktop they always get the appID of the manifest we set, but on B2G-emulator they get the appID of the iframe's src (which is mochitest)

While I may find another way to test that the cookie jars are separate, we need a way to address the failure or test_app_update (either by changing it, disabling it on B2G, or setting the network.disable.ipc.security pref). And we should find out why there's a difference of behaviour between emulator/desktop builds.

Comment 6

[Valentin Gosu [:valentin] (he/him)]

I was unable to run the attached mochitest on an hardware device using the instructions on the page: https://developer.mozilla.org/en-US/Firefox_OS/Platform/Automated_testing/Mochitests#Running_mochitests_on_device_and_emulator_builds (I'm using a keon)

Would it be possible to get someone from QA with some experience in this area to run the test, or to help me do it? (it's difficult to guess the correct params for runtestsb2g.py)

Thanks!

Comment 7

[Jason Smith [:jsmith]]

I think this is something better suited to ask Fabrice about, rather than QA.

QA Wanted requests though typically target manual testing needs, not automation needs. On that regard, I'm going to remove the qawanted flag.

Comment 8

[[:fabrice] Fabrice Desré]

Yep, me and someone from the ateam like ahal, because we need to figure out why the test setup doesn't match what we expect.

Comment 9

[Kan-Ru Chen [:kanru] (UTC+9)]

I/Gecko   (  333): XXXXXXXXXXXXXXX appId 37 serialized.mAppId 1001

  "{4929b723-1e70-43cd-97c3-ef578c5d717a}": {
    "origin": "http://mochi.test:8888",
    "installOrigin": "http://mochi.test:8888",
    "receipt": null,
    "installTime": 1408699304718,
    "updateTime": 1408699304718,
    "manifestURL": "http://mochi.test:8888/manifest.webapp",
    "removable": true,
    "localId": 37,
    "etag": null,
    "packageEtag": null,
    "appStatus": 1,
    "id": "{4929b723-1e70-43cd-97c3-ef578c5d717a}",
    "basePath": "/data/local/webapps",
    "installerAppId": 0,
    "installerIsBrowser": false,
    "installState": "installed",
    "storeId": "",
    "storeVersion": 0,
    "role": "",
    "widgetPages": [],
    "downloading": false,
    "readyToApplyDownload": false,
    "name": "Mochitest",
    "csp": "",
    "kind": "hosted"
  },
  "{6c06a3c7-89a4-45f6-a1f2-cbaaaedc72b1}": {
    "name": "Really Rapid Release (hosted)",
    "csp": "",
    "installOrigin": "http://mochi.test:8888",
    "origin": "http://test",
    "receipts": [],
    "installTime": 1408699469685,
    "manifestURL": "http://test/tests/dom/apps/tests/file_app.sjs?apptype=hosted&getmanifest=true",
    "appStatus": 1,
    "removable": true,
    "id": "{6c06a3c7-89a4-45f6-a1f2-cbaaaedc72b1}",
    "localId": 1001,
    "basePath": "/data/local/webapps",
    "progress": 0,
    "installState": "installed",
    "downloadAvailable": false,
    "downloading": false,
    "readyToApplyDownload": false,
    "downloadSize": 0,
    "lastUpdateCheck": 1408699469685,
    "etag": "apptype-hosted-getmanifest-true-2",
    "manifestHash": "53c7f5fd4ecfd82e040c3430aa7e6774",
    "installerAppId": 37,
    "installerIsBrowser": false,
    "storeId": "",
    "storeVersion": 0,
    "role": "",
    "widgetPages": [],
    "kind": "hosted",
    "manifest": {
      "name": "Really Rapid Release (hosted)",
      "description": "Updated even faster than Firefox, just to annoy slashdotters.",
      "launch_path": "/tests/dom/apps/tests/file_app.sjs?apptype=hosted",
      "icons": {
        "128": "default_icon"
      }
    }

Comment 10

[Kan-Ru Chen [:kanru] (UTC+9)]

We run the Mochitest app OOP and load the test html so this is a case that we don't really support currently: mozapp in a remote mozapp. It's like running the system OOP and load other apps in it. In this case they will share one TabParent thus the AppId mismatch.