[OS X Emacs] Delay opening HTML files from a shell

[Win Treese]

Here’s an experiment I did:

1. Create a file called /tmp/foo.html with the text “hello”
2. Run “open /tmp/foo.html” in the Terminal -> opens immediately in Safari
3. Run Aquamacs 3.4 distributed release version (which is signed)
    a. run M-x shell
    b. run “open /tmp/foo.html” in the shell inside Aquamacs
    -> opens immediately in Safari
4. Run Aquamacs nightly build
    a. run M-x shell
    b. run “open /tmp/foo.html” in the shell inside Aquamacs
    -> opens after a noticeable delay in Safari

While I was doing the experiments, I watched the logs in the Console.app. In #4, there is a lot of chatter about the trust subsystem. The messages are mysterious, but suggests that the trust subsystem is having a minor freakout over access privileges, after which it lets things go ahead anyway.

It’s hard to tell what’s going on, or what Apple’s intent for this scenario is. But it seems pretty clear that this is what’s causing the performance problem.

The simplest answer would be to use a signed binary, and I hope we’ll have one with the TLS changes in available soon.

 - Win

> On Jul 16, 2019, at 9:59 AM, Braun, Michael <braunm at mail.smu.edu> wrote:
> 
> Thanks.  I can confirm this behavior on my computer as well.  The release version ran as it should.  The nightly build behaved as it should when run as a binary from the Terminal, but not when launched through the GUI.
> 
> 
> I did run into the following issues, however.
> 
> 1.  When running the app directly from Terminal, Aquamacs was looking for libTIFF.dylib, libJPEG.dylib and libPng.dylib in /usr/local/lib.  Those files were not there, but among the System files.  Once I added symlinks, the application was able to launch, and files would open instantly, as they should. But this did not solve the problem when launching from the GUI.
> 
> 2.  Even though the app does launch and run from the Terminal, I got the following error 
> 
> mbraun: ~/Downloads $ ./Aquamacs.app/Contents/MacOS/Aquamacs 
> 2019-07-16 08:50:15.131 Aquamacs[25407:8580522] Failed to initialize color list unarchiver: Error Domain=NSCocoaErrorDomain Code=4864 "*** -[NSKeyedUnarchiver _initForReadingFromData:error:throwLegacyExceptions:]: non-keyed archive cannot be decoded by NSKeyedUnarchiver" UserInfo={NSDebugDescription=*** -[NSKeyedUnarchiver _initForReadingFromData:error:throwLegacyExceptions:]: non-keyed archive cannot be decoded by NSKeyedUnarchiver}
> 
> It didn’t seem to affect running of the app, at least in my short test.  But maybe that’s relevant.
> 
> 3.  As stated earlier in this thread, I cannot build Aquamacs on my own at the moment.  Also, I do not do much developing, so I’m not sure what’s involved in signing an application.  So unfortunately I cannot test that.
> 
> But it does appear that seeing if signing the nightly build would be the next step in debugging this.
> 
> 
> 
> 
> 
>> On Jul 15, 2019, at 9:07 PM, Jamie Taylor <Jamie.Taylor at pobox.com> wrote:
>> 
>> I attempted to send this a month ago, but the list mail server rejected it, and I didn't get around to sending it again from a different source.  I'd be interested to know if any of this helps.
>> 
>>  ----
>> 
>> Some googling and brief experimentation has lead me to believe
>> that this behavior is related to the code signature (or the lack
>> thereof) on the application.  Specifically, I observed the
>> following three data points:
>> 
>> The current released version of Aquamacs, which is signed, does
>> not exhibit this behavior.
>> 
>> A nightly that I happened to have lying around (2018-02-23), which
>> is not signed, does exhibit the slow "open" command behavior.
>> 
>> However, if that same nightly is opened by running its binary
>> directly rather than opening it as normal (i.e., running
>> $  ~/Desktop/Aquamacs\ 2018-02-23\ nightly.app/Contents/MacOS/Aquamacs
>> rather than double-clicking its icon), everything is speedy again.
>> 
>> So my hypothesis is that if you either a) sign the app bundle that you
>> built, or b) launch it by running the binary from the terminal rather
>> than opening the app bundle, then you will get your speedy "open"
>> behavior back.
>> 
>> 
>> If anyone wants to go down the rabbit hole of trying to figure out
>> why it works this way, here are a couple of search terms and links that
>> might be of interest:  Mojave TCC, Attribution Chain
>> https://github.com/macvim-dev/macvim/issues/763
>> https://eclecticlight.co/2019/02/01/solving-problems-with-mojaves-privacy-protection/ (the most interesting bits are in the comment thread)
>> 
>> 
>> _____________________________________________________________
>> MacOSX-Emacs mailing list
>> MacOSX-Emacs at email.esm.psu.edu
>> https://email.esm.psu.edu/mailman/listinfo/macosx-emacs
>> List Archives: http://dir.gmane.org/gmane.emacs.macintosh.osx
> 
> 
> _____________________________________________________________
> MacOSX-Emacs mailing list
> MacOSX-Emacs at email.esm.psu.edu
> https://email.esm.psu.edu/mailman/listinfo/macosx-emacs
> List Archives: http://dir.gmane.org/gmane.emacs.macintosh.osx