Hi, James.
Fix looks fine to me as well.
On 24.05.2013 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
<[email protected] <mailto:[email protected]>> 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
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
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
--
Best regards, Sergey.
