This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author phd
Recipients
Date 2005-10-31.13:11:51
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
Logged In: YES 
user_id=4799

Yes, I want.

Current practice of running a browser in the background by
default is deadly broken. The old code of webbrowser.py is
full of dirty hacks. Look at Netscape._remote(). It tries to
start a browser to send a remote command; if that fails it
tries to start the browser in the background, waits an
arbitrary number of seconds (why this? why not less? why not
more?) and without testing if the browser in the background
was started it retries sending the remote command. You can
never know if the browser was started and if the command was
sent becuase .open() does not return a result code.

At the global level the bug is that webbrowser.py doesn't
tri all browsers in the tryorder - it only concentrates on
the first it found in PATH. What if the brwoser cannot be
started (damaged disk image; wrong DISAPLY; wrong
xhost/xauth permissions)?

My patched webbrowser.py is much safer. It runs all browsers
in the tryorder until it finds one that can be started. One
doesn't need to wait a random number of seconds, too little
for slow systems, too many for fast. .open() returns a
success/fail status (on systems where it is possible to
obtain one).

The framework still alows you to shoot yourself in the foot,
but you must do it explicitly. Either run

os.system("shotgun-browser &")

yourself or register your own ShotgunBrowser. Thus the new
framework is safe by default but still flexible.
History
Date User Action Args
2007-08-23 14:35:48adminlinkissue1338995 messages
2007-08-23 14:35:48admincreate