Description Markus Persson 2015-01-29 08:56:54 EST

In certain circumstances, SWT will send SWT.OpenDocument events with strange file paths  on OS X. These events are in addition to events containing the real file paths the user wants to open, if the user opened them one by one. Perhaps even more severe, if the user tries to open multiple files at once in these circumstances, none of the real paths are delivered as events, only the strange file path.

In best case, observed on OS X 10.9.5, 10.10.1 and 10.10.2, these additional paths start with an unusual and most likely illegal prefix (a slash followed by a Unicode BOM) and can thus be filtered out by code that knows about them. But this cannot be guaranteed to always hold for other OS X versions. In fact, it will most likely change soon since the Apple Event data type from which the BOM character originates is deprecated. If this changes, these paths cannot be differentiated from real paths.

The source of these extraneous file paths are Spotlight search terms, which optionally has been included in the "Open Documents" Apple Event since OS X 10.4. Initially, these search terms might only have been included in the event when the files where actually opened from Spotlight (the system-wide search mechanism on OS X). But at least as of the OS X versions mentioned above, they are included, albeit empty, even when a file is double-clicked on in the Finder (including on the desktop). They are not included when you open a file from the command line using the "open" command.

In order to reproduce this behavior, it is important that the SWT application is not already running. This is because the Apple Events take a different route, one without this flaw, once SWT is up and running.

The fix is simple, and is only needed in the Cocoa port of the eclipse executable. Somewhat strangely, but explainable, the Carbon port already does this part correctly.

It is however somewhat complicated to explain what happens, as it requires some level of knowledge about how Apple Events are structured. But I will try. For a better background, I can recommend the old documentation at https://developer.apple.com/legacy/library/documentation/AppleScript/Conceptual/AppleEvents/AppleEvents.pdf

Basically, Apple Events are built using fundamental building blocks called descriptors. Descriptors have a type and data according to that type. Examples of descriptor types are "unicode text with optional BOM" (typeUnicodeText), FSRef (typeFSRef), "UTF-8 encoded text" (typeUTF8Text), and "UTF-8 encoded file URL" (typeFileURL). The first two types are deprecated in favor of the other two. There are operations to convert (or "coerce") a descriptor into another descriptor of a given type, though conversions might not be possible for all descriptor types.

Another descriptor type is the descriptor list (typeAEList), which has a list of other descriptors as its data. An extended form of a descriptor is the "keyword-specified descriptor", which in addition to type and data has a "keyword" specifying the role of the descriptor. An extended form of a descriptor list is the Apple Event record (typeAERecord) whose contained descriptors are all "keyword-specified descriptors". Finally, an extended form of that is the Apple Event (typeAppleEvent), which conceptually divides its content into two Apple Event records, one for "attributes" and one for "parameters".

For this discussion we can mostly ignore the "attributes" part, but it specifies what type of an event it is, in this case "Open Documents" (kAEOpenDocuments). The "parameters" list contains the data that should be operated upon, and in this case includes the file paths to be opened.

But, the file paths are contained within a specific parameter descriptor, namely the "direct parameter", with the keyword keyDirectObject. This descriptor is a descriptor list which contains the file paths as descriptors of type typeFileURL, typeBookmarkData, or some deprecated types like typeFSRef.

Another, optional, parameter descriptor has the keyword keyAESearchText, which contains the Spotlight search terms used to find the files. I have only observed this descriptor with the deprecated type typeUnicodeText and with a BOM.

Now, what the current broken eclipse executable does, is using the Apple Event itself as a descriptor list. It iterates through its descriptors (the parameter descriptors), trying to coerce each one into either a typeFSRef or a typeFileURL.

Unfortunately, the coerce mechanism is a little too helpful here. It sees a string and thinks that sure, it could be a relative file or URL. It sees a list containing a single typeBookmarkData and thinks that well, yes I _could_ extract a URL from it. Only if there are more than one typeBookmarkData, it fails.

So, the fix is to first use [event paramDescriptorForKeyword:keyDirectObject], optionally verify that it is a descriptor list, and the iterate over _its_ descriptors, coercing as before.

This should be fixed in AppleEventDelegate.handleOpenDocuments, which is at
http://git.eclipse.org/c/equinox/rt.equinox.framework.git/tree/features/org.eclipse.equinox.executable.feature/library/carbon/eclipseCarbon.c