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

[Lennart Borgman]

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