Getting Safari document title/location via Scripting Bridge fails

Question

I'm trying to get the URL and document title from the topmost Safari document/tab. I have an AppleScript and an objective-c version using the Scripting Bridge framework.
Both versions work fine for most web pages, however when I open a Youtube video in full-screen mode, the Scripting Bridge based version fails (error below). The Apple Script works fine for "normal" and full-screen Safari windows.
Can anyone see what is wrong with the Scripting Bridge code below to cause it to fail for full-screen Safari windows?
Here the code (I omitted error checking for brevity):
AppleScript:
tell application "Safari"
# Give us some time to open video in full-screen mode
delay 10
do JavaScript "document.title" in document 0
end tell
Scripting Bridge:
SafariApplication* safari = [SBApplication applicationWithBundleIdentifier:@"com.apple.Safari"];
SBElementArray* windows = [safari windows];
SafariTab* currentTab = [[windows objectAtIndex: 0] currentTab];
// This fails when in full-screen mode:
id result = [safari doJavaScript: @"document.title" in: currentTab];
NSLog(@"title: %@", result);
Scripting Bridge error (with added line breaks):
Apple event returned an error. Event = 'sfri'\'dojs'{
'----':'utxt'("document.title"),
'dcnm':'obj '{ 'want':'prop',
'from':'obj '{ 'want':'cwin',
'from':'null'(),
'form':'indx',
'seld':1 },
'form':'prop',
'seld':'cTab' }
Error info = {
ErrorNumber = -1728;
ErrorOffendingObject = <SBObject @0x175c2de0:
currentTab of SafariWindow 0 of application "Safari" (238)>;
I could not find details about the given error code. It complains about 'currentTab' which shows that the JavaScript event at least made it all the way to Safari. I assume that the current tab receives the event, but refuses to run the JS code, because it is in full-screen mode. However, why does this work for an AppleScript? Don't they use the same code path eventually?
Thanks!
Rico

Answer 1

1) I have not yet looked into Apple events, but have read elsewhere that it is not the most fun thing to deal with. I might give it a shot after having tried 2 + 3
Not really, but your command isn't too complicated so it'd be quite doable using the AEBuild* functions/NSAppleEventDescriptor and AESendMessage. If you go the AEBuild* route, you can use AEDebug to sniff Apple events sent from AppleScript for clues - the AEPrint syntax is similar to that used by AEBuild* functions. Mostly it's just tedious; first learning to use the lower-level APIs, then writing the code for them.
2) Using NSAppleScript was actually my first approach, but having to compile each script before I run it seems a waste. Maybe I can try a pre-compiled script and hand in the JavaScript as a parameter.
That's the safe and efficient way to parameterize AppleScripts. Although unless you're doing this to support user-supplied scripts, by the time you've packed what you need into an NSAppleEventDescriptor, a bit more code and you could probably send it directly to Safari yourself.
3) I had tried ASTranslate in the past. I have not actually compiled the generated code, but seeing this makes me wonder about the difference between the Apple Script and Scripting Bridge.
I've written about that in various places, e.g.:
http://stackoverflow.com/questions/1309958/avoiding-applescript-through-ruby-rb- appscript-or-rubyosa/1316563#1316563
Basically, Apple event IPC is RPC plus first-class queries, not OO as a lot of folks assume. AppleScript's OO-like syntax is a bit of a red herring, and the AS interpreter uses various tricks (e.g. implict gets) to further this illusion. So it looks and feels like OO, but only up to a point, and beyond that folks get totally confused when it does something decidedly un-OO. Hence AppleScript's reputation amongst professional programmers as being confusing and unpredictable. (It's actually reasonably straightforward and predictable one you know how it really works; it's just that figuring it out for yourself takes a lot of time and effort, since it's completely messed with your preconceptions by then. Ugh.)
Apple had an opportunity to learn their lessons from AS's approach, but whether due to politics, hubris or naivety they decided to dress up SB to look even more Cocoa-/OO-like. Which just means there's a bigger impedance mismatch between the SB API and the AE API hidden beneath the surface. So the abstractions are thicker and leakier, and the obfuscations more impenetrable when you do run into problems. By comparison, objc-appscript minimizes the syntactic sugar and wears much of Apple events' inherent weirdness on its sleeve. So while it takes a bit of getting used to if you're from an OO background, once you do get the hang of it it (nearly always) just works.