bug#4951: 23.1.50; browse-url-default-windows-browser bug + patch

[Lennart Borgman]

On Wed, Nov 18, 2009 at 2:00 PM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
> On Wed, Nov 18, 2009 at 6:54 AM, Jason Rumney <jasonr@f2s.com> wrote:
>> Lennart Borgman wrote:
>>>
>>> On Wed, Nov 18, 2009 at 4:35 AM, Stefan Monnier
>>> <monnier@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

Jason (or someone else), I have this in the registry

    Windows Registry Editor Version 5.00

    [HKEY_CLASSES_ROOT\file]
    "URL Protocol"=""
    @="URL:File Protocol"
    "Source Filter"="{E436EBB6-524F-11CE-9F53-0020AF0BA770}"

    [HKEY_CLASSES_ROOT\file\CLSID]
    @="{00000303-0000-0000-C000-000000000046}"

I believe this is what ShellExecute uses for a file:/// type url. This
does not work for me when "open" is specified to w32-shell-execute,
see above. What do you have in the registry here? There must be
something I am missing since "open" works for you but not for me.