GNU bug report logs -
#4951
23.1.50; browse-url-default-windows-browser bug + patch
Previous Next
Full log
Message #25 received at 4951 <at> emacsbugs.donarmstrong.com (full text, mbox):
On Wed, Nov 18, 2009 at 6:54 AM, Jason Rumney <jasonr <at> f2s.com> wrote:
> Lennart Borgman wrote:
>>
>> On Wed, Nov 18, 2009 at 4:35 AM, Stefan Monnier
>> <monnier <at> iro.umontreal.ca> wrote:
>>
>>>>
>>>> browse-url-default-windows-browser does not work any longer. I am
>>>> unsure when it stopped working, but on at least Windows XP the
>>>> attached patch seems necessary. Could we please apply this as soon as
>>>> possible so it will get tested?
>>>>
>>>
>>> Could you explain why it's necessary? I mean I understand you say that
>>> the current doesn't work, but I'd like to understand why it doesn't work.
>>>
>>
>> No, I do not understand why it is necessary ... ;-)
>>
>> There are two changes:
>>
>> 1) file: => file:///
>>
>> This was discussed some time ago (a yr or two?) and it looks like this
>> is a more correct syntax for the file URL.
>>
>
> Is it actually needed, or is this purely an aesthetic thing? The RFCs are
> not clear whether either is more correct, as the file: scheme is not
> explicitly defined, and not all URL schemes require a server to be specified
> before the file path. As far as I can tell, either option is accepted by
> Windows itself, but if the association passes the URL intact rather than
> after converting to a file argument by Windows, then there may be
> applications that accept one but not the other.
>
> IIRC the main reason for using file: rather than file:/// was that if the
> same code is used on all platforms, then the former works, while the latter
> does not (too many / when combined with posix paths). But as this is now in
> a (windows-nt msdos cygwin) conditional, that is not really important, and
> we should use what works.
This is perhaps not needed, but it seems more consistent and I
therefore thinks that there is a better chance that this works. (I
have been using this very long, but I can't remember any more why I
switched.)
>> 2) Changing the verb to w32-shell-execute (ShellExecute) from "open"
>> to nil is for some reason I do not know necessary. The answer to why
>> hides deep within the w32 registry and maybe some knowledgeable
>> persons at MS... It might be a mismatch of some kind, I don't know. I
>> believe the verbs are not that well thought out and used all the time.
>> Probably the registry entry has taken over from the program code
>> (which give users and other programs better possibilities).
>>
>
> It is likely a misconfiguration on your system. "open" is the standard verb
> for opening files, and should avoid the security problems associated with
> using nil for executable file types where the system's default action is
> something other than "open".
You might be right. I thought that file:/// was special and would
always be opened in a web browser, but that is maybe not at all true.
I do not know how Windows handles this. Are there any special w32
registry entries for file: that you are aware of?
Just looking at Explorer under Tools - Folder Options and then File
Types it looks like the file:/// URL is not handled special since
there is no entry there for this URL type, but that is not correct. It
is handled specially. Here are some tests I have made:
(w32-shell-execute "open" "c:/some/file.html") ;; OK
(w32-shell-execute nil "file:c:/some/file.html") ;; OK
(w32-shell-execute nil "file:///c:/some/file.html") ;; OK
(w32-shell-execute "open" "file:///c:/some/file.html") ;; Doesn't work
(w32-shell-execute "open" "file:c:/some/file.html") ;; Doesn't work
This bug report was last modified 13 years and 313 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.