Service written in SL now errs in ML

Hi, I wrote a small clipping service in OS 10.6.8 that worked fine (code below). The AS code runs fine outside Automator and worked as a service in that OS. Since moving to OS 10.8.3 (now .4), the service still works but stops throws a “Choose Application” dialog asking “Where is WorkflowServiceRunner.xpc?”. If I cancel the dialog the service completes correctly in terms of pasting the data but the point of the service is lost.

I’ve a hunch this is a by-blow of new sandboxing security. Apple docs have no mention of WorkflowServiceRunner and Google throws up nothing useful. Any Ideas?

Below is the only action in the service. The try block wasn’t in the original script and added as part of testing in 10.8.4. It doesn’t help as the issue isn’t the error dilaog at the end but the pointless “Where’s WorkflowServiceRunner” dialog!

on run {input}
	try
		set currApp to name of current application
		set the clipboard to input as Unicode text
		activate application "Tinderbox"
		if (count of documents of application "Tinderbox") is equal to 0 then
			tell application "System Events"
				tell process "Tinderbox"
					-- no document so make new one
					keystroke "n" using command down
					-- short delay needed or paste action fires too soon
					delay 0.25
				end tell
			end tell
		end if
		tell application "System Events"
			tell process "Tinderbox"
				tell window 1
					-- in case target is a text window, send Cmd+Down-Arrow
					-- in order to move cursor to end of $Text
					-- (Note: has no effect in TB's major views)
					key code 125 using command down
					-- paste clipboard contents
					keystroke "v" using command down
				end tell
			end tell
		end tell
		activate application currApp
	on error errmsg
		display dialog "Error while executing service:" & errmsg buttons {"Close"}
	end try
end run

FWIW, the script’s target app doesn’t have an AS dictionary. It doesn’t matter as the basic process works outside the service. I just mention this lest someone suggests a method requiring the target app be more AS-sciptable.

Model: Spring 2011 Unibody MBPro
AppleScript: 2.2.4
Browser: Safari 536.30.1
Operating System: Mac OS X (10.8)

After posting the above, I did a wider search in Terminal and found this:

/System/Library/Frameworks/AppKit.framework/Versions/C/XPCServices/WorkflowServiceRunner.xpc

In the Chooser dialog thrown by my service I can Navigate to the above . but not select it, which looks like a bug somewhere under the OS hood.

Maybe you can make it work, by either using System UI Server for current applicaton, or write a dedicated applet to send messages to (call up handlers from.

Maybe the easiest thing would be to have your service, just call a background application, that takes care of everything?

I know this isn’t much help, but it may work to circumwent the problem.

Thanks, although I think the suggestion takes me beyond my limited under-the-hood knowledge! I assume it also points to this being old functionality (unintentionally?) broken by Apple post-Lion sandboxing. The service above was made by me for others (I don’t actually have a need for it) who wanted a simple ‘clip-to’ service for the targeted app. It sounds like this is a task better done by the app’s author (in Xcode or wherever) than by user scripting. Sad, yet more useful functionality thrown under the bus by OS changes.

Bottom line seems to be this pathway is broken (at least if using Automator and not coding in Objective-C or such) or am I wrong?

I’d mail the Producer with your problem, and maybe a reference to this thread.

On a general basis, I prefer security over functionality. Most of the time, you’ll find another way of doing something, while you retain the security.

As the user base grows on mac, the number of dirt-bags will also do so, inevitably, unfortunately. And if we don’t increase the security, then we may end up with windoze conditions.

Understood. However, the extra functionality is non-core to the app which has better calls on its dev spend. I was simply trying to help the small band who are militant about always wanting to write to any app but the one they are currently using! I think the answer is for them use something like Keyboard Maestro or Alfred that (I presume) act as the ‘app’ necessary to fill the security problem the old services now create. Only downside is needing yet another app and not being free.

Quite take the point about not letting naughty rascals do bad things. Thanks again, I’d feared this question might garner no answers.

Hi,

there is a common misunderstanding

current application is always the AppleScript runner environment the script is running in,
but not the frontmost application.

Better write


tell application "System Events" to set activeApplication to bundle identifier of 1st process whose frontmost is true
--
activate application "somethingElse"
doStuff()
--
activate application id activeApplication


Happiness :). It works! Hard to diagnose without the knowledge. For others like me who are inexpert with AS the fix was to change two lines (the first and last lines of the main try block. It is now:

on run {input}
	try
		tell application "System Events" to set activeApplication to bundle identifier of 1st process whose frontmost is true
		set the clipboard to input as Unicode text
		activate application "Tinderbox"
		if (count of documents of application "Tinderbox") is equal to 0 then
			tell application "System Events"
				tell process "Tinderbox"
					-- no document so make new one
					keystroke "n" using command down
					-- short delay needed or paste action fires too soon
					delay 0.25
				end tell
			end tell
		end if
		tell application "System Events"
			tell process "Tinderbox"
				tell window 1
					-- in case target is a text window, send Cmd+Down-Arrow
					-- in order to move cursor to end of $Text
					-- (Note: has no effect in TB's major views)
					key code 125 using command down
					-- paste clipboard contents
					keystroke "v" using command down
				end tell
			end tell
		end tell
		activate application id activeApplication
	on error errmsg
		--display dialog "Error while executing service:" & errmsg buttons {"Close"}
	end try
end run

Basically, I used StefanK’s opening/closing lines of code to replace my two that used ‘currApp’. All now works though interestingly with the new code, if the service is run while the workflow is open in automator, you can’t then save any changes. You need to close the file in Automator before using the service. Not sure why the change although Automator moaned about something else having altered the file and versioning. Whatever, saving closing before tasting changes seems to work OK.

Sidenote: this is just the sort of workflow configuration issue that I feel a tool like Automator ought to help make clearer - it’s not a guessable fact and Apple make both AppleScript and Automator.

Edit:

: What I mean is that a Help article somewhere flagging up that a likely cause of a service asking “Where is WorkflowServiceRunner.xpc?” is becasue the script author has guessed incorrectly the actual context of ‘current application’ in a script run in a service. Oh well, perhaps the Google will now find this thread!

Still, I’m very happy that this now works and thanks to the exports for their help.

I don’t think I can edit my older post but perhaps must eat my words about broken functionality and admit to user error. :frowning: