Path: csiph.com!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder2.enfer-du-nord.net!border1.nntp.ams2.giganews.com!border3.nntp.ams.giganews.com!border1.nntp.ams.giganews.com!nntp.giganews.com!xlned.com!feeder3.xlned.com!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Newsgroups: comp.lang.python
Date: Sun, 24 Feb 2013 22:26:06 -0800 (PST)
In-Reply-To: <mailman.2488.1361770535.2939.python-list@python.org>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=99.162.129.213; posting-account=aw7wEQoAAACnaP8vftI9MyiC9NfXNJyr
References: <659b4770-12fb-400f-8aa5-049605347fe2@googlegroups.com> <CAMZYqRRD-X1aXvsze0vQ4Czs332ig3qCgJ2v-tOLWsB=pfao5g@mail.gmail.com> <mailman.2488.1361770535.2939.python-list@python.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Subject: Re: webbrowser.open("./documentation/help.html")-- No Go in Windows
From: llanitedave <llanitedave@veawb.coop>
To: comp.lang.python@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1
Cc: python-list@python.org
Precedence: list
Message-ID: <mailman.2492.1361774212.2939.python-list@python.org>
Lines: 107
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:39879

On Sunday, February 24, 2013 9:35:17 PM UTC-8, Terry Reedy wrote:
> On 2/24/2013 4:35 AM, Chris Rebert wrote:
> 
> 
> 
> > Sounds like this might be your problem:
> 
> > http://bugs.python.org/issue8936
> 
> 
> 
> I just closed that issue an invalid. Here is most of what I wrote.
> 
> '''
> 
> After reading the doc and the code, I am convinced that current behavior 
> 
> is close to the implied wanted behavior, and that it is not a bug.
> 
> 
> 
> The doc says
> 
>   webbrowser.open(url, new=0, autoraise=True)
> 
>      Display url using the default browser.
> 
> 
> 
> What does 'default browswer' mean? Near the top, the doc says "If the 
> 
> environment variable BROWSER exists, it is interpreted to override the 
> 
> platform default list of browsers,". So the 'default browser' is 
> 
> actually the 'default browser list'. What open() does is to try each in 
> 
> turn and stop when one says it succeeded. So the doc should say 'using 
> 
> the first default browser that claims to succeed.'
> 
> 
> 
> What does 'default browser list' mean? It depends on the platform *and* 
> 
> the software loaded on the particular machine when webbrowser is first 
> 
> imported in a particular instance of the interpreter. The 'platform' 
> 
> part is in the quote above, the rest is not. I will open a separate doc 
> 
> issue.
> 
> 
> 
> On Windows, the list starts with 'default Windows browser', which calls 
> 
> os.startfile(), which, I believe, does call the user default browser. 
> 
> Next is Internet Explorer -- if available at that time on the particular 
> 
> machine! If the user-default browser rejects the url, then IE is tried.
> 
> 
> 
> On my win7 machine today, I have Firefox the default and IE available. 
> 
> Firefox rejects 127.0.0.1:8080 with an 'Unable to connect' error box. IE 
> 
> 'accepts' it in the sense that it displays an information starting 'The 
> 
> webpage cannot be displayed'.
> 
> '''
> 
> 
> 
> For *this* issue, I strongly suspect that Chrome is rejecting the 
> 
> invalid URL and telling Python so. So IE is tried next (but not first).
> 
> 
> 
> > The fix would seem to be ensuring that the URL you pass includes the
> 
> > scheme (in your case, "file:").
> 
> 
> 
> so that Chrome does not return an error code, in which case IE should 
> 
> *not* be tried as a backup.
> 
> 
> 
> -- 
> 
> Terry Jan Reedy


Terry, after what I've learned today I'm tempted to agree that it's not necessarily a bug, and that maybe all that's needed is a bit more clarity in the documentation.

On the other hand, it *is* a bit frustrating that Linux recognizes an html-style relative path, while Windows insists on the entire absolute path.  Maybe we can call it a Windows bug, but a workaround would be nice to have.

However, combined with os.path.abspath(), it's not a huge issue -- once we understand the approach. 

I certainly appreciate your taking the time to make an analysis of it, and someday I hope to have the time and skills to help out in some small way.