webbrowser.open("./documentation/help.html")-- No Go in Windows

[llanitedave]

I created an html help page for my Python 2.7.3 application and put it in adocumentation folder. I used webbrowser.open() to fetch the page.

On linux -- KDE specifically, the command opens the local file on my default browser with no issues. However, on Windows 7, it opens Internet Explorer, which doesn't even search the local folder, but goes straight to the weband does a Google search, returning nothing but useless noise.

My default browser on Windows is Chrome, so my intention is getting undermined right from the start.

How do I get a local html file to open properly from Python in Windows?

 

[Chris Rebert]

I created an html help page for my Python 2.7.3 application and put it in

a documentation folder. I used webbrowser.open() to fetch the page.

On linux -- KDE specifically, the command opens the local file on my

default browser with no issues. However, on Windows 7, it opens Internet
Explorer, which doesn't even search the local folder, but goes straight to
the web and does a Google search, returning nothing but useless noise.

My default browser on Windows is Chrome, so my intention is getting

undermined right from the start.

How do I get a local html file to open properly from Python in Windows?

Please provide the exact code snippet that you're using.

Cheers,
Chris

 

[Demian Brecht]

Rather than using a relative path, try using
webbrowser.open('{}/documentation/help.html'.format(os.path.dirname(__file__))).

 

[Chris Rebert]

I created an html help page for my Python 2.7.3 application and put it in

a documentation folder. I used webbrowser.open() to fetch the page.

On linux -- KDE specifically, the command opens the local file on my

default browser with no issues. However, on Windows 7, it opens Internet
Explorer, which doesn't even search the local folder, but goes straight to
the web and does a Google search, returning nothing but useless noise.

My default browser on Windows is Chrome, so my intention is getting

undermined right from the start.

How do I get a local html file to open properly from Python in Windows?

Sounds like this might be your problem:
http://bugs.python.org/issue8936

The fix would seem to be ensuring that the URL you pass includes the scheme
(in your case, "file:").

Cheers,
Chris

 

[llanitedave]

Sounds like this might be your problem:

http://bugs.python.org/issue8936

The fix would seem to be ensuring that the URL you pass includes the scheme (in your case, "file:").

Cheers,

Chris

Holy Toledo! That's a two-year-old bug spanning two versions of the language!

BTW, Chris, the snippet I showed in the title essentially WAS the exact code. It's a method with that single line called from a wxPython Help menu. I can't really put an absolute pathname into the argument, because the application is going to be distributed to a variety of computers at my workplace, and there's no assurance that it will go into (or remain in)a particularfolder.

I was trying to avoid using the wx.html.HtmlWindow feature of wxPython, because it doesn't handle CSS and styles. My help page is the portal to a multi-page users guide with a style sheet to render all the content consistently.

Plus, I couldn't get the wx.html.HtmlWindow to open relative paths either -- it gave me "URL Malformed" messages even in KDE, when webbrowser.open("filepath") was working for the exact same path. But that's something to takeup on the wxPython list, I guess.

This to me illustrates the downside of the Python philosophy of "There should be only one obvious way to do things". If that one obvious way has a fatal bug, you're pretty much SOL.

 

[llanitedave]

Sounds like this might be your problem:

http://bugs.python.org/issue8936

The fix would seem to be ensuring that the URL you pass includes the scheme (in your case, "file:").

Cheers,

Chris

Holy Toledo! That's a two-year-old bug spanning two versions of the language!

BTW, Chris, the snippet I showed in the title essentially WAS the exact code. It's a method with that single line called from a wxPython Help menu. I can't really put an absolute pathname into the argument, because the application is going to be distributed to a variety of computers at my workplace, and there's no assurance that it will go into (or remain in)a particularfolder.

I was trying to avoid using the wx.html.HtmlWindow feature of wxPython, because it doesn't handle CSS and styles. My help page is the portal to a multi-page users guide with a style sheet to render all the content consistently.

Plus, I couldn't get the wx.html.HtmlWindow to open relative paths either -- it gave me "URL Malformed" messages even in KDE, when webbrowser.open("filepath") was working for the exact same path. But that's something to takeup on the wxPython list, I guess.

This to me illustrates the downside of the Python philosophy of "There should be only one obvious way to do things". If that one obvious way has a fatal bug, you're pretty much SOL.

 

[Chris Rebert]

Holy Toledo! That's a two-year-old bug spanning two versions of the language!

BTW, Chris, the snippet I showed in the title essentially WAS the exact code.

Sorry, my bad. This is why I dislike messages that put critical info
*only* in the subject line; I tend not to reread the subject line once
I've opened the message.

It's a method with that single line called from a wxPython Help menu. Ican't really put an absolute pathname into the argument, because the application is going to be distributed to a variety of computers at my workplace, and there's no assurance that it will go into (or remain in)a particular folder.

