<AWT Dev> com.apple.eawt.Application.setOpenURIHandler does not deliver initial launch URI

[James Tomson]

Hi Anthony,

Thanks for taking a look. To answer your questions, the
application:openFiles and application:printFiles methods should not need
similar special treatment - the passed instances should be getting
implicitly retained and released by the block from my understanding, and
can be queued for later processing without a problem. Testing locally with
those handlers, the OpenFilesEvent and PrintFilesEvent events on the
java-side are delivered without issue when the app is launched from an open
file or print file event from the Finder.

The issue with the passed NSAppleEventDescriptors is that while the objects
are properly retained and released by the block, the Apple Event Handling
system seems to be marking the instance's internal state as otherwise
invalid/expired even though the instance itself is still retained. I'm
unable to find any specific documentation or discussion about the lifecycle
of these event descriptor objects though.

-James


On Fri, May 24, 2013 at 12:13 PM, Anthony Petrov
<anthony.petrov at oracle.com>wrote:

> Hi James,
>
> I like your patch.
>
> Do you know if other handlers are affected by a similar issue? In
> particular, the application:openFiles and application:printFiles also take
> references to NSObjects as their arguments. Could you please test if these
> handlers are affected or not?
>
> --
> best regards,
> Anthony
>
>
> On 05/23/2013 10:56 PM, James Tomson wrote:
>
>> Hi - this issue was originally discussed on the jdk7u-dev list here:
>> http://mail.openjdk.java.net/**pipermail/jdk7u-dev/2013-May/**006446.html<http://mail.openjdk.java.net/pipermail/jdk7u-dev/2013-May/006446.html>
>>
>> Additionally a report should be available soon in the bug database as
>> (JDK-8015302)
>> http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=8015302<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8015302>
>>
>> To summarize, a bundled mac application which registers custom url
>> schemes via the CFBundleURLSchemes entry in its Info.plist, and listens
>> for uri events using com.apple.eawt.Application.**setOpenURIHandler, will
>> not receive the URI used to launch the application.
>>
>> Once the application is running however, subsequent openURI events will
>> be delivered without issue. The problem only manifests with the URI is
>> used to launch the App initially.
>>
>> When the app is opened via URI, the following appears in the system log:
>>
>> ----------
>> JavaAppLauncher[74278]: -[NSAppleEventDescriptor
>> paramDescriptorForKeyword:] called on invalid NSAppleEventDescriptor
>> ----------
>>
>> It appears that since the QueueingApplicationDelegate is only keeping
>> references to those descriptor objects instead of making deep copies of
>> them,
>> the event descriptor for the initial URI that launches the app is
>> invalidated by the time the app actually gets around to processing it.
>>
>> The following patch (same for both jdk8 and jdk7u sources) seems to
>> resolve the issue:
>>
>> ----
>> diff --git a/src/macosx/native/sun/**osxapp/**
>> QueuingApplicationDelegate.m
>> b/src/macosx/native/sun/**osxapp/**QueuingApplicationDelegate.m
>> --- a/src/macosx/native/sun/**osxapp/**QueuingApplicationDelegate.m
>> +++ b/src/macosx/native/sun/**osxapp/**QueuingApplicationDelegate.m
>> @@ -110,8 +110,14 @@
>>
>>   - (void)_handleOpenURLEvent:(**NSAppleEventDescriptor *)openURLEvent
>> withReplyEvent:(**NSAppleEventDescriptor *)replyEvent
>>   {
>> +    // Make an explicit copy of the passed events as they may be
>> invalidated by the time they're processed
>> +    NSAppleEventDescriptor *openURLEventCopy = [openURLEvent copy];
>> +    NSAppleEventDescriptor *replyEventCopy = [replyEvent copy];
>> +
>>       [self.queue addObject:[^(){
>> -        [self.realDelegate _handleOpenURLEvent:**openURLEvent
>> withReplyEvent:replyEvent];
>> +        [self.realDelegate _handleOpenURLEvent:**openURLEventCopy
>> withReplyEvent:replyEventCopy]**;
>> +        [openURLEventCopy release];
>> +        [replyEventCopy release];
>>       } copy]];
>>   }
>> -----
>>
>> Please let me know if there is additional information that I can provide
>> - thanks!
>>
>> -James
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20130524/3cde6f26/attachment.html