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.

Title: CVS (1.40) bugs
Type: Stage:
Components: Library (Lib) Versions: Python 2.5
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: georg.brandl, gregcouch, phd, skip.montanaro
Priority: normal Keywords:

Created on 2005-10-26 23:08 by gregcouch, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (22)
msg26720 - (view) Author: Greg Couch (gregcouch) Date: 2005-10-26 23:08
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).
msg26721 - (view) Author: Oleg Broytman (phd) * Date: 2005-10-27 15:36
Logged In: YES 

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?!
msg26722 - (view) Author: Greg Couch (gregcouch) Date: 2005-10-27 17:35
Logged In: YES 

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.
msg26723 - (view) Author: Oleg Broytman (phd) * Date: 2005-10-28 11:56
Logged In: YES 

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

And, BTW, Elinks is a subclass of UnixBrowser, not
msg26724 - (view) Author: Greg Couch (gregcouch) Date: 2005-10-28 18:49
Logged In: YES 

So you really want to change existing practice and break all
Python GUI programs that invoke

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
msg26725 - (view) Author: Oleg Broytman (phd) * Date: 2005-10-31 13:11
Logged In: YES 

Yes, I want.

Current practice of running a browser in the background by
default is deadly broken. The old code of 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 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 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.
msg26726 - (view) Author: Greg Couch (gregcouch) Date: 2005-10-31 22:01
Logged In: YES 

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.
msg26727 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2005-11-09 21:43
Logged In: YES 

Fixed in Revision 41419.
msg26728 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2005-11-15 04:08
Logged In: YES 

(Reopening.  The webbrowser module still appears broken to me.)

I'm new to this thread, but in current SVN 
(revision 41445) seems broken to me.  This simple statement:"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.
msg26729 - (view) Author: Oleg Broytman (phd) * Date: 2005-11-18 20:36
Logged In: YES 

So it seems the new is too new. May I suggest
to rename the new module and doc to, and
restore the old version of the module and the doc?
msg26730 - (view) Author: Greg Couch (gregcouch) Date: 2005-12-03 02:12
Logged In: YES 

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 and
should address Oleg Broytmann concerns as well.
msg26731 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2005-12-04 17:22
Logged In: YES 

I gave patch #1372125 a try.  This still fails:"/tmp/mmhelp.html")

while this works:"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.
msg26732 - (view) Author: Greg Couch (gregcouch) Date: 2005-12-06 20:21
Logged In: YES 

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 should support filesystem
paths in addition to URLs, is a different
bug/question/patch.  In my application, I encapsulate with code that supports it and it could be
added fairly easily.  Here's the information needed for
anyone to do so:


works or not is browser dependent (works with Netscape
4.76!).  In fact, even the other example:"file:///tmp/mmhelp.html")

will fail on some browsers (Safari, may be fixed by now),
and one needs to do:"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.
msg26733 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2005-12-06 20:40
Logged In: YES 

> Whether or not 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.

msg26734 - (view) Author: Greg Couch (gregcouch) Date: 2005-12-06 21:21
Logged In: YES 

Then file a bug report with whoever makes your web browser.
 It's not Python's webbrowser module's fault that the
browser doesn't accept filesystem paths.  The webbrowser
module is only documented to work with URLs, so any code
that depends on paths is arguably buggy.  That said, if
someone else will write a patch for the documentation, I
will write a patch for the code.  - Greg
msg26735 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2005-12-06 21:57
Logged In: YES 

You're missing the point.  It works in Python 2.4 and
doesn't on CVS HEAD.  I've already had to modify one
application.  Maybe the old webbrowser module
used to prepend a "file://localhost/" to filenames
that were missing schemes.  All I know is it used to
work and now it doesn't  As is, 2.5 is likely to
break some applications that rely on the behavior in
msg26736 - (view) Author: Greg Couch (gregcouch) Date: 2005-12-06 22:27
Logged In: YES 

And you seem to have scanned my previous post and missed
where I discussed all of the problems with  I should have been more explicit
that those were problems with the all versions of the
webbrowser module.  It is browser-dependent whether or not
opening a path works at all.  I have had to work around that
"problem" for years (starting with grail in 1997 and carried
over to the webbroswer module in 2001).  Any cross-platform
developer, that tests their code, already has a workaround
in place.

If the webbrowser documentation agreed with you, then I
would agree with you as well.  Although I feel we are
already violently agreeing.  "Fix" the documentation and
I'll "fix" the code.
msg26737 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2005-12-06 23:38
Logged In: YES 

All I'm saying is that if this form"/tmp/foo.html")

was supported in Python 2.4, possibly by recognizing the bare
path and silently pretending the programmer wrote"file://localhost/tmp/foo.html")

then it ought to do the same in 2.5 unless you intend to break
existing applications.  How hard can it be to recognize that
the first character of the "url" is "/" and prepend "file://localhost/"
before passing it along to the user's chosen browser?

I suggest compatibility with urllib.urlopen is desirable:

>>> f = urllib.urlopen("/etc/hosts")
"##\n# Host Database\n# \n# Note that this file is consulted when the 
system is running in single-user\n# mode.  At other times this information is 
handled by lookupd.  By default,\n# lookupd gets information from NetInfo, 
so this file will not be consulted\n# unless you have changed lookupd's 
configuration.\n#\n# localhost is used to configure the loopback interface\n# 
when the system is booting.  Do not change this 

msg26738 - (view) Author: Greg Couch (gregcouch) Date: 2005-12-07 00:13
Logged In: YES 

And I agree it is desirable, but it didn't work reliably in
2.4 nor any earlier version, and it isn't documented to work.  

The urllib.urlopen example you gave fails miserably with
Windows files names, i.e., given "C:\WINDOWS\system.ini" it
tries to interpret the C as a scheme.  You need to use
urllib's pathname2url function and pass the result to
urlopen.  If is fixed, then maybe there will
be some pressure to fix urlopen as well.

You just have been lucky or unlucky depending on how you
view it.
msg26739 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2006-01-20 21:05
Logged In: YES 

Another try to fix it in 42121. I added a special case for
OSX browsers wrt local URLs. Skip, can you test?
msg26740 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2006-01-21 15:06
Logged In: YES 

> Skip, can you test?

Yes, it works, thanks.  I can understand special casing local URLs, but why
also OSX?  Was that the only platform on which local URLs failed?
msg26741 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2006-01-21 19:04
Logged In: YES 

Well, all of the Unix browsers I tried accept filenames
without a problem, the os.startfile function on Windows does
it in any case. That left OSX and Safari.
Date User Action Args
2022-04-11 14:56:13adminsetgithub: 42526
2005-10-26 23:08:06gregcouchcreate