(...)Which GTK+ version do you have installed? That's a bug in GTK+ (see bug #576852), fixed in GTK+ >= 2.22.0(...)

2.20.1-2. Unfortunately using Debian stable means I'm a bit back in time. Thanks for information, I will check if it will disappear when I finally will do an upgrade.

(...)Which python version do you have installed?(...)
Python 2.6 is set as a default.

About lauch.... py script.

I'm not a pro with a python. Done few lines only. But from other experiences with other programming languages I do know, that starting a new thread is not enough to get in a background - the process will not terminate until all non-daemon threads are terminated. And if threads are daemon, they will be killed when all non-daemon threads terminates. In this case inkscape fires new process (python interpreter) and awaits for it's completion. So python interpreter must terminate while browser must go to another, independent process.

Also python manual says: "(...)global interpreter lock(...) The mechanism used by the CPython interpreter to assure that only one thread executes Python bytecode at a time.(...)" what suggests that doing threads in python when not doing I/O or awaiting for an external process is ridiculous. Again, I'm not a pro with python.

I did modified script to remove threading and it works the same way: iceweasel behaves as typed in terminal - shows and returns. Epiphany exposes incorrect behavior.

The webbrowser.py module used in script is using subprocess.py to spawn subprocess with shell==false. Manual says, that it is reasonable because of safety but will result in os.execvp(). As expected on Unix clone, manual says that os.execvp do not return. However subprocess _execute_child do os.fork() so it is correct and cannot be a source of problem.

But some pieces of webbrowser.py contains dangerous "return not p.wait()". It seems it assumes that some style of calling, named "remote", will fork by itself and others will not. I do not understand WHY such a distinction. Closer look shows, that following classes of browsers defined in this webbrowser.py module will await till child process completes:

GenericBrowser
UnixBrowser (depening on arguments)

Selection of class is made by get() and available set is prepared by register_X_browsers() during module initialization. This method applies distinct assumptions about distinct commands. I do not understand why to wait for some browsers to complete? Does it matter? We are only willing to fire it up and forget, right? I think it is for python code running in terminal. That's the problem with a generic code - it does too much and is too uncertain.

For GNOME default browser is available through "gnome-open" system script. When checked in command line this script is always forking and returning. The webbrowser.py module recognizes it as a BackgroundBrowser what should be ok, as BackgroundBrowser do not wait for subprocess to complete. But it should not matter anyway, since "gnome-open" forks for both iceweasel and epiphany.

Unfortunately I did confirm, modifying launchwebbrowser to:
(...)
from webbrowser import BackgroundBrowser
bb=BackgroundBrowser("gnome-open")
bb.open(url=opt.url)
(...)
that it is a location of a problem - inkscape awaits for browser to be closed.

Changed to:
(...)
cmdline =["gnome-open",opt.url]
subprocess.Popen(cmdline)
(...)
and this one is also awaiting for browser to be closed.

Changed then to:
(...)
if os.fork() == 0:
   os.execvp("gnome-open",["gnome-open",opt.url])
(...)
and to my great surprise it ALSO do wait.

The stand alone simple script run from outside of inkscape:

#!/usr/bin/env python
import os
if os.fork()==0:
	os.execvp("gnome-open",["gnome-open","http://www.wp.pl"])
else:	
	print "waiting"

forks as expected.

Ok, let's try what can prevent a process (inkscape) observing a child process from detecting it's completion when a sub-child process is still running? Maybe pipes still opened? In linux child process are having their stdin/stdout/stderr exactly the same as a parent process. Try to run this script:

#!/usr/bin/env python
import os
import time
if os.fork()==0:
  	print "forked exec"
  	time.sleep(10)
  	print "forked complete"
else:	
	print "non-forked"

It nicely forks into a background, but text "forked completed" is popping to terminal after 10 seconds.

But EXACTLY THE SAME CODE placed inside launch_webbrowser.py makes inkscape to wait for 10 seconds with a dialog opened and then reporting expected error capture: "non-forked".

Ok, so maybe pipes are causing troubles. Code:

if os.fork()==0:
        os.close(0)
        os.close(1)
        os.close(2)
        os.execvp("gnome-open",["gnome-open","http://www.wp.pl"])
else:	
	print "non-forked"

is crashing in inkscape. Browser obviously needs some kind of stdin/stdout/stderr. But code:


if os.fork()==0:
        devnull = os.open("/dev/null",os.O_RDWR)
        os.dup2(devnull,0)
        os.dup2(devnull,1)
        os.dup2(devnull,2)
        os.execvp("gnome-open",["gnome-open","http://www.wp.pl"])

works exactly as expected.

Why then standard code do not work? The subprocess.py DO redirect stdin/stdout/stderr ONLY if it is TOLD TO. The BackgroundBrowser do not say that. It says to close all files EXCEPT those three and do not touch them. In effect inkscape is waiting (I suppose, since it is grabbing and showing stderr)  for those pipes to be closed as a sign of interpreter completion but they are passed to child process (browser) which keeps them opened and alive.

Solution to this problem:

1.The launch_webbrowser.py should be (but do not have to be) stripped from threading code to a plain call:

#!/usr/bin/env python
import webbrowser, threading
from optparse import OptionParser

parser = OptionParser()                                                                                                   	
parser.add_option("-u", "--url", action="store", type="string",
                  default="http://www.inkscape.org/",
                  dest="url", help="The URL to open in web browser")                                       		
(opt, args)=parser.parse_args()
webbrowser.open(opt.url)

2.The bug report for Phyton 2.6 & 2.7 webbrowser.py module should be filled:

The BackgroundBrowser class should have line:

        p = subprocess.Popen(cmdline, close_fds=True, preexec_fn=setsid)

changed to:
        
        devnull = os.open(os.devnull,os.O_RDWR)
    	p = subprocess.Popen(cmdline, close_fds=True, preexec_fn=setsid,
    			    stdin=devnull,stdout=devnull,stderr=devnull)

After those changes everything works fine. Note: I wasn't able to test it on windows so I don't know whether os.devnull exists there and how does it work. Developers should decide if it would not be better to create GnomeBrowser class instead.

3.Python 2.7 - the same faulty behaviour.

With regards,
  Tomasz Sztejka