User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b3pre) Gecko/20100802 Minefield/4.0b3pre Build Identifier: A SOCKS proxy server will be needed in mochitests in order to test bug 354493. This is because knowledge of the server's IP address is needed. Currently, all mochitest requests go through an HTTP proxy which means the destination server's IP address isn't known. Bug 584155 adds a js SOCKS proxy server that was written primarily for this purpose. That bug, however, doesn't enable the proxy when mochitests run; it only adds the proxy code and the proxy's own xpcshell tests. The reason for opening a separate bug is that I felt it would make the mochitest changes easier to review. Reproducible: Always
Starts/stops socksd.js in mochotests when httpd.js is started/stopped. Adds two hosts that are proxied via SOCKS 4 in mochitests: 192.0.2.0 (an rfc5735 reserved public address for documentation and example code) and 172.16.0.0 (an rfc1918 private address).
You should make sure that this works properly with the mobile testing setup, where the browser+tests are running on a mobile device, and httpd.js is running on a separate machine.
Change from previous version of patch: proxy requests to the http server via "localhost" rather than |gServerAddress|, which is the remote address specified for httpd.js and socksd.js to listen on. I didn't have any problems proxying to |gServerAddress|, but |gServerAddress| actually isn't being listened on by either httpd.js or socksd.js. Instead, the value of |gServerAddress| is only used to decide whether or not to listen only on the loopback. Thus, using "localhost" will ensure that socksd.js will still be able to proxy through to httpd.js even if there is some situation where |gServerAddress| isn't routable from within the machine that server.js is running on.
Attachment #463693 - Attachment is obsolete: true
(In reply to comment #2) > You should make sure that this works properly with the mobile testing setup, > where the browser+tests are running on a mobile device, and httpd.js is running > on a separate machine. Good call. I've now tested this using the steps I've described here: https://wiki.mozilla.org/Mobile/Fennec_Unittests/Remote_Testing/Examples. The tests ran fine and the SOCKS proxy worked properly. (I did have a small number of test failures, but I get these same failures without the SOCKS proxy. Even aside from remote testing of Fennec, I have yet to run the full suite of mochitests on a clean Firefox build without a few test failures.)
Fixes the --socks-port option being read but ignored by runtestsremote.py. This resulted in not being able to override the default SOCKS port the tests use (11080). I had forgotten to test this option when running the remote tests a little while ago.
Attachment #464193 - Attachment is obsolete: true
Assignee: nobody → bugs
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: unspecified → Trunk
Fixed so that socksd will be available in server.js for packaged builds (that is, fixed to work on tryserver). Like the fix just applied to the patch in bug 584155 comment 12, this uses a combination of Ted's TEST_HARNESS_COMPONENTS suggestion in that bug along with the -r argument to xpcshell to make the socksd interface available within server.js.
Attachment #464218 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.