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: selection of browser
Type: Stage:
Components: Library (Lib) Versions:
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: fdrake Nosy List: doko, fdrake, gvanrossum, niemeyer, nobody
Priority: high Keywords:

Created on 2001-12-21 00:56 by doko, last changed 2022-04-10 16:04 by admin. This issue is now closed.

File name Uploaded Description Edit
webbrowser-diff doko, 2002-09-08 09:47
Messages (10)
msg8414 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2001-12-21 00:56
[please CC on replies; complete 
report can be found at ] tries hard to select correct browsers 
and then wastes it

The culprit is the last loop, registering everything 
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/	Sun Nov 11 
18:23:54 2001
+++ /tmp/	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-----
msg8415 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2001-12-28 22:19
Logged In: YES 

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.
msg8416 - (view) Author: Nobody/Anonymous (nobody) Date: 2002-01-09 10:23
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.
msg8417 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2002-01-09 13:57
Logged In: YES 

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.
msg8418 - (view) Author: Fred Drake (fdrake) (Python committer) Date: 2002-01-09 14:28
Logged In: YES 

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.
msg8419 - (view) Author: Fred Drake (fdrake) (Python committer) Date: 2002-01-09 14:37
Logged In: YES 

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.)
msg8420 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2002-09-08 09:47
Logged In: YES 

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?
msg8421 - (view) Author: Fred Drake (fdrake) (Python committer) Date: 2002-10-11 13:13
Logged In: YES 

Galeon support has been added in revision 1.33.
msg8422 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2002-10-12 07:52
Logged In: YES 

Setting the "Resolution" from "Invalid" to "Remind", see
message from 2002-09-08.
msg8423 - (view) Author: Gustavo Niemeyer (niemeyer) * (Python committer) Date: 2002-11-25 17:34
Logged In: YES 

Fixed in the following revisions:

Lib/ 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!
Date User Action Args
2022-04-10 16:04:49adminsetgithub: 35811
2001-12-21 00:56:47dokocreate