Allow Marionette to access XPCOM interfaces without host and device being on same network

RESOLVED FIXED in Firefox 22

Status

RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: mschwart, Assigned: jgriffin)

Tracking

unspecified
mozilla22
x86_64
Gonk (Firefox OS)
Points:
---

Firefox Tracking Flags

(blocking-b2g:tef+, firefox20 wontfix, firefox21 wontfix, firefox22 fixed, b2g18+ fixed, b2g18-v1.0.0 wontfix, b2g18-v1.0.1 fixed)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

6 years ago
Currently, when trying to run tests such as http://mxr.mozilla.org/mozilla-b2g18/source/dom/system/gonk/tests/marionette/test_get_voicemailInfo.js to interact with XPCOM interfaces, the framework tries to contact the IP address of the host therefore requiring they both be on the same network.

Can we remove this limitation?
FTR, this is with regards to the phone and runner machine needing to be on the same network so the phone can have access to the runner's webserver, despite being connected via adb.

There might be a way to forward the port or tunnel in so the phone can have access to the webserver...
I understand the request now.  Ideally adb would support reverse-forwarding, but it don't.

Doing so wouldn't be hard.  We would need
 - proxy server on the host side to adb forward a port X to device
 - proxy server on the device to listen to connection on port X
 - host connect to device over X for "control" channel
 - device proxy bind and listen to second port Y
 - device proxy muliplex on-device connections on Y over socket on X
 - host proxy demux and route to port Y on host

Of course, adb already has all the machinery for this, just in the opposite direction.  It might be easier to teach adb to device-forward or reverse-forward than to jury-rig a separate system.
Or hack adb forward to set up two-way forwarding.
(Reporter)

Comment 4

6 years ago
So is the access to the host needed to report the result of the tests or some other reason?
(In reply to Michael Schwartz [:m4] from comment #4)
> So is the access to the host needed to report the result of the tests or
> some other reason?

the reason seems to be two-fold. 

1) all these tests are run in a "blank" html page that is served by the webserver. Before running the test, we load this blank page, and then run your test in it.
2) if any of those tests want to load a test page from the test runner machine, it will have to be loaded by the webserver

I think we can get rid of 1) by loading "about:blank" instead of serving own "blank" html page. This will help you run tests that don't load their own pages, like the one you linked in the description.

