Bugs item #1338995, was opened at 2005-10-26 18:08
Message generated for change (Comment added) made by montanaro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Couch (gregcouch)
Assigned to: Nobody/Anonymous (nobody)
Summary: CVS webbrowser.py (1.40) bugs
Initial Comment:
There are two calls to _safequote that are only made on
darwin, aka, Mac OS X. That function is missing.
And the UnixBrowser is missing an & in the "simpler
command" and thus causes python to hang until the
browser is exited (if it wasn't running already).
----------------------------------------------------------------------
>Comment By: Skip Montanaro (montanaro)
Date: 2005-12-06 14:40
Message:
Logged In: YES
user_id=44345
> Whether or not webbrowser.open should support filesystem
> paths in addition to URLs, is a different
> bug/question/patch.
Given that it used to work, I consider it gratuitous
breakage that it doesn't anymore.
S
----------------------------------------------------------------------
Comment By: Greg Couch (gregcouch)
Date: 2005-12-06 14:21
Message:
Logged In: YES
user_id=131838
Oops, that was bug #1352621 for an analysis of why the
previous fix was bad. I closed it as a duplicate because
this bug was reopened.
The short answer to your question about schemeless URLs, is
no, they aren't supposed to work because they are not URLs.
Whether or not webbrowser.open should support filesystem
paths in addition to URLs, is a different
bug/question/patch. In my application, I encapsulate
webbrowser.open with code that supports it and it could be
added fairly easily. Here's the information needed for
anyone to do so:
Whether:
webbrowser.open("/tmp/mmhelp.html")
works or not is browser dependent (works with Netscape
4.76!). In fact, even the other example:
webbrowser.open("file:///tmp/mmhelp.html")
will fail on some browsers (Safari, may be fixed by now),
and one needs to do:
webbrowser.open("file://localhost/tmp/mmhelp.html")
instead (so a bug, but one my application had to
workaround). I recall there being cases of the reverse
being true, but I can't find those notes.
Constructing the file URL is a minor pain, but I'm not sure
what I'd change. I use urllib.pathname2url(), but that
doesn't add the file scheme. So I use urlparse.urlunparse
to build the actual URL -- that seems like overkill, but I
might have a fragment (some browsers support fragments with
the file scheme, some just ignore them). The OS X bug is
easy fix in between the calls to pathname2url and urlunparse.
----------------------------------------------------------------------
Comment By: Skip Montanaro (montanaro)
Date: 2005-12-04 11:22
Message:
Logged In: YES
user_id=44345
I gave patch #1372125 a try. This still fails:
webbrowser.open("/tmp/mmhelp.html")
while this works:
webbrowser.open("file:///tmp/mmhelp.html")
Is the schemeless form supposed to work or not?
Also, there appears to be a digit missing from the bug reference #135261
and a simple search for "webbrowser" doesn't turn it up.
----------------------------------------------------------------------
Comment By: Greg Couch (gregcouch)
Date: 2005-12-02 20:12
Message:
Logged In: YES
user_id=131838
See bug #135261 and patch #1372125. The patch contains
changes to use subprocess.Popen instead of os.system for the
UnixBrowser and fixes my problems with webbrowser.py and
should address Oleg Broytmann concerns as well.
----------------------------------------------------------------------
Comment By: Oleg Broytmann (phd)
Date: 2005-11-18 14:36
Message:
Logged In: YES
user_id=4799
So it seems the new webbrowser.py is too new. May I suggest
to rename the new module and doc to webbrowser2.py, and
restore the old version of the module and the doc?
----------------------------------------------------------------------
Comment By: Skip Montanaro (montanaro)
Date: 2005-11-14 22:08
Message:
Logged In: YES
user_id=44345
(Reopening. The webbrowser module still appears broken to me.)
I'm new to this thread, but webbrowser.open() in current SVN
(revision 41445) seems broken to me. This simple statement:
webbrowser.open("somefile.html")
returns True but fails to open the page in my currently running
instance of Safari. Dropping back to Python 2.4.1, it works fine.
I know webbrowser was a huge hack, but at least it appeared to do
basic stuff fine. It would appear that's no longer the case.
----------------------------------------------------------------------
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-11-09 15:43
Message:
Logged In: YES
user_id=1188172
Fixed in Revision 41419.
----------------------------------------------------------------------
Comment By: Greg Couch (gregcouch)
Date: 2005-10-31 16:01
Message:
Logged In: YES
user_id=131838
Breaking applications that use webbrowser does not help
application writers. It would be much more useful to me, as
an application writer, if the webbrowser module gave an
error saying it couldn't contact a web browser, rather than
the new behavior of hanging my application. You have yet to
address this common use case.
Running the webbrowser in the background is a contract that
the webbrowser module can't break and still be called the
webbrowser module. I agree that the 2.4.2 version is a
practical hack that should be fixed, but the CVS webbrower
almost fixes it while breaking existing applications. Since
adding an & is so bad (the web browser is already confirmed
to exist and to be executable), the CVS webbrower could be
changed to use the subprocess module instead of os.system,
and the original webbrowser contract could be preserved.
The wrong display or wrong xhost/xauth permissions are not a
problem because the python GUI application that calls
webbrowser would have failed to start up in the first place
if those problems existed. Starting the web browser in the
background only needs to confirm that the web browser
actually started up.
----------------------------------------------------------------------
Comment By: Oleg Broytmann (phd)
Date: 2005-10-31 07:11
Message:
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.
----------------------------------------------------------------------
Comment By: Greg Couch (gregcouch)
Date: 2005-10-28 13:49
Message:
Logged In: YES
user_id=131838
So you really want to change existing practice and break all
Python GUI programs that invoke webbrowser.open?
And the Elinks example proves my point. What is the point
of it being a UnixBrowser, in the terminal window, if you
can't send remote commands to it (because the Python GUI
application is blocked until the browser exits)? Tty-based
browsers are nice for completeness, but are really a last
resort for a Python application, and imply that no windowing
system is available (i.e, remotely logged in and not
forwarding X connections, so not running GUI applications
either).
----------------------------------------------------------------------
Comment By: Oleg Broytmann (phd)
Date: 2005-10-28 06:56
Message:
Logged In: YES
user_id=4799
No, I still think it is a bad idea to put a generic Unix
browser to background by default. If you want to do it - do
it explicitly. Start a browser in a background yourself, and
use remote actions from the module to open new windows/tabs.
Or register another browser, with different .open() and/or
._remote().
And, BTW, Elinks is a subclass of UnixBrowser, not
GenericBrowser.
----------------------------------------------------------------------
Comment By: Greg Couch (gregcouch)
Date: 2005-10-27 12:35
Message:
Logged In: YES
user_id=131838
And I don't want starting up firefox to hang my python GUI
either. So, if you look at the code more closely,
lynx/links/elinks subclass from GenericBrowser not
UnixBrowser, so adding the & to UnixBrowser is the correct
thing to do.
----------------------------------------------------------------------
Comment By: Oleg Broytmann (phd)
Date: 2005-10-27 10:36
Message:
Logged In: YES
user_id=4799
Yes, _safequote() call seems like a bug. A leftover after
I've merged a half dozens of patches into this one. Should
be removed.
But there should certainly be no '&'. You certainly dont
want to start lynx/links/elinks in the background, do you?!
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
