[please CC 121737@bugs.debian.org on replies; complete 
report can be found at http://bugs.debian.org/121737 ]

webbrowser.py tries hard to select correct browsers 
and then wastes it

The culprit is the last loop, registering everything 
possible.
I'm not sure, but wasn't it supposed to run only in 
the environ["BROWSER"]
case like this?:

-----diff start-----
--- /usr/lib/python2.1/webbrowser.py	Sun Nov 11 
18:23:54 2001
+++ /tmp/webbrowser.py	Thu Nov 29 17:40:46 2001
@@ -305,11 +305,10 @@
     # It's the user's responsibility to register 
handlers for any unknown
     # browser referenced by this value, before 
calling open().
     _tryorder = os.environ["BROWSER"].split(":")
-
-for cmd in _tryorder:
-    if not _browsers.has_key(cmd.lower()):
-        if _iscommand(cmd.lower()):
-            register(cmd.lower(), None, GenericBrowser
("%s %%s" % cmd.lower()))
+    for cmd in _tryorder:
+        if not _browsers.has_key(cmd.lower()):
+            if _iscommand(cmd.lower()):
+                register(cmd.lower(), None, 
GenericBrowser("%s %%s" % cmd.lower()))

 _tryorder = filter(lambda x: _browsers.has_key(x.lower
())
                    or x.find("%s") > -1, _tryorder)
-----diff end-----

Logged In: YES 
user_id=6380

I don't think this is a bug. The report doesn't explain what
undesirable behavior follows, and it looks like some
platforms need the registration. Note that the registry is
independent from the try order -- the registry may contain
browsers that are not in the try order, but they won't be
used unless you add them to the try order yourself.

Closing this as Invalid.

BTW, please encourage your users to interact with SF
directly rather than forwarding bugs from Debian here. It is
too painful.

Logged In: NO 

But it is the other way around. Earlier you have:
if os.environ.get("TERM") or os.environ.get("DISPLAY"):
    _tryorder = ("mozilla","netscape","kfm","grail","links","lynx","w3m")

So _tryorder is _full_ of browsers.
And then they are all registered, of course only if they are available,
but disregarding $TERM and $DISPLAY.
So mozilla _is_ registered, and _is_ in _tryorder, and _will_ be run.
And, surprise, surprise, I run mostly on the virual console, and not in X.

If it is supposed to be that way it's very strange for me.

Logged In: YES 
user_id=6380

If your real complaint is that you are not running under X
yet it tries to start Mozilla, please say so. If that's the
case, we have to figure out where the bug is.

reopening and assigning to Fred Drake -- I don't follow the
login in the module and the use of the _tryorder and
_browsers variable is not documented very well.

Logged In: YES 
user_id=3066

Sounds painful, but I can't look at it right now (though I
don't think it will be hard to fix).  I've bumped the
priority up and set the tracker fields to reasonable values
for this report.

I'll need to be careful about testing this with & without
$BROWSER both on a console and under X.

Logged In: YES 
user_id=3066

I'll make a note here so I don't forget:  I should add
galeon and skipstone to the list of known browsers.  (Both
are based on the Mozilla engine.)

Logged In: YES 
user_id=60903

Attached is a patch, which changes _tryorder to try the
text-based browsers first in absence of the DISPLAY environment.

No change for the case where BROWSER is set. Should the
module take care of the case, where BROWSER is set to i.e.
mozilla and you're running on the console?

Logged In: YES 
user_id=3066

Galeon support has been added in revision 1.33.

Logged In: YES 
user_id=60903

Setting the "Resolution" from "Invalid" to "Remind", see
message from 2002-09-08.

Logged In: YES 
user_id=7887

Fixed in the following revisions:

Lib/webbrowser.py: 1.35
Misc/NEWS: 1.542

Matthias, I've used a slightly different way to fix the
problem. I've done that because I see no point in including
graphic browsers in _tryorder, even with a lower priority,
if running in a console.

Fred, I've also included skipstone as you suggested. I've
looked at its code to check if it accepted any options, but
it doesn't look so. Thus, it's just a generic browser. I've
also done the extensive tests you mentioned, in console and
X, with and without BROWSER set.

Thanks for the report Matthias!