Start webbrowser in a thread. Prevents lockup with Chrome. #936

Closed
wants to merge 1 commit into
from

2 participants

@fperez
IPython member

If a user has Chrome set as their default browser (system-wide or via
the BROWSER environment variable), opening the notebook hangs
because the chrome call doesn't return immediately. This solves the
issue by opening the browser in a thread.

Note that there remains an issue where killing the notebook will kill
Chrome if the Chrome session was started by us. I haven't found a way
to work around that despite attempts by making the webbrowser.open()
call in a subprocess.

@fperez fperez Start webbrowser in a thread. Prevents lockup with Chrome.
If a user has Chrome set as their default browser (system-wide or via
the `BROWSER` environment variable), opening the notebook hangs
because the chrome call doesn't return immediately.  This solves the
issue by opening the browser in a thread.

Note that there remains an issue where killing the notebook will kill
Chrome if the Chrome session was started by us.  I haven't found a way
to work around that despite attempts by making the webbrowser.open()
call in a subprocess.
9f23711
@minrk
IPython member

Sensible, though note that it is actually only affects setting the BROWSER env to a blocking call. It does not affect Chrome, or any other browser, if it is the default system-wide as you suggest (assuming support for gnome-open or similar).

I actually was able to get the subprocess to survive notebook termination (at least with sigint/ctrl-C), with:

            def b():
                signal.signal(signal.SIGINT, signal.SIG_IGN)
                webbrowser.open("%s://%s:%i" % (proto, ip, self.port),
                                         new=2)
            p = multiprocessing.Process(target=b)
            p.daemon = True
            p.start()
@fperez
IPython member

Right on the system-wide setting, which is good.

I tried several approaches with subprocess and threading, but not the one with mp (I basically wrote the identical code you have with threading instead of mp). I'd say we go with that approach instead, as it will ultimately provide a better interface.

How does that sound? I can update the PR in a bit.
I'll

@fperez
IPython member

Mmh: I just implemented the code above, and I still get the Chrome session to die on my system (ubuntu 11.10, Chrome stable)... No luck, it dies just like with the threading or subprocess approach. Any chance when you were testing you had a Chrome process lying around beforehand? In that case it doesn't get killed...

@minrk
IPython member

I did check, but I may not have been thorough. I honestly don't think it's a big deal - this is only going to affect users who don't actually use Chrome, but are running the notebook with Chrome (e.g. testers, like you). The more important thing is it starts up functional, which is resolved by the threading.

Since such users are few, and presumably fairly advanced, we can just note that using BROWSER='google-chrome&' (background) instead of BROWSER='google-chrome' should avoid the problem, though I'm not 100% sure it will be different from the multiprocessing behavior.

@fperez
IPython member
@fperez
IPython member

Rebased to avoid recursive merge, pushed.

@fperez fperez closed this Oct 28, 2011
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment