Bug in Carbon port: browse-url-default-macosx-browser

Bug in Carbon port: browse-url-default-macosx-browser

[David Reitter]

The browse-url functions have a bug on OS X: When a local file is  
browsed (such as during "Preview Buffer" in HTML(-Helper) mode), the  
system will open the file in the application that is the default  
handler for .html files.
Chances are that this default handler is NOT the default browser, but  
an editor such as Emacs itself.

This is actually what happens when you run Emacs on a virgin OS X  
machine: HTML files are not associated with the browser. (Happened to  
me when I installed it on a friend's brand-new iBook).

Here's what the relevant function does:

(defun browse-url-default-macosx-browser (url &optional new-window)
   (interactive (browse-url-interactive-arg "URL: "))
   (start-process (concat "open " url) nil "open" url))

as originally proposed here:
http://groups.google.com/group/gnu.emacs.bug/browse_thread/thread/ 
fdf8b2f1523f9c94/9903ef920ab11af6

Now, the problem is that while "open" is specified to open http://  
URLs in the default browser, it will open "file://" URLs in the  
system's default handler for the particular file, which is usually  
what's associated with the file type of the file, or its extension.

I have spent half the evening researching the correct solution  
(without using Cocoa) and the best I could come up with was this:

(defun browse-url-default-macosx-browser (url &optional new-window)
   (interactive (browse-url-interactive-arg "URL: "))
   (if (not (string-match "file:/*\\(/.*\\)" url))
       (start-process (concat "open " url) nil "open" url)
     (let* ((file (match-string 1 url))
	   (newfile (concat file ".emacs-url")))
     (copy-file file newfile 'overwrite 'keeptime nil 'preserve)
     (mac-set-file-type newfile "HTML")
     (start-process (concat "open " newfile) nil "open" url))))


Not very elegant, and needs to write to the directory where the .html  
file is.
(Needs to do that in order to eliminate the use of any .html standard  
handler. Can't be in /tmp because the browser will interpret all  
embedded URLs (e.g. graphics) as relative to path. Could get around  
by writing a temporary redirection file to /tmp. This is even clunkier.)

Note that something like this won't work:

(do-applescript (format "tell \"browser\"
open location \"%s\"" "file:///Users/dr/Temp/test.html
end tell
"))

doesn't work either - it does the same as "open".
Any solutions involving "tell application Finder" aren't acceptable  
either because the Finder is not defined to be present.

Maybe some of the Mac people here have an idea.

Re: Bug in Carbon port: browse-url-default-macosx-browser

[Stefan Monnier]

> The browse-url functions have a bug on OS X: When a local file is  browsed
> (such as during "Preview Buffer" in HTML(-Helper) mode), the system will
> open the file in the application that is the default  handler for
> .html files.
> Chances are that this default handler is NOT the default browser, but an
> editor such as Emacs itself.

By default .html files are opened in the browser, so if the user changed
this config, I'd expect that he gets what he wants.  I.e. I'm not convinced
it's a bug.


        Stefan

Re: Bug in Carbon port: browse-url-default-macosx-browser

[David Reitter]

On 24 Nov 2005, at 17:23, Stefan Monnier wrote:

>> The browse-url functions have a bug on OS X: When a local file is   
>> browsed
>> (such as during "Preview Buffer" in HTML(-Helper) mode), the  
>> system will
>> open the file in the application that is the default  handler for
>> .html files.
>> Chances are that this default handler is NOT the default browser,  
>> but an
>> editor such as Emacs itself.
>
> By default .html files are opened in the browser, so if the user  
> changed
> this config, I'd expect that he gets what he wants.  I.e. I'm not  
> convinced
> it's a bug.

Two observations:
1. I installed my customized Emacs on a newly installed OSX 10.4.3,  
which defines html as an allowable extension in its Info.plist. This  
could have been Smultron or BBEdit or whatever alternatively.  
LaunchServices seemed to think that this was supposed to be the  
default handler for HTML files now - if you opened them, they're not  
displayed in the browser, but in the editor. When I chose "view  
buffer contents" in html mode, this didn't work as intended.
I've had the same report from a much more seasoned user a while ago,  
and I didn't believe it until I saw it myself.

2. If html files are opened by default in an editor (a perfectly  
sensible configuration!),  there is still a separate setting for the  
default browser. This is what you see in the Preferences of Camino or  
Safari. This is what "open" uses to open http:// URLs with. If you  
change the default browser, this will not change the HTML file handler.
And that is what browse-url should do when browse-url-browser- 
function is set to 'browse-url-default-macosx-browser. And mind you,  
it is this symbol and not something like 'browse-url-default-html- 
file-handler.

"open" is defined to open http:// URLs with the default browser, but  
file:// URLs with the default handler for the specific file type.

Re: Bug in Carbon port: browse-url-default-macosx-browser

[Stefan Monnier]

> 1. I installed my customized Emacs on a newly installed OSX 10.4.3,  which
>    defines html as an allowable extension in its Info.plist. This  could
>    have been Smultron or BBEdit or whatever alternatively.
>    LaunchServices seemed to think that this was supposed to be the  default
>    handler for HTML files now - if you opened them, they're not  displayed
>    in the browser, but in the editor. When I chose "view  buffer contents"
>    in html mode, this didn't work as intended.

I'm not sure I understand correctly.  Are you saying that installing Emacs
causes it to become the default handler for HTML files?  If so, it sounds
like a bug to me.

> And that is what browse-url should do when browse-url-browser-function is
> set to 'browse-url-default-macosx-browser.  And mind you, it is this
> symbol and not something like 'browse-url-default-html-file-handler.

I understand the difference, of course.  I'm just trying to understand why
it's so important: while it's a valid config, it shouldn't be the default.


        Stefan

Re: Bug in Carbon port: browse-url-default-macosx-browser

[David Reitter]

On 24 Nov 2005, at 21:03, Stefan Monnier wrote:

>> 1. I installed my customized Emacs on a newly installed OSX  
>> 10.4.3,  which
>>    defines html as an allowable extension in its Info.plist. This   
>> could
>>    have been Smultron or BBEdit or whatever alternatively.
>>    LaunchServices seemed to think that this was supposed to be  
>> the  default
>>    handler for HTML files now - if you opened them, they're not   
>> displayed
>>    in the browser, but in the editor. When I chose "view  buffer  
>> contents"
>>    in html mode, this didn't work as intended.
>
> I'm not sure I understand correctly.  Are you saying that  
> installing Emacs
> causes it to become the default handler for HTML files?  If so, it  
> sounds
> like a bug to me.

I don't know about Emacs, as I installed Aquamacs Emacs.
But I don't think there is a bug, it's just normal OS X behavior.  
Either way, it's not the bug I'm trying to fix here.

>> And that is what browse-url should do when browse-url-browser- 
>> function is
>> set to 'browse-url-default-macosx-browser.  And mind you, it is this
>> symbol and not something like 'browse-url-default-html-file-handler.
>
> I understand the difference, of course.  I'm just trying to  
> understand why
> it's so important: while it's a valid config, it shouldn't be the  
> default.

Well, I don't know how important it is, but what I do know is that  
out-of-the-box, HTML previewing may silently fail or start up the  
wrong program. I've had people complain, and I've seen it happen  
myself. The reason why it works in most cases is that most people  
have HTML files linked to some browser by default.

The other case where the browser preview will fail completely is when  
the user saves an html-mode buffer to a file with a totally different  
extension, say, .shtml or something with a typo. Then, browse-url  
will definitely open the wrong application!

The bug is due a flaw in the implementation of  browse-url-default- 
macosx-browser. I already said what the mistake is (using "open" to  
open a URL of the form file:// ).

What application is associated with HTML is pretty much up to the  
user. They can set that up in Finder. What the default is is up to  
LaunchServices AFAIK and not a matter of the application side of  
things, so that's nothing I'm worrying about right now.

Re: Bug in Carbon port: browse-url-default-macosx-browser

[Randal L. Schwartz]

>>>>> "David" == David Reitter <david.reitter@gmail.com> writes:

David> I don't know about Emacs, as I installed Aquamacs Emacs.

I think this is your problem.  This must've been added by Aquamacs, as
the standard "mac/Emacs.app" in GNU Emacs CVS contains no such
element in the Info.plist.

Please talk to the Aquamacs people.  And yes, I see that they've added
HTML there. I'd consider that mostly evil.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: Bug in Carbon port: browse-url-default-macosx-browser

[David Reitter]

On 24 Nov 2005, at 22:50, Randal L. Schwartz wrote:

>>>>>> "David" == David Reitter <david.reitter@gmail.com> writes:
>
> David> I don't know about Emacs, as I installed Aquamacs Emacs.
>
> I think this is your problem.  This must've been added by Aquamacs, as
> the standard "mac/Emacs.app" in GNU Emacs CVS contains no such
> element in the Info.plist.
>
> Please talk to the Aquamacs people.  And yes, I see that they've added
> HTML there. I'd consider that mostly evil.

Excuse me: This is a problem that I never complained about. Please  
read my messages.
It's very normal for any OS X program to declare a couple of files it  
can typically open, usually along with supplying icons for these  
files. Nothing evil about that.
But again, this is not the problem at hand and I'm not going to  
discuss this any further.

The problem is that browse-url doesn't do what it advertises: "Ask a  
WWW browser to load url."
And that's the case for the very standard GNU Emacs -Q, easily  
reproducible:

Create an HTML file and save it under the name /tmp/test.tst

then call

(browse-url "file:///tmp/test.test")

(which is what the html-mode "View Buffer"  function does.)

No browser will start.

Re: Bug in Carbon port: browse-url-default-macosx-browser

[Lennart Borgman]

David Reitter wrote:

>
> The problem is that browse-url doesn't do what it advertises: "Ask a  
> WWW browser to load url."
> And that's the case for the very standard GNU Emacs -Q, easily  
> reproducible:
>
> Create an HTML file and save it under the name /tmp/test.tst
>
> then call
>
> (browse-url "file:///tmp/test.test")
>
> (which is what the html-mode "View Buffer"  function does.)
>
> No browser will start.

I think the implementation in Emacs for w32 is of the same type. I 
actually think it is quite practical most of the time. This way Emacs 
behaves as I expect it to on w32. Firefox installed itself so that it 
took care of this. It would not have been possible if Emacs explicitly 
specified the web browser. But maybe things works differently on Mac?

Maybe the doc string should be changed? Perhaps something like:

    Asked OS to give url to associated application (normally a web browser)

Or something better ;-)

Re: Bug in Carbon port: browse-url-default-macosx-browser

[David Reitter]

On 24 Nov 2005, at 23:44, Lennart Borgman wrote:
>
> I think the implementation in Emacs for w32 is of the same type. I  
> actually think it is quite practical most of the time. This way  
> Emacs behaves as I expect it to on w32. Firefox installed itself so  
> that it took care of this. It would not have been possible if Emacs  
> explicitly specified the web browser. But maybe things works  
> differently on Mac?
>
> Maybe the doc string should be changed? Perhaps something like:
>
>    Asked OS to give url to associated application (normally a web  
> browser)

I think the defined functionality is just the right thing. On OS X,  
there is a system-wide browser default, which may or may not coincide  
with the association for .html files. The browser default is what  
should be respected.

Re: Bug in Carbon port: browse-url-default-macosx-browser

[Lennart Borgman]

David Reitter wrote:

> On 24 Nov 2005, at 23:44, Lennart Borgman wrote:
>
>>
>> I think the implementation in Emacs for w32 is of the same type. I  
>> actually think it is quite practical most of the time. This way  
>> Emacs behaves as I expect it to on w32. Firefox installed itself so  
>> that it took care of this. It would not have been possible if Emacs  
>> explicitly specified the web browser. But maybe things works  
>> differently on Mac?
>>
>> Maybe the doc string should be changed? Perhaps something like:
>>
>>    Asked OS to give url to associated application (normally a web  
>> browser)
>
>
> I think the defined functionality is just the right thing. On OS X,  
> there is a system-wide browser default, which may or may not coincide  
> with the association for .html files. The browser default is what  
> should be respected.
>
Thanks, I see. I do not think you can divide between those two things on 
w32 (but I am not absolutely sure about that). Your explanation makes it 
much more easy for me to understand what you want.

Is there then a way for Emacs to use the system-wide browser default?

Re: Bug in Carbon port: browse-url-default-macosx-browser

[David Reitter]

On 25 Nov 2005, at 08:20, Lennart Borgman wrote:

> David Reitter wrote:
>
>> On 24 Nov 2005, at 23:44, Lennart Borgman wrote:
>>
>>>
>>> I think the implementation in Emacs for w32 is of the same type.  
>>> I  actually think it is quite practical most of the time. This  
>>> way  Emacs behaves as I expect it to on w32. Firefox installed  
>>> itself so  that it took care of this. It would not have been  
>>> possible if Emacs  explicitly specified the web browser. But  
>>> maybe things works  differently on Mac?
>>>
>>> Maybe the doc string should be changed? Perhaps something like:
>>>
>>>    Asked OS to give url to associated application (normally a  
>>> web  browser)
>>
>>
>> I think the defined functionality is just the right thing. On OS  
>> X,  there is a system-wide browser default, which may or may not  
>> coincide  with the association for .html files. The browser  
>> default is what  should be respected.
>>
> Thanks, I see. I do not think you can divide between those two  
> things on w32 (but I am not absolutely sure about that). Your  
> explanation makes it much more easy for me to understand what you  
> want.
>
> Is there then a way for Emacs to use the system-wide browser default?


After some research I put together the following patch. It finds the  
appropriate default browser and runs it. Does the job for me.



*** lisp/net/browse-url.el      25 Oct 2005 13:18:52 -0000      1.51
--- lisp/net/browse-url.el      25 Nov 2005 21:07:14 -0000
***************
*** 811,818 ****
       (w32-shell-execute "open" url)))

   (defun browse-url-default-macosx-browser (url &optional new-window)
     (interactive (browse-url-interactive-arg "URL: "))
!   (start-process (concat "open " url) nil "open" url))

   ;; --- Netscape ---

--- 811,820 ----
       (w32-shell-execute "open" url)))

   (defun browse-url-default-macosx-browser (url &optional new-window)
+ "Launch the default browser specified in Mac OS X.
+ NEW-WINDOW is ignored."
     (interactive (browse-url-interactive-arg "URL: "))
!   (mac-launch-URL-with-default-browser url))

   ;; --- Netscape ---




*** src/mac.c	Fri Nov 25 20:45:05 2005
--- src/mac.c	Fri Nov 25 21:06:10 2005
***************
*** 4247,4252 ****
--- 4247,4332 ----
       return Qnil;
   }

+ DEFUN ("mac-launch-URL-with-default-browser",  
Fmac_launch_url_with_default_browser,  
Smac_launch_url_with_default_browser, 1, 1, 0,
+        doc: /* Launch the URL with the system's default browser.
+ Return non-nil if the URL has been successfully launched.*/)
+      (URLstring)
+      Lisp_Object URLstring;
+ {
+   check_mac();
+   CHECK_STRING (URLstring);
+   if (NILP (URLstring))
+     {
+       error ("URL is nil.");
+       return Qnil;
+     }
+
+   BLOCK_INPUT;
+   // get default browser
+ 	
+   FSRef appRef;  // will be discarded
+   LSLaunchURLSpec spec;
+   OSStatus status;
+
+   /* Build URL to find out what the default handler for http is.
+      Without an explicit application reference, the launch function
+      (e.g. LSOpenFromURLSpec or ICLaunchURL) will determine the
+      default file handler for the file, which is not neccessarily the
+      default browser.*/
+ 	
+   char* urlStr = "http://www.gnu.org/"; // just a test URL
+   CFStringRef inURLCfs = CFStringCreateWithCString(NULL, urlStr,	
+ 						   kCFStringEncodingASCII);
+   CFURLRef inURLRef = CFURLCreateWithString(NULL, inURLCfs, NULL);
+ 	
+   /* Get application for opening html pages */
+   status = LSGetApplicationForURL(inURLRef, kLSRolesEditor, &appRef,
+ 				  &spec.appURL);
+   CFRelease(inURLRef);
+   CFRelease(inURLCfs);
+
+   if (status == noErr)
+     {
+       /* Open the file / http with the http handler */
+       CFStringRef targetUrlCfs =
+ 	CFStringCreateWithCString(NULL, SDATA(URLstring),
+ 				  kCFStringEncodingASCII);
+       CFURLRef targetUrlRef = CFURLCreateWithString(NULL,  
targetUrlCfs, NULL);
+ 		
+       if ( (spec.itemURLs =
+ 	    CFArrayCreate(NULL, (const void **)&targetUrlRef, 1,
+ 			  &kCFTypeArrayCallBacks)) == NULL)
+ 	{
+ 	  return Qnil;
+ 	}
+       spec.passThruParams = NULL;
+       spec.launchFlags = kLSLaunchDefaults;
+       spec.asyncRefCon = NULL;
+       status = LSOpenFromURLSpec(&spec, NULL);
+ 		
+       CFRelease(spec.itemURLs);
+       CFRelease(targetUrlRef);
+       CFRelease(targetUrlCfs);
+       UNBLOCK_INPUT;
+
+       if (status != noErr)
+ 	{
+ 	  error("Failed to launch default browser.");
+ 	  return Qnil;
+ 	}
+     }
+   else
+     {
+       UNBLOCK_INPUT;
+       error("Could not determine default browser.");
+       return Qnil;
+     }
+
+
+   return Qt;
+ }
+
+

   #ifdef MAC_OSX
   #undef select
***************
*** 4692,4698 ****
     defsubr (&Smac_code_convert_string);
   #endif
     defsubr (&Smac_clear_font_name_table);
!
     defsubr (&Smac_set_file_creator);
     defsubr (&Smac_set_file_type);
     defsubr (&Smac_get_file_creator);
--- 4772,4779 ----
     defsubr (&Smac_code_convert_string);
   #endif
     defsubr (&Smac_clear_font_name_table);
!
!   defsubr (&Smac_launch_url_with_default_browser);
     defsubr (&Smac_set_file_creator);
     defsubr (&Smac_set_file_type);
     defsubr (&Smac_get_file_creator);

Re: Bug in Carbon port: browse-url-default-macosx-browser

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 25 Nov 2005 21:29:49 +0000, David Reitter <david.reitter@gmail.com> said:

> After some research I put together the following patch. It finds the
> appropriate default browser and runs it. Does the job for me.

I think the function `Fmac_launch_url_with_default_browser' is rather
specific.  How about just making a wrapper function for
LSGetApplicationForURL at the C level, and doing the rest of work at
the Lisp level?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Bug in Carbon port: browse-url-default-macosx-browser

[David Reitter]

On 28 Nov 2005, at 02:32, YAMAMOTO Mitsuharu wrote:

>>>>>> On Fri, 25 Nov 2005 21:29:49 +0000, David Reitter  
>>>>>> <david.reitter@gmail.com> said:
>
>> After some research I put together the following patch. It finds the
>> appropriate default browser and runs it. Does the job for me.
>
> I think the function `Fmac_launch_url_with_default_browser' is rather
> specific.  How about just making a wrapper function for
> LSGetApplicationForURL at the C level, and doing the rest of work at
> the Lisp level?

Sure, but then you'll need to offer some functions to deal with with  
app URL itself.  I don't know if start-process is the right /  
documented thing to do in this case (even though it'll probably work).

But most importantly, I have a number of bugs to deal with these days  
(mostly in my own libraries) and would like to work on that before  
introducing new mac-specific features in the Carbon port.

Re: Bug in Carbon port: browse-url-default-macosx-browser

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 28 Nov 2005 09:12:15 +0000, David Reitter <david.reitter@gmail.com> said:

> Sure, but then you'll need to offer some functions to deal with with
> app URL itself.

I think you can obtain the app file name from an FSRef value (appRef
in your code) using FSRefMakePath.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp