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

James Tomson james.b.tomson at gmail.com
Thu May 30 12:04:15 PDT 2013


Fantastic - thanks Anthony et al. for following up.

I'm not quite sure of the procedure to nominate this patch for inclusion in
the jdk7u sources as well - would it be helpful for me to bring this up on
the jdk7u-dev list?

Cheers,
James


On Thu, May 30, 2013 at 10:14 AM, Anthony Petrov
<anthony.petrov at oracle.com>wrote:

> Hi James,
>
> Thank you very much for the contribution! Your fix is now pushed to the
> repository:
>
> http://hg.openjdk.java.net/**jdk8/awt/jdk/rev/768fcc36182a<http://hg.openjdk.java.net/jdk8/awt/jdk/rev/768fcc36182a>
>
> --
> best regards,
> Anthony
>
>
> On 05/29/13 01:30, James Tomson wrote:
>
>> Running the Leaks instrument while triggering multiple openURIs (and
>> openFile, and printFile events) and neither the descriptors or the
>> queued blocks are flagged as leaked. I've only had a chance to run the
>> profile against a patched jdk7u, not a patched jdk8.
>>
>> Cheers,
>> James
>>
>>
>> On Mon, May 27, 2013 at 1:23 PM, Mike Swingler <swingler at apple.com
>> <mailto:swingler at apple.com>> wrote:
>>
>>     This looks reasonable to me. Did you test the fix using the "leaks"
>>     to determine that the descriptors or the block itself were not
>>     over-retained?
>>
>>     Regards,
>>     Mike Swingler
>>     Apple Inc.
>>
>>     On May 27, 2013, at 6:53 AM, Anthony Petrov
>>     <anthony.petrov at oracle.com <mailto:anthony.petrov at oracle.**com<anthony.petrov at oracle.com>>>
>> wrote:
>>
>>      > Thanks for testing, James. I'm fine with the fix then.
>>      >
>>      > Note that we need at least one more review from a reviewer on
>>     this mailing list before we can push your fix to the repository.
>>      >
>>      > Anyone?
>>      >
>>      > --
>>      > best regards,
>>      > Anthony
>>      >
>>      > On 05/24/13 22:39, James Tomson wrote:
>>      >> 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 <mailto:anthony.petrov at oracle.**com<anthony.petrov at oracle.com>
>> >
>>     <mailto:anthony.petrov at oracle.**com <anthony.petrov at oracle.com>
>>
>>     <mailto:anthony.petrov at oracle.**com <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>
>>      >>
>>     <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>
>>      >> <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/20130530/475ebbb9/attachment.html 


More information about the awt-dev mailing list