From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lennart Borgman Newsgroups: gmane.emacs.bugs Subject: bug#4951: 23.1.50; browse-url-default-windows-browser bug + patch Date: Thu, 19 Nov 2009 05:37:05 +0100 Message-ID: References: <4B038C0D.8020707@f2s.com> Reply-To: Lennart Borgman , 4951@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1258606065 31967 80.91.229.12 (19 Nov 2009 04:47:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 19 Nov 2009 04:47:45 +0000 (UTC) Cc: 4951@emacsbugs.donarmstrong.com To: Jason Rumney Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Nov 19 05:47:37 2009 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NAyve-00017y-Qn for geb-bug-gnu-emacs@m.gmane.org; Thu, 19 Nov 2009 05:47:35 +0100 Original-Received: from localhost ([127.0.0.1]:59671 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NAyvd-0007nJ-S5 for geb-bug-gnu-emacs@m.gmane.org; Wed, 18 Nov 2009 23:47:33 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NAyvZ-0007mu-DV for bug-gnu-emacs@gnu.org; Wed, 18 Nov 2009 23:47:29 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NAyvV-0007kk-2z for bug-gnu-emacs@gnu.org; Wed, 18 Nov 2009 23:47:28 -0500 Original-Received: from [199.232.76.173] (port=32976 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NAyvU-0007kg-No for bug-gnu-emacs@gnu.org; Wed, 18 Nov 2009 23:47:24 -0500 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:50896) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NAyvT-0003ak-NY for bug-gnu-emacs@gnu.org; Wed, 18 Nov 2009 23:47:24 -0500 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id nAJ4lKPU015241; Wed, 18 Nov 2009 20:47:21 -0800 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id nAJ4j7cX014993; Wed, 18 Nov 2009 20:45:07 -0800 Resent-Date: Wed, 18 Nov 2009 20:45:07 -0800 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: Lennart Borgman Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Thu, 19 Nov 2009 04:45:06 +0000 Resent-Message-ID: Resent-Sender: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: followup 4951 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 4951-submit@emacsbugs.donarmstrong.com id=B4951.125860545514285 (code B ref 4951); Thu, 19 Nov 2009 04:45:06 +0000 Original-Received: (at 4951) by emacsbugs.donarmstrong.com; 19 Nov 2009 04:37:35 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from mail-yw0-f179.google.com (mail-yw0-f179.google.com [209.85.211.179]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id nAJ4bYXJ014282 for <4951@emacsbugs.donarmstrong.com>; Wed, 18 Nov 2009 20:37:35 -0800 Original-Received: by ywh9 with SMTP id 9so1732794ywh.19 for <4951@emacsbugs.donarmstrong.com>; Wed, 18 Nov 2009 20:37:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=sRXs+B770NX2em6dHuWd4HPuR2EbptcyzCgPX3SfaWQ=; b=lvMcHbJkrvIsrDl+019UEqHuEXJWwjgzlQXrxy7X6QoUEMsxp3SpKtKnFTMH03do9o G9IwI0nlWSK1cQIPmkakiD+qX7bP5TpwdCArZ33Jbby6PThXSGDGyX0HZ1MrXiSv9jKL jHroWPgBsSYwPvgyH5pySSjIVHpRjxyUsDGVQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=fl65E+Azj/hloJhaoaUJ/yVBsExWXPNBuRCqY43lnbGy7AsSm+WJfOwmzzciuT3xKg fnug8SB5mhZ1ZelvYqEYLVlYwQbAAMJsyC5Uqkf3RZpb3qCpizEVUv4bMmeU7+bTr5jh BnEtc/Js99Gvni+i7tSZ9oEGJVB9Squ14yolA= Original-Received: by 10.101.149.3 with SMTP id b3mr3447086ano.115.1258605445068; Wed, 18 Nov 2009 20:37:25 -0800 (PST) In-Reply-To: X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Resent-Date: Wed, 18 Nov 2009 23:47:28 -0500 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:32696 Archived-At: On Wed, Nov 18, 2009 at 2:00 PM, Lennart Borgman wrote: > On Wed, Nov 18, 2009 at 6:54 AM, Jason Rumney wrote: >> Lennart Borgman wrote: >>> >>> On Wed, Nov 18, 2009 at 4:35 AM, Stefan Monnier >>> wrote: >>> >>>>> >>>>> browse-url-default-windows-browser does not work any longer. =C2=A0I = am >>>>> unsure when it stopped working, but on at least Windows XP the >>>>> attached patch seems necessary. =C2=A0Could we please apply this as s= oon as >>>>> possible so it will get tested? >>>>> >>>> >>>> Could you explain why it's necessary? =C2=A0I mean I understand you sa= y that >>>> the current doesn't work, but I'd like to understand why it doesn't wo= rk. >>>> >>> >>> No, I do not understand why it is necessary ... ;-) >>> >>> There are two changes: >>> >>> 1) file: =3D> 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 ar= e >> 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 speci= fied >> 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 th= e >> same code is used on all platforms, then the former works, while the lat= ter >> does not (too many / when combined with posix paths). =C2=A0But as this = is now in >> a (windows-nt msdos cygwin) conditional, that is not really important, a= nd >> 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 v= erb >> for opening files, and should avoid the security problems associated wit= h >> 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: > > =C2=A0(w32-shell-execute "open" "c:/some/file.html") ;; OK > =C2=A0(w32-shell-execute nil "file:c:/some/file.html") ;; OK > =C2=A0(w32-shell-execute nil "file:///c:/some/file.html") ;; OK > =C2=A0(w32-shell-execute "open" "file:///c:/some/file.html") ;; Doesn't w= ork > =C2=A0(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"=3D"" @=3D"URL:File Protocol" "Source Filter"=3D"{E436EBB6-524F-11CE-9F53-0020AF0BA770}" [HKEY_CLASSES_ROOT\file\CLSID] @=3D"{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.