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

[James Tomson]

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> 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>
> 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>> 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/20130528/cecef9fd/attachment.html