But if you plan on running tests described in 2), ie: tests that load a file from the test runner machine, then fixing 1) won't help you, and we'll need to get this webserver available to your phone.
Is the server just serving static content?  If so, can we just upload the content to device and run a local http server there?
(In reply to Chris Jones [:cjones] [:warhammer] from comment #6)
> Is the server just serving static content?  If so, can we just upload the
> content to device and run a local http server there?

The server currently only serves static content, so yes can have a server run on the phone and talk to it that way. You can avoid using the marionette webserver at all this way, and you can run the tests by passing a --baseurl=<your webserver url> argument to runtests.py.

I'm not sure what files you're required to serve, other than the "blank" page. If the blank page is all you need, then I think we can just switch it out to use "about:blank", and avoid running a server on the device at all until it is needed by a test that actually wants to load static content, but I'd like wait on Jgriffin's input for this before acting, since he's more familiar with these kinds of tests.
Flags: needinfo?(jgriffin)
(Reporter)

Comment 8

6 years ago
What do you mean by "these kinds of tests"?  If I only want to call XPCOM interfaces then it seems all I want is an xpcshell and webpages shouldn't really need to play into it, right?
(In reply to Michael Schwartz [:m4] from comment #8)
> What do you mean by "these kinds of tests"?  If I only want to call XPCOM
> interfaces then it seems all I want is an xpcshell and webpages shouldn't
> really need to play into it, right?

By "these kinds of tests" I mean the js tests that are run via marionette. If your testing needs are satisfied by xpcshell tests, then perhaps you can try out https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Platform/Testing/XPCShell?
(Reporter)

Comment 10

6 years ago
Thanks Malini, xpcshell tests might be a good way to get us going while we figure out how to get the js tests running.  JS tests appear to be a better fit because poking at both XPCOM interfaces and the navigator or other web objects would be ideal.
(Assignee)

Comment 11

6 years ago
Created attachment 720803 [details] [diff] [review]
Use about:blank as the default WebAPI test page in Marionette

This patch causes us to use about:blank as the default WebAPI test page, which would remove the reliance on access to the host's webserver.  I'll run it through try to see if it causes any problems.
Flags: needinfo?(jgriffin)
(Assignee)

Updated

6 years ago
Assignee: nobody → jgriffin
(Assignee)

Comment 13

6 years ago
(In reply to Jonathan Griffin (:jgriffin) from comment #12)
> https://tbpl.mozilla.org/?tree=Try&rev=5b3e55bc6659

This try job was bad; see bug 847683.  I'll try again after that's fixed.
(Assignee)

Comment 14

6 years ago
Created attachment 720989 [details] [diff] [review]
Use about:blank as the default WebAPI test page in Marionette

Looks like about:blank doesn't work, but in some quick tests, using a data url did.
(Assignee)

Updated

6 years ago
Attachment #720803 - Attachment is obsolete: true
(Assignee)

Comment 15

6 years ago
Created attachment 721368 [details] [diff] [review]
Use about:blank as the default WebAPI test page in Marionette

*this* patch passed on try, except for test_simpletest_pass.js, which was asserting on window.location.href.  I've removed that check, since it doesn't really belong here, and because we don't get anything meaningful from window.location.href when we're using data url's.
Attachment #721368 - Flags: review?(mdas)
(Assignee)

Updated

6 years ago
Attachment #720989 - Attachment is obsolete: true
Comment on attachment 721368 [details] [diff] [review]
Use about:blank as the default WebAPI test page in Marionette

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

oh cool, I didn't know you can navigate like that.
Attachment #721368 - Flags: review?(mdas) → review+
(Reporter)

Comment 18

6 years ago
Thanks Jon, this change works!  Note that everything seems great on the host but I'm still seeing the following error on device via adb:

E/GeckoConsole(  122): [JavaScript Error: "[Exception... "Component returned failure code: 0x80470002 (NS_BASE_STREAM_CLOSED) [nsIOutputStream.write]"  nsresult: "0x80470002 (NS_BASE_STREAM_CLOSED)"  location: "JS frame :: chrome://global/content/devtools/dbg-transport.js :: DT_onOutputStreamReady :: line 94"  data: no]" {file: "chrome://global/content/devtools/dbg-transport.js" line: 94}]

It doesn't appear to be getting in the way but looks like it should probably be fixed - perhaps in a different bug.
(Assignee)

Comment 19

6 years ago
(In reply to Michael Schwartz [:m4] from comment #18)
> Thanks Jon, this change works!  Note that everything seems great on the host
> but I'm still seeing the following error on device via adb:
> 
> E/GeckoConsole(  122): [JavaScript Error: "[Exception... "Component returned
> failure code: 0x80470002 (NS_BASE_STREAM_CLOSED) [nsIOutputStream.write]" 
> nsresult: "0x80470002 (NS_BASE_STREAM_CLOSED)"  location: "JS frame ::
> chrome://global/content/devtools/dbg-transport.js :: DT_onOutputStreamReady
> :: line 94"  data: no]" {file:
> "chrome://global/content/devtools/dbg-transport.js" line: 94}]
> 
> It doesn't appear to be getting in the way but looks like it should probably
> be fixed - perhaps in a different bug.

This is a known and harmless exception.
(Reporter)

Comment 20

6 years ago
Should we be catching it then?
(Assignee)

Comment 21

6 years ago
Yes, we should.  Filed previously as bug 842972.
(Assignee)

Updated

6 years ago
Component: General → Marionette
Product: Boot2Gecko → Testing
Target Milestone: --- → mozilla22
(Assignee)

Comment 23

6 years ago
We'd like to uplift this to b2g18 branches.
tracking-b2g18: --- → ?
https://hg.mozilla.org/mozilla-central/rev/23a1dd29471f
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Is b2g18 enough or are you requesting v1.0.1 as well?  tracking-b2g18:+ will get patches to the former but not the latter.
tracking-b2g18: ? → +
(Assignee)

Comment 26

6 years ago
I believe :m4 would like it in 1.0.1 as well, so marking as shira?
blocking-b2g: --- → shira?
I think we're using tef+ for 1.0.1 stuff so shira? -> tef?.
blocking-b2g: shira? → tef?
(Reporter)

Comment 28

6 years ago
Yes, both please.  Thx!
blocking-b2g: tef? → tef+
https://hg.mozilla.org/releases/mozilla-b2g18/rev/aec2f0738fab
https://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/a0eb57759a92
status-b2g18: --- → fixed
status-b2g18-v1.0.0: --- → wontfix
status-b2g18-v1.0.1: --- → fixed
status-firefox20: --- → wontfix
status-firefox21: --- → wontfix
status-firefox22: --- → fixed
(Reporter)

Comment 30

6 years ago
Playing with this feature a little more, it seems like the loaded data page cannot be easily cleared unless I'm missing something (very possible).
(Assignee)

Comment 31

6 years ago
(In reply to Michael Schwartz [:m4] from comment #30)
> Playing with this feature a little more, it seems like the loaded data page
> cannot be easily cleared unless I'm missing something (very possible).

That's right.  In order to avoid thorny permissions issues, we load the test page in place of the gaia homescreen, so you cannot remove it by pressing the Home button, for example.  Instead, you need to reboot the phone.
(Reporter)

Comment 32

6 years ago
Thanks jgriffin.

A run of test_simpletest_pass.js is failing for me:
 TEST-UNEXPECTED-FAIL | test_simpletest_pass.js | JavascriptException: Marionette.finish() not called
I'm running:
 python runtests.py --address localhost:2828 tests/unit/test_simpletest_pass.js
From:
 https://github.com/mozilla/marionette_client
Any ideas what we're doing differently?
(Assignee)

Comment 33

6 years ago
:m4, the github repo is very out of date, sorry.  It's scheduled for deletion.  Please try running the tests instead from the gecko checkout in B2G, at the path gecko/testing/marionette/client/marionette.
You need to log in before you can comment on or make changes to this bug.