EasySIMBL stopped working on 10.10.4 b4

[antons]

Just restarted to 10.10.4 b4 and noticed that EasySIMBL stopped working. All checkboxes are enabled, but the plugins are not injected into apps.

[norio-nomura]

It seems OS X 10.10.4 b4 (14E26a) has restricted API that EasySIMBL (and original SIML) depend on with some undocumented conditions.

2015/05/27 12:57:34.421 com.github.norio-nomura.SIMBL-Agent[41695]: AppleEvents: Send port for process has no send right, port=( port:32047/0x7d2f rcv:1,send:0,d:0 limit:5) (findOrCreate()/AEMachUtils.cp #526) com.apple.main-thread

[d235j]

This warning appeared on previous 10.10 versions. So I doubt this is why it fails.

[norio-nomura]

I have been taught that the log is appearing also on OS X 10.10.3.
It seems silently failed injecting on OS X 10.10.4 (14E26a)
EasySIMBL has ever stopped working while OS X 10.9 Preview as #4, but it works again until final release.

[d235j]

This is a weird one. TotalFinder's injector (source at https://github.com/binaryage/totalfinder-osax) still works, as does FinderPop's (finderpop.com), Default Folder X, Bartender.

This log message does seem related, but doesn't give enough information to be of use.

Apple also changed other major stuff in this 10.10.4 beta — discoveryd was removed and replaced with the older mDNSResponder.

[d235j]

If I make a standalone AppleScript application that sends the appropriate Apple Event to the desired application, the bundles get loaded. Therefore this is a bug in the EasySIMBL Agent.

[norio-nomura]

@d235j Thanks. I'll investigate.

[norio-nomura]

I tested injecting EasySIMBL.osax by using AppleScript as following:

tell application "Safari" to «event ESIMload»

got same errors on both OS X 10.10.3 and OS X 10.10.4 as following:

tell application "Safari"
    «event ESIMload»
        --> error number -1708
    «event ascrgdut»
        --> error number -1708
    «event ESIMload»
        --> error number -10004
end tell
tell current application
    «event ESIMload»
end tell

It works on OS X 10.10.3 (14D131), and not on OS X 10.10.4 (14E26a) 😕

[d235j]

I also had to change Context: User to Context: Process in the OSAX Info.plist. It works if I send the event using Script Editor, after doing this. If I create an .app of the script, it does require a password. This is probably because this is cross-app scripting.
Other injectors (such as FinderPop and the others I mentioned) use Context: Process in the OSAX. They do not require a password.

[norio-nomura]

@d235j Thank you for explanation,
After editing Info.plist of EasySIMBL.osax 0.10.10 (bundled into EasySIMBL-1.7.1) and re-codesign it, I got works by AppleScript.

[ylluminate]

So glad to see this guys, thanks for your effort on this! This was a real headache for me today.

Are you releasing a packaged fix soon for this changed over to Context: Process @norio-nomura?

[orbitly]

Any word on when the fix will be released?

[norio-nomura]

Referring information about TotalFinder, I have tried fix. But I have not yet success EasySIMBL working on OS X 10.10.4 (14E26a). 😞

[ylluminate]

Have we asked the BinaryAge guys for input / help? @darwin @sdsykes

[sdsykes]

Don't know why the problem has arisen. You might try using the AESendMessage API rather than SBApplication to send the events.

[darwin]

ScriptingAdditions are fragile.

AFAIK, OSAX bundles should reside in /Library/ScriptingAdditions (probably installed by root/admin) to be first-class citizens with full rights to be injected in all bundles in /Applications. Having them in ~/Library/ScriptingAdditions sometimes works, but I had issues that sometimes the system prevents apple events because of "no send right". I don't remember the details, but I would assume system-level OSAXes can be injected into anything. And user-level OSAXes can be injected only into user-level processes. The exact rules are unknown to me but it is possible Apple made some changes of this mechanism in 10.10.4 (14E26a).

Also one thing which burned me during development is that OSAX bundles are being actively scanned for on the whole filesystem using Spotlight or something like that. So if you have some broken OSAX lying somewhere then scripting additions could pick it up and try inject it instead of good OSAX in Library/ScriptingAdditions folders. So for example installer should not unpack OSAX somewhere into a temp folder and copy it later to the destination. This could confuse the system in rare cases.

In TotalFinder I had a lot of problems related to failed OSAX injections. I decided not to use hihg-level applescript, but send events using AESendMessage, it boils down to:
https://gist.github.com/darwin/72be854b54c590d05958

Some dev notes:
https://github.com/binaryage/totalfinder-osax/blob/280930f6e3dc96602d31b281a61104da773f2fed/TotalFinderInjector.m#L21-L65

[norio-nomura]

@sdsykes @darwin Thanks for informations,
I will try using AESendMessage as first step.

[d235j]

@darwin @norio-nomura It seems that putting the OSAX in ~/Library/Scripting Additions is not the problem since using an AppleScript Editor created application to send the Apple Event still works. This is probably due to how SBApplication is being used.

[norio-nomura]

I have tested using AESendMessage without SBApplication. It works on OS X 10.10.3 and does not work on OS X 10.10.4 (14E26a).
Is it needed to change bundle structures for placing OSAX in /Library/ScriptingAdditions? 😒

[antons]

@norio-nomura In my (limited) testing, that is the only location that worked.

[antons]

EasySIMBL doesn’t work on El Capitan too, as far as I can see.

[orbitly]

I can report the same, 10.11 (15A178w)

[w0lfschild]

Are you sure about that? It's definitely working for me. Granted not all bundles are working with the new apps (cDock, colorfulsidebar). I believe some apps have moved to swift because I can't class dump the dock executable anymore.

[orbitly]

Neither Flashlight nor Safari Stand work.

[w0lfschild]

That's doesn't mean that simbl isn't working though...

NotificationClear and RadonChrome are both 100% working on 10.11 via easySIMBL.

[antons]

@w0lfschild You’re right, some plugins work. However, I have an app and a plugin that have not changed since 10.10, and yet they fail to load.

09.06.15 16:06:43,511 Gitbox[14462]: Error loading /Users/Anton/Library/ScriptingAdditions/EasySIMBL.osax/Contents/MacOS/EasySIMBL:  dlopen(/Users/Anton/Library/ScriptingAdditions/EasySIMBL.osax/Contents/MacOS/EasySIMBL, 262): no suitable image found.  Did find:
    /Users/Anton/Library/ScriptingAdditions/EasySIMBL.osax/Contents/MacOS/EasySIMBL: open() failed with errno=24

[norio-nomura]

@d235j No, I didn't change Info.plist both of testing on 10.10.4 b4 and 10.11.

[d235j]

@norio-nomura can you try that together with /Library/ScriptingAdditions? (You also have to remove EasySIMBL.osax from ~/Library/ScriptingAdditions or it will attempt to use that copy and fail.) I could not get it to work at all until I made this change, even with manual injection with an AppleScript, but it seems to work when set up that way on 10.10.4 at least.

[norio-nomura]

@d235j I'm using original SIMBL-0.9.9 on my testing. Because EasySIMBL has some unnecessary functions for placing at /Library/ScriptingAdditions.

[d235j]

@norio-nomura: I also had to delete EasySIMBL.osax from ~/Library/ScriptingAdditions.
I'll summarize what it took to make it work:

1. Modify the Info.plist as described above.
2. Install and turn on EasySIMBL as usual.
3. Quit the EasySIMBL app.
4. Copy EasySIMBL.osax to /Library/ScriptingAdditions.
5. Delete EasySIMBL from ~/Library/ScriptingAdditions.
6. Observe that it functions. If something puts it back in ~/Library/ScriptingAdditions, it will stop functioning.

the aforementioned AEDebugSends and AEDebugReceives environment variables are useful for testing.

[norio-nomura]

@d235j SIMBL Agent.app copies EasySIMBL.osax to ~/Library/ScriptingAdditions before sending apple events. If target app is sandboxed, it also copies .osax and plugins into their container.
Placing at /Library/ScriptingAdditions make those functions are unnecessary.

[d235j]

@norio-nomura Yeah, understood. I don't know if it still works if the target is sandboxed, though.
Having the app to be able to turn SIMBL plugins on and off is handy, by the way.

[sambuev]

Can you update EasySimbl to newer version where everything is works under 10.10.4? please

[inket]

@sambuev It's pointless. It's a lot of work for no benefit (besides the plugins management GUI) because SIMBL already works.

And it's even less useful because 10.11 breaks both EasySIMBL and SIMBL without huge workarounds.

[norio-nomura]

I wrote a note about injection mechanism of EasySIMBL extended from SIMBL-0.9.9
https://gist.github.com/norio-nomura/f4346e9cb9db0a411779

[violinday]

Not working for me as well.

[norio-nomura]

How to transition from EasySIMBL to SIMBL by hetima

[gkarag]

@norio-nomura Hello and thanks for your support. I followed the advice of hetima and now I have SafariStand working. One thing has caught my attention though, in the console I get these:

04.07.2015 02:30:49.992 Safari[539]: Performance: Please update this scripting addition to supply a value for ThreadSafe for each event handler: "/Library/ScriptingAdditions/SIMBL.osax"

My question is should I be concerned about that and is there a rather easy way to fix it?

[norio-nomura]

@gkarag The message means SIMBL(and plugins loaded by that) will be initialized on main thread that drives UI. If those behavior affect you, you will see some UI freeze or beachball cursor on loading plugins. I don't know such plugins are exists or not.

[Sufl]

I have just created an account in order to say THANK YOU to norio-nomura for her information and effort above on How to transition from EasySIMBL to SIMBL by hetima because it allowed me to get the colourful sidebar back.

I was distraught when it disappeared with Yosemite 10.10.4 and I read the various threads on this with desperation because it was awful to lose my beautiful sidebar when EasySIMBL no longer worked. Now thankfully I have it back and I want to say thank you very much for the work and effort that it has taken so that people can enjoy the lovely colourful sidebar again. I am now very happy again.

Cheers.

[thekrynn]

SIMBL stopped working for me as well on 10.10.4. Tried the EasySIMBL to SIMBL, and no luck, although maybe it has to do with the fact that I am trying to use the TheLostFinderNewWindow, which I use on all my machines. Here's what I'm seeing when my machine reboots:

Jul 12 02:06:49 macbookpro2 com.apple.xpc.launchd1: Please switch away from OnDemand to KeepAlive.

Jul 12 02:06:49 macbookpro2 com.apple.xpc.launchd1: Could not import service from caller: caller = otherbsd.238, service = com.github.norio-nomura.SIMBL-Agent, error = 119: Service is disabled

Jul 12 02:06:49 macbookpro2.w.21.intranet otherbsd[238]: Could not submit LoginItem job com.github.norio-nomura.SIMBL-Agent: 119: Service is disabled

[norio-nomura]

@thekrynn For injecting plugins into Finder using SIMBL-0.9.9, you need doing additional steps.

Injecting SIMBL to Finder by using Apple Script

Basic instructions:

1. Open Script Editor.app
2. Open new script by using menu File > New or hitting ⌘N
3. Paste tell application "Finder" to inject SIMBL into Snow Leopard to the script.
4. Run the script by using menu Script > Run or hitting ⌘R
   

If your plugin works with above steps, let’s make your injector app with following steps:

1. Using menu File > Export…
2. Input inject SIMBL to Finder into Export As: field
3. Select Application on File Format: field
4. Click Save

Now you can register your inject SIMBL to Finder.app to launch on your login as following:

This method may work with another plugins for another apps.

[tkoyn]

thekrynn, Did you find any way to workaround this to get TheLostFinderNewWindow to work again?

norio-nomura, Are you planning on developing a replacement or update for EasySIMBL?

Thanks

[thekrynn]

Was working perfectly with 10.10.4 (3 different machines) using the applescript app approach (even with manually double clicking). However, the error below occurs on 10.11 DP3. Confirmed that it is working on my machines still with 10.10.4 using applescript with the attached code.

Also, tried it as root from shell:
sh-3.2# osascript -e 'tell application "Finder" to inject SIMBL into Snow Leopard'
29:59: execution error: Finder got an error: A privilege violation occurred. (-10004)

[thekrynn]

The following article works just fine with TheLostFinderNewWindow in 10.11. Rebooting in recovery mode and disabling the new security option does the trick. While it's supposed to be for our protection, I hate to say that not being able to open a window with a traditional double click is too much of an inconvenience.

http://blog.binaryage.com/el-capitan-update/

Anyone who might need help getting TLFNW to work, feel free emailing me at alex at truoptik dot com.
Kudos to norio-nomura for making all this possible.

[norio-nomura]

@thekrynn I wrote about OS X 10.11 (15A204h) on #26 (comment). I don't test yet on newer build.

[yuchenlin]

It doesn't work on 10.10.5 as well.

[tkoyn]

Yuchelin, Exactly what and how did you test? The post 2 posts above yours reported a way to get Lost Finder New Window to work in 10.11.

It doesn't work on 10.10.5 as well.

—
Reply to this email directly or view it on GitHub.

[ashishb]

Working on 10.10.5 for me using norio-nomura's apple script

[Gunny123]

So TypeStatus for Mac 1.0 does not work any longer? Or do I use another method mentioned above?

[vhristev]

I make it work on 10.10.5 but its buggy ....

1. Open spotlight everything is working with FlashLight but after couple of searches it crash.
2. Open spotlight again and there is no FlashLight plugins
3. Initiate again the norio-nomura apple script
4. Everything is back to normal
5. Open spotlight and start searching .... it crash randomly so its kind of random loop if its going to work on not