As Demian demonstrated, you can simply compute the absolute path from
the relative path at runtime; although I would probably toss an
abspath() call in for good measure
(http://docs.python.org/2/library/os.path.html#os.path.abspath ).

This to me illustrates the downside of the Python philosophy of "There should be only one obvious way to do things". If that one obvious way has a fatal bug, you're pretty much SOL.

On the other hand, you don't have to investigate which of N APIs is
the "fixed"/"correct" one (Which PHP MySQL function is safe from SQL
injection again?), and you only have wait for 1 fix instead of N. But
yes, some of Python's included batteries are due for some recharging.

Cheers,
Chris

 

[Mark Lawrence]

Holy Toledo! That's a two-year-old bug spanning two versions of the language!

Only two years is nothing. Pay your money, take your choice

This to me illustrates the downside of the Python philosophy of "There should be only one obvious way to do things". If that one obvious way has a fatal bug, you're pretty much SOL.

Misquoted as always. I guess that some day someone will quote it correctly.

 

[llanitedave]

Sorry, my bad. This is why I dislike messages that put critical info

*only* in the subject line; I tend not to reread the subject line once

I've opened the message.

Nah, my bad. I didn't realize that the title was the only place I'd put the actual command. I don't like it when other people do that either.

As Demian demonstrated, you can simply compute the absolute path from

the relative path at runtime; although I would probably toss an

abspath() call in for good measure

(http://docs.python.org/2/library/os.path.html#os.path.abspath ).

OK, I'm going to have to study that one a bit. It looks like a new conceptfor my feeble brain.

On the other hand, you don't have to investigate which of N APIs is

the "fixed"/"correct" one (Which PHP MySQL function is safe from SQL

injection again?), and you only have wait for 1 fix instead of N. But

yes, some of Python's included batteries are due for some recharging.



Cheers,

Chris

You're right. It's one thing to have a persistent bug, it's another thing to offer the function in the documentation as if the bug doesn't exist.

The bug report from October 2010 indicated that someone was working on a fix at that time. The fact that it's still not fixed implies that it might be something that's really hard to pin down. In a case like that, it's probably better to simply withdraw the feature, or tag it as "Non-windows only"

 

[llanitedave]

Sorry, my bad. This is why I dislike messages that put critical info

*only* in the subject line; I tend not to reread the subject line once

I've opened the message.

Nah, my bad. I didn't realize that the title was the only place I'd put the actual command. I don't like it when other people do that either.

As Demian demonstrated, you can simply compute the absolute path from

the relative path at runtime; although I would probably toss an

abspath() call in for good measure

(http://docs.python.org/2/library/os.path.html#os.path.abspath ).

OK, I'm going to have to study that one a bit. It looks like a new conceptfor my feeble brain.

On the other hand, you don't have to investigate which of N APIs is

the "fixed"/"correct" one (Which PHP MySQL function is safe from SQL

injection again?), and you only have wait for 1 fix instead of N. But

yes, some of Python's included batteries are due for some recharging.



Cheers,

Chris

You're right. It's one thing to have a persistent bug, it's another thing to offer the function in the documentation as if the bug doesn't exist.

The bug report from October 2010 indicated that someone was working on a fix at that time. The fact that it's still not fixed implies that it might be something that's really hard to pin down. In a case like that, it's probably better to simply withdraw the feature, or tag it as "Non-windows only"

 

[llanitedave]

Only two years is nothing. Pay your money, take your choice






Misquoted as always. I guess that some day someone will quote it correctly.



--

Cheers.



Mark Lawrence

I think the correct quote is "You pays your money, and you takes your chances".

 

[llanitedave]

Only two years is nothing. Pay your money, take your choice






Misquoted as always. I guess that some day someone will quote it correctly.



--

Cheers.



Mark Lawrence

I think the correct quote is "You pays your money, and you takes your chances".

 

[MRAB]

Holy Toledo! That's a two-year-old bug spanning two versions of the
language!

BTW, Chris, the snippet I showed in the title essentially WAS the
exact code. It's a method with that single line called from a
wxPython Help menu. I can't really put an absolute pathname into the
argument, because the application is going to be distributed to a
variety of computers at my workplace, and there's no assurance that
it will go into (or remain in)a particular folder.

I was trying to avoid using the wx.html.HtmlWindow feature of
wxPython, because it doesn't handle CSS and styles. My help page is
the portal to a multi-page users guide with a style sheet to render
all the content consistently.

Plus, I couldn't get the wx.html.HtmlWindow to open relative paths
either -- it gave me "URL Malformed" messages even in KDE, when
webbrowser.open("filepath") was working for the exact same path. But
that's something to take up on the wxPython list, I guess.

This to me illustrates the downside of the Python philosophy of
"There should be only one obvious way to do things". If that one
obvious way has a fatal bug, you're pretty much SOL.

I've had a brief look at webbrowser.py. It's looking for the browsers in
the paths listed in the PATH environment variable.

On my PC at least, the paths to the other browsers, such as "C:\Program
Files\Mozilla Firefox" for Firefox, aren't listed there, hence the only
one it can find is Internet Explorer.

 

[Demian Brecht]

For the record, I completely misread and misunderstood the question. I
should stop posting that late at night

 

[llanitedave]

On Sunday, February 24, 2013 1:35:31 AM UTC-8, Chris Rebert wrote:
[snip]

Sounds like this might be your problem:

http://bugs.python.org/issue8936

The fix would seem to be ensuring that the URL you pass includes
the scheme (in your case, "file:").

Holy Toledo! That's a two-year-old bug spanning two versions of the


BTW, Chris, the snippet I showed in the title essentially WAS the

exact code. It's a method with that single line called from a

wxPython Help menu. I can't really put an absolute pathname into the

argument, because the application is going to be distributed to a

variety of computers at my workplace, and there's no assurance that

it will go into (or remain in)a particular folder.

I was trying to avoid using the wx.html.HtmlWindow feature of

wxPython, because it doesn't handle CSS and styles. My help page is

the portal to a multi-page users guide with a style sheet to render

all the content consistently.

Plus, I couldn't get the wx.html.HtmlWindow to open relative paths

either -- it gave me "URL Malformed" messages even in KDE, when

webbrowser.open("filepath") was working for the exact same path. But

that's something to take up on the wxPython list, I guess.

This to me illustrates the downside of the Python philosophy of

"There should be only one obvious way to do things". If that one

obvious way has a fatal bug, you're pretty much SOL.

I've had a brief look at webbrowser.py. It's looking for the browsers in

the paths listed in the PATH environment variable.



On my PC at least, the paths to the other browsers, such as "C:\Program

Files\Mozilla Firefox" for Firefox, aren't listed there, hence the only

one it can find is Internet Explorer.

Well, it's still very odd, because when I use wxPython's wx.html.HtmlWindowto click a web link, it DOES use the default browser, which is Chrome on my PC. It's just using the webbrowser.open() function that goes to IE. Until then, I'd been suspecting that wx.html.HtmlWindow was using webbrowser.open() under the hood. I guess not.

But wx.html.HtmlWindow doesn't work on relative paths, it seems (in neitherLinux NOR Windows), so I'm not able to find a substitute as of yet.

 

[llanitedave]

On Sunday, February 24, 2013 1:35:31 AM UTC-8, Chris Rebert wrote:
[snip]

Sounds like this might be your problem:

http://bugs.python.org/issue8936

The fix would seem to be ensuring that the URL you pass includes
the scheme (in your case, "file:").

Holy Toledo! That's a two-year-old bug spanning two versions of the


BTW, Chris, the snippet I showed in the title essentially WAS the

exact code. It's a method with that single line called from a

wxPython Help menu. I can't really put an absolute pathname into the

argument, because the application is going to be distributed to a

variety of computers at my workplace, and there's no assurance that

it will go into (or remain in)a particular folder.

I was trying to avoid using the wx.html.HtmlWindow feature of

wxPython, because it doesn't handle CSS and styles. My help page is

the portal to a multi-page users guide with a style sheet to render

all the content consistently.

Plus, I couldn't get the wx.html.HtmlWindow to open relative paths

either -- it gave me "URL Malformed" messages even in KDE, when

webbrowser.open("filepath") was working for the exact same path. But

that's something to take up on the wxPython list, I guess.

This to me illustrates the downside of the Python philosophy of

"There should be only one obvious way to do things". If that one

obvious way has a fatal bug, you're pretty much SOL.

I've had a brief look at webbrowser.py. It's looking for the browsers in

the paths listed in the PATH environment variable.



On my PC at least, the paths to the other browsers, such as "C:\Program

Files\Mozilla Firefox" for Firefox, aren't listed there, hence the only

one it can find is Internet Explorer.

Well, it's still very odd, because when I use wxPython's wx.html.HtmlWindowto click a web link, it DOES use the default browser, which is Chrome on my PC. It's just using the webbrowser.open() function that goes to IE. Until then, I'd been suspecting that wx.html.HtmlWindow was using webbrowser.open() under the hood. I guess not.

But wx.html.HtmlWindow doesn't work on relative paths, it seems (in neitherLinux NOR Windows), so I'm not able to find a substitute as of yet.

 

[llanitedave]

For the record, I completely misread and misunderstood the question. I

should stop posting that late at night












--

Demian Brecht

http://demianbrecht.github.com

Well, between you and Chris, I think you've got me on the right track. If things keep going like they are now, I should have it back under control inan hour or two.

So, thanks in advance for all of you!

 

[llanitedave]

For the record, I completely misread and misunderstood the question. I

should stop posting that late at night












--

Demian Brecht

http://demianbrecht.github.com

Well, between you and Chris, I think you've got me on the right track. If things keep going like they are now, I should have it back under control inan hour or two.

So, thanks in advance for all of you!

 

[llanitedave]

Well, we can mark this one as solved.

Simple enough, actually -- thanks to Chris and Demian for leading me to water.

The following code works on both Linux and Windows 7:

def OnDocs(self, event):
"""Opens the User's Guide in the default web browser"""
fullpath = os.path.abspath('documentation/HTMLDocs/index.html')
url_link = "file:///" + fullpath
webbrowser.open(url_link)

This allows both platforms to have their own idiosyncratic path structures without having to create separate code for each. It even chooses the correct browser!

I learned some more about Python today, too. I'd never explored the 'os.' library before, and now I see things a little more clearly.

Thanks again, guys!

 

[Terry Reedy]

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.