<AWT Dev> com.apple.eawt.Application.setOpenURIHandler does not deliver initial launch URI
Anthony Petrov
anthony.petrov at oracle.com
Thu May 30 12:24:41 PDT 2013
Yes, jdk7u-dev@ is the right place to request an approval. I believe we
can port it right away given that 1) the fix is very simple and hence
low-risk; and 2) the 7u-dev repos will soon close for stabilization
before the 7u40 release.
Please follow this template for your request:
http://openjdk.java.net/projects/jdk7u/approval-template.html
You can find links to the mailing list messages at
http://mail.openjdk.java.net/pipermail/awt-dev/
(to link to a review thread for this fix).
Also, you may indicate me as a person who's actually going to push this
fix for you.
--
best regards,
Anthony
On 05/30/2013 11:04 PM, James Tomson wrote:
> 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 <mailto: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>
> <mailto: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>
> <mailto:anthony.petrov at oracle.__com
> <mailto: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>
> <mailto:anthony.petrov at oracle.__com
> <mailto:anthony.petrov at oracle.com>>
> <mailto:anthony.petrov at oracle.__com
> <mailto:anthony.petrov at oracle.com>
>
> <mailto: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>
> >>
>
> <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
> >>
> >>
>
>
>
More information about the awt-dev
mailing list