Mac drag-and-drop questions

[Martin Fox]

While researching JDK-8153032 I realized that part of the drag-and-drop API doesn’t make sense to me. From what I can determine there’s no reliable way of figuring out whether the user is holding down a modifier key or not while processing a drag event. On Windows DragEvent::getTransferMode() returns TransferMode.MOVE if the user is holding down Shift but also if the user isn’t holding down any key at all. There’s no way of distinguishing between these two cases. Linux has the same problem with TransferMode.COPY.

This seems like a major hole in the API. If the drop target wants to choose the transfer mode based on context it needs to know that the user isn’t trying to force a specific transfer mode. I don’t see how that’s possible with the current API.

> On Sep 30, 2021, at 3:55 PM, Martin Fox <martin at martinfox.com> wrote:
> 
> Kevin,
> 
> As a heads up there are actually two behavior changes to be reviewed. JavaFX is picking up some archaic behavior from the OS which thinks that the modifier key for LINK is Control. The Finder switched over to Option+Command a long time ago and I think JavaFX should follow suit.
> 
> As for finding older bugs I guess it’s just a matter of using the right Search box (my bad). Thanks.
> 
> Martin
> 
>> On Sep 30, 2021, at 3:19 PM, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
>> 
>> If changing the default behavior makes it consistent with native apps on macOS and with JavaFX apps on other platforms, then it seems like the right thing to do. We would want a CSR for the behavior change
>> 
>> As for your question about finding the bug using the old "RT-NNNN" bug ID, you can just paste that into the search box. It will redirect to the right bug:
>> 
>> https://bugs.openjdk.java.net/browse/RT-31449 --> https://bugs.openjdk.java.net/browse/JDK-8116268
>> 
>> -- Kevin
>> 
>> On 9/30/2021 3:03 PM, Martin Fox wrote:
>>> I was just looking at JDK-8237329 which is a drag-and-drop bug on the Mac; holding down the Command key alone is guaranteed to disable an internal dnd operation. I’m putting together a PR to fix this.
>>> 
>>> While going through the bug database looking for related bugs I ran across JDK-8153032 which notes that given a choice of TransferModes the Mac will default to COPY. This doesn’t match the JavaFX behavior on Windows or the user interface guidelines of any platform; normally the default operation is MOVE and the user has to press Option to force COPY. This bug makes it impossible for a control to get drag-and-drop right on the Mac. The code was last touched to address RT-31449 but it looks like the default mode was COPY even before that.
>>> 
>>> So my question is whether or not to fix this long-standing but incorrect behavior. I ask because If we’re going to fix the COPY bug I think it should be tested in conjunction with the fix for the modifier keys.
>>> 
>>> BTW, when I run across a reference to something like RT-31449 is there any way to look at the details of the original bug?
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8237329 <https://bugs.openjdk.java.net/browse/JDK-8237329>
>>> https://bugs.openjdk.java.net/browse/JDK-8153032
>>> https://bugs.openjdk.java.net/browse/JDK-8264172
>>> https://bugs.openjdk.java.net/browse/JDK-8227371 <https://bugs.openjdk.java.net/browse/JDK-8227371>
>>> 
>> 
>