How to run a headless second Firefox instance?
We talked a while ago about using a browser extension to make HTTPS requests on behalf of a pluggable transport, so that the TLS doesn't stand out as unusual (#11183). I have that working pretty well and you can try it out. Using these bundles, you can run the meek pluggable transport and the TLS layer looks just like Firefox, because it is Firefox. https://trac.torproject.org/projects/tor/ticket/11183#comment:16 https://people.torproject.org/~dcf/pt-bundle/3.5.2.1-meek-5/ How it works: tor starts a wrapper program called meek-client-torbrowser, which starts a second copy of firefox using a separate profile.meek-http-helper. The second profile has some different prefs (https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/blob/861e270c6...) and it runs the HTTP helper extension. The extension prevents a second browser window from opening. Once the second firefox starts up, meek-client-torbrowser runs meek-client and sets it up to communicate using the browser helper. What I need some advice on: In order to prevent a browser window from opening in the second instance of firefox, the helper extension opens a modal dialog and never returns. If the dialog is ever closed, the whole browser is shut down. It looks like this (https://gitweb.torproject.org/pluggable-transports/meek.git/blob/d2de8adc064...): try { // Block forever. var prompts = Components.classes["@mozilla.org/embedcomp/prompt-service;1"] .getService(Components.interfaces.nsIPromptService); prompts.confirm(null, "Query", "Get down, get funky?"); } finally { var app = Components.classes["@mozilla.org/toolkit/app-startup;1"] .getService(Components.interfaces.nsIAppStartup); app.quit(app.eForceQuit); } It gets the job done, but it sucks because the first thing you see is the dialog and you have to know not to close it. Is there a way to accomplish the same thing (keep the browser running, but don't show a browser window) without raising a conspicuous dialog? David Fifield
On 09/04/14 07:29, David Fifield wrote:
It gets the job done, but it sucks because the first thing you see is the dialog and you have to know not to close it. Is there a way to accomplish the same thing (keep the browser running, but don't show a browser window) without raising a conspicuous dialog?
You could play further with this: $ nc -l -p 9999 & $ iceweasel -no-remote -p testing -chrome http://localhost:9999 If there's no server listening, firefox opens up a "can't connect" page. Otherwise, it continues running, with no UI, past the 3-minute TCP timeout mark, even if you kill nc in the meantime. However, I am not sure if the process is actually responsive, or simply hanging waiting for an HTTP response - so you'll need to test that. Also, there's no guarantee that firefox will keep this behaviour. Failing everything, maybe you could return a real XUL response that displays "don't close me"? X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git
On 09/04/14 16:31, Ximin Luo wrote:
On 09/04/14 07:29, David Fifield wrote:
It gets the job done, but it sucks because the first thing you see is the dialog and you have to know not to close it. Is there a way to accomplish the same thing (keep the browser running, but don't show a browser window) without raising a conspicuous dialog?
You could play further with this:
$ nc -l -p 9999 & $ iceweasel -no-remote -p testing -chrome http://localhost:9999
If there's no server listening, firefox opens up a "can't connect" page. Otherwise, it continues running, with no UI, past the 3-minute TCP timeout mark, even if you kill nc in the meantime.
However, I am not sure if the process is actually responsive, or simply hanging waiting for an HTTP response - so you'll need to test that. Also, there's no guarantee that firefox will keep this behaviour.
Firefox hangs around if I exit nc with ctrl-D. I assume that this means it closed the TCP connection, so the fact that Firefox is still running afterwards is a good sign. -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git
On Wed, Apr 09, 2014 at 04:31:57PM +0100, Ximin Luo wrote:
On 09/04/14 07:29, David Fifield wrote:
It gets the job done, but it sucks because the first thing you see is the dialog and you have to know not to close it. Is there a way to accomplish the same thing (keep the browser running, but don't show a browser window) without raising a conspicuous dialog?
You could play further with this:
$ nc -l -p 9999 & $ iceweasel -no-remote -p testing -chrome http://localhost:9999
That's an interesting idea. I didn't know about the -chrome option. https://developer.mozilla.org/en-US/docs/Mozilla/Command_Line_Options#Chrome Maybe in order to avoid relying on a local port, we could use an internal chrome:// URL that just doesn't define any UI elements, or something like that. I don't know too much about how the XUL overlays work, but it seems like it should be possible. In fact, if I use the "-chrome chrome://inspector/content" from the page linked above, it seems to do pretty much what we want. Browser/firefox" -no-remote -profile Data/Browser/profile.meek-http-helper -chrome chrome://inspector/content It doesn't open any window. I don't know what "chrome://inspector/content" does, but we can always define our own empty UI file. A downside, though, is that even though no window gets opened, you still get an icon in the OS X dock, and if you click on it and then "File→New Window", a naked proxy-bypassing web browser appears. It happens with the local netcat listener, too. The modal dialog approach also creates a second dock icon, but it doesn't have a menu. David Fifield
On Wed, Apr 9, 2014 at 12:17 PM, David Fifield <david@bamsoftware.com> wrote:
$ iceweasel -no-remote -p testing -chrome http://localhost:9999
That's an interesting idea. I didn't know about the -chrome option. https://developer.mozilla.org/en-US/docs/Mozilla/Command_Line_Options#Chrome
I was looking into driving Mozilla from the command line and assembling some notes. Maybe these links and small example apps are of use. https://developer.mozilla.org/en-US/docs/Mozilla/Command_Line_Options https://developer.mozilla.org/en-US/docs/Chrome/Command_Line https://developer.mozilla.org/en-US/docs/Mozilla/Projects/XULRunner/CommandL... https://github.com/omarabid/CmdShots https://addons.mozilla.org/en-US/firefox/addon/grab-them-all/ http://rafal.zelazko.info/2009/08/21/screenshot-server/ http://rafal.zelazko.info/2008/06/23/easy-screenshot-of-many-sites/ If you don't want to *see* mozilla, maybe you can bury it in a zero size or null Xnest DISPLAY / emulation, or patch out FF's display guts before that.
On Wed, Apr 9, 2014 at 12:17 PM, David Fifield <david@bamsoftware.com> wrote:
On Wed, Apr 09, 2014 at 04:31:57PM +0100, Ximin Luo wrote:
On 09/04/14 07:29, David Fifield wrote:
It gets the job done, but it sucks because the first thing you see is the dialog and you have to know not to close it. Is there a way to accomplish the same thing (keep the browser running, but don't show a browser window) without raising a conspicuous dialog?
You could play further with this:
$ nc -l -p 9999 & $ iceweasel -no-remote -p testing -chrome http://localhost:9999
That's an interesting idea. I didn't know about the -chrome option. https://developer.mozilla.org/en-US/docs/Mozilla/Command_Line_Options#Chrome
Maybe in order to avoid relying on a local port, we could use an internal chrome:// URL that just doesn't define any UI elements, or something like that. I don't know too much about how the XUL overlays work, but it seems like it should be possible.
I *think* this .xul file suffices: <?xml version="1.0"?> <window xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"></window> There is a specific warning at https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/window to the effect that without more, "the window will be invisible". I don't know how to get rid of the OSX dock icon, though.
Is there a way to accomplish the same thing (keep the browser running, but don't show a browser window) without raising a conspicuous dialog?
Selenium seems to use xvfb as a virtual display. There's also a new nsIAppShellService::createWindowslessBrowser(), but I don't think that's ready.
On Tue, Apr 08, 2014 at 11:29:25PM -0700, David Fifield wrote:
We talked a while ago about using a browser extension to make HTTPS requests on behalf of a pluggable transport, so that the TLS doesn't stand out as unusual (#11183). I have that working pretty well and you can try it out. Using these bundles, you can run the meek pluggable transport and the TLS layer looks just like Firefox, because it is Firefox.
https://trac.torproject.org/projects/tor/ticket/11183#comment:16 https://people.torproject.org/~dcf/pt-bundle/3.5.2.1-meek-5/
What I need some advice on: In order to prevent a browser window from opening in the second instance of firefox, the helper extension opens a modal dialog and never returns. If the dialog is ever closed, the whole browser is shut down. It looks like this (https://gitweb.torproject.org/pluggable-transports/meek.git/blob/d2de8adc064...): try { // Block forever. var prompts = Components.classes["@mozilla.org/embedcomp/prompt-service;1"] .getService(Components.interfaces.nsIPromptService); prompts.confirm(null, "Query", "Get down, get funky?"); } finally { var app = Components.classes["@mozilla.org/toolkit/app-startup;1"] .getService(Components.interfaces.nsIAppStartup); app.quit(app.eForceQuit); } It gets the job done, but it sucks because the first thing you see is the dialog and you have to know not to close it. Is there a way to accomplish the same thing (keep the browser running, but don't show a browser window) without raising a conspicuous dialog?
I found this trick that seems to work: // Block forever. // https://developer.mozilla.org/en-US/Add-ons/Code_snippets/Threads#Waiting_fo... var thread = Components.classes["@mozilla.org/thread-manager;1"].getService().currentThread; while (true) thread.processNextEvent(true); It prevents any window from being opened for the second browser instance. On Windows you don't get a second icon in the taskbar. On OS X you do get a second icon (which is #11429), but I didn't see a way to get the icon to open a window. David Fifield
participants (5)
-
Arlo Breault -
David Fifield -
grarpamp -
Ximin Luo -
Zack Weinberg