* bug#4951: 23.1.50; browse-url-default-windows-browser bug + patch
@ 2010-01-02 20:31 Chong Yidong
2011-09-11 5:18 ` Lars Magne Ingebrigtsen
0 siblings, 1 reply; 9+ messages in thread
From: Chong Yidong @ 2010-01-02 20:31 UTC (permalink / raw
To: Lennart Borgman; +Cc: 4951
> 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.
This was included in the 2009-11-23 change by Ken Brown.
> 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.
Is this still necessary?
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#4951: 23.1.50; browse-url-default-windows-browser bug + patch
2010-01-02 20:31 bug#4951: 23.1.50; browse-url-default-windows-browser bug + patch Chong Yidong
@ 2011-09-11 5:18 ` Lars Magne Ingebrigtsen
0 siblings, 0 replies; 9+ messages in thread
From: Lars Magne Ingebrigtsen @ 2011-09-11 5:18 UTC (permalink / raw
To: Chong Yidong; +Cc: 4951
Chong Yidong <cyd@stupidchicken.com> writes:
>> 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.
>
> Is this still necessary?
More information was requested a year and a half ago, and was not
followed up on, so I'm closing this bug. Please reopen if it turns out
that this is still necessary.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#4951: 23.1.50; browse-url-default-windows-browser bug + patch
@ 2009-11-18 1:46 Lennart Borgman
2009-11-18 3:35 ` Stefan Monnier
0 siblings, 1 reply; 9+ messages in thread
From: Lennart Borgman @ 2009-11-18 1:46 UTC (permalink / raw
To: emacs-pretest-bug
[-- Attachment #1: Type: text/plain, Size: 471 bytes --]
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?
In GNU Emacs 23.1.50.1 (i386-mingw-nt5.1.2600)
of 2009-10-15
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --no-opt --cflags
-Ic:/g/include -fno-crossjumping'
[-- Attachment #2: browse-url.patch --]
[-- Type: text/x-diff, Size: 1752 bytes --]
Index: browse-url.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/net/browse-url.el,v
retrieving revision 1.85
diff -c -r1.85 browse-url.el
*** browse-url.el 6 Nov 2009 05:16:29 -0000 1.85
--- browse-url.el 18 Nov 2009 01:27:21 -0000
***************
*** 444,450 ****
;; applies.
("^/\\([^:@]+@\\)?\\([^:]+\\):/*" . "ftp://\\1\\2/")
,@(if (memq system-type '(windows-nt ms-dos cygwin))
! '(("^\\([a-zA-Z]:\\)[\\/]" . "file:\\1/")
("^[\\/][\\/]+" . "file://")))
("^/+" . "file:///"))
"An alist of (REGEXP . STRING) pairs used by `browse-url-of-file'.
--- 444,450 ----
;; applies.
("^/\\([^:@]+@\\)?\\([^:]+\\):/*" . "ftp://\\1\\2/")
,@(if (memq system-type '(windows-nt ms-dos cygwin))
! '(("^\\([a-zA-Z]:\\)[\\/]" . "file:///\\1/")
("^[\\/][\\/]+" . "file://")))
("^/+" . "file:///"))
"An alist of (REGEXP . STRING) pairs used by `browse-url-of-file'.
***************
*** 834,840 ****
(if dos-windows-version
(shell-command (concat "start " (shell-quote-argument url)))
(error "Browsing URLs is not supported on this system"))
! (w32-shell-execute "open" url)))
(defun browse-url-default-macosx-browser (url &optional new-window)
(interactive (browse-url-interactive-arg "URL: "))
--- 834,840 ----
(if dos-windows-version
(shell-command (concat "start " (shell-quote-argument url)))
(error "Browsing URLs is not supported on this system"))
! (w32-shell-execute nil url)))
(defun browse-url-default-macosx-browser (url &optional new-window)
(interactive (browse-url-interactive-arg "URL: "))
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#4951: 23.1.50; browse-url-default-windows-browser bug + patch
2009-11-18 1:46 Lennart Borgman
@ 2009-11-18 3:35 ` Stefan Monnier
2009-11-18 3:41 ` Lennart Borgman
0 siblings, 1 reply; 9+ messages in thread
From: Stefan Monnier @ 2009-11-18 3:35 UTC (permalink / raw
To: Lennart Borgman; +Cc: 4951
> 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.
Stefan
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#4951: 23.1.50; browse-url-default-windows-browser bug + patch
2009-11-18 3:35 ` Stefan Monnier
@ 2009-11-18 3:41 ` Lennart Borgman
2009-11-18 5:54 ` Jason Rumney
0 siblings, 1 reply; 9+ messages in thread
From: Lennart Borgman @ 2009-11-18 3:41 UTC (permalink / raw
To: Stefan Monnier; +Cc: 4951
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.
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).
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#4951: 23.1.50; browse-url-default-windows-browser bug + patch
2009-11-18 3:41 ` Lennart Borgman
@ 2009-11-18 5:54 ` Jason Rumney
2009-11-18 13:00 ` Lennart Borgman
0 siblings, 1 reply; 9+ messages in thread
From: Jason Rumney @ 2009-11-18 5:54 UTC (permalink / raw
To: Lennart Borgman, 4951
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.
> 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".
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#4951: 23.1.50; browse-url-default-windows-browser bug + patch
2009-11-18 5:54 ` Jason Rumney
@ 2009-11-18 13:00 ` Lennart Borgman
2009-11-19 4:37 ` Lennart Borgman
0 siblings, 1 reply; 9+ messages in thread
From: Lennart Borgman @ 2009-11-18 13:00 UTC (permalink / raw
To: Jason Rumney; +Cc: 4951
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#4951: 23.1.50; browse-url-default-windows-browser bug + patch
2009-11-18 13:00 ` Lennart Borgman
@ 2009-11-19 4:37 ` Lennart Borgman
2009-11-23 1:34 ` Lennart Borgman
0 siblings, 1 reply; 9+ messages in thread
From: Lennart Borgman @ 2009-11-19 4:37 UTC (permalink / raw
To: Jason Rumney; +Cc: 4951
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#4951: 23.1.50; browse-url-default-windows-browser bug + patch
2009-11-19 4:37 ` Lennart Borgman
@ 2009-11-23 1:34 ` Lennart Borgman
0 siblings, 0 replies; 9+ messages in thread
From: Lennart Borgman @ 2009-11-23 1:34 UTC (permalink / raw
To: Jason Rumney; +Cc: 4951
I have tried to find the cause of the problem. Some people on
help-emacs-windows@gnu.org mailing list helped me, but I could not
find anything specific.
However I wrote this function and will include it in my patched
version of Emacs+EmacsW32 for those who needs it. (I am not the only
one having this trouble.)
;; (customize-option-other-window 'browse-url-browser-function)
(defun browse-url-no-open-windows-browser (url &optional new-window)
"Same as `browse-url-default-windows-browser' nearly.
You may want to customize `browse-url-browser-function' to this
function if files do not open in your web browser. It is known
that some pc:s have this problem, reason is so far unknown.
The cure seem to be to call `w32-shell-execute' with a nil
argument here instead of \"open\" which the default function
function `browse-url-default-windows-browser' does.
This should be safe unless your computer is strangely configured,
since you are normaly opening .html files with this function."
(interactive (browse-url-interactive-arg "URL: "))
(if (eq system-type 'ms-dos)
(if dos-windows-version
(shell-command (concat "start " (shell-quote-argument url)))
(error "Browsing URLs is not supported on this system"))
(w32-shell-execute nil url)))
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2011-09-11 5:18 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-01-02 20:31 bug#4951: 23.1.50; browse-url-default-windows-browser bug + patch Chong Yidong
2011-09-11 5:18 ` Lars Magne Ingebrigtsen
-- strict thread matches above, loose matches on Subject: below --
2009-11-18 1:46 Lennart Borgman
2009-11-18 3:35 ` Stefan Monnier
2009-11-18 3:41 ` Lennart Borgman
2009-11-18 5:54 ` Jason Rumney
2009-11-18 13:00 ` Lennart Borgman
2009-11-19 4:37 ` Lennart Borgman
2009-11-23 1:34 ` Lennart Borgman
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.