Hard Freeze On Dropping Images

[Biocava]

Describe the bug
Placed an image from a folder onto background/token layer, froze and unable to interact or close it, have to force quit it from task manager, happened with a different image to the person I'm working with on the same campaign, he was player, I was GM. Didn't happen on the campaign until updating.

To Reproduce
Steps to reproduce the behavior:
Haven't gotten it to reproduce consistently, drag and drop from a folder to the campaign is how it happened.

Expected behavior
No hard freeze.

MapTool Info

• Version: 1.9.2
• Install: New install, old campaign.

Desktop (please complete the following information):

• OS: Windows 10 Pro
• Version: [20H2]
• OS Build: [19042.1052]

Additional context
Campaign started in version 1.5.x, was moved up to 1.7.x, then 1.9.x with the security thing, I believe, using an SR5 Framework, don't remember which.
maptool_2021-06-21_18-03-24.log

[Phergus]

I've had no success reproducing this just by dropping images onto map area however...

Nearly 100% repeatable with the Edit Token dialog open:

1. Open MT.
2. Drop image on token layer from desktop or open explorer window.
3. Double-click to open Edit Token dialog.
4. Attempt to drag another image to Edit Token dialog.
5. MT freezes once dragged image is over MT main window.

If I vary from that set of actions by much I don't see the freeze.

Potentially related:
When you go to drag one of the pre-made Default tokens (the .rptok versions) onto the map the drag action is almost immediately paused (like above) while the dialog warning about mismatched versions (this will only happen in a dev environment or by forcing the MT version to be less than 1.3.b55) is shown. This suggests that during the drag action itself MT is already accessing the file (has a file lock?) instead of waiting for the drop event.

[Azhrei]

I've had no success reproducing this just by dropping images onto map area however...

Nearly 100% repeatable with the Edit Token dialog open:

1. Open MT.
2. Drop image on token layer from desktop or open explorer window.
3. Double-click to open Edit Token dialog.
4. Attempt to drag another image to Edit Token dialog.
5. MT freezes once dragged image is over MT main window.

If I vary from that set of actions by much I don't see the freeze.

Those steps do not produce a freeze on macOS.

For step 2 I've tried dragging from the macOS Finder window, from a browser, and from the Resource Library.

For step 4, I've tried dragging from Finder and a browser. MT does not freeze as soon as the mouse is over the main window, nor does it freeze when it's over the token editor dialog. If I drop the image on top of the token image in the upper left corner, the new image replaces the one that is there (although the drop action triggers the "rejected" action in which the image is shown sliding back to the original source, even though MT accepted the drop; separate bug?).

If I switch to the Config tab in the token editor, I can drag an image from Finder or a browser into either of the Portrait or Handout areas as well and both work (with the same "rejection" action as above, even though it works).

Potentially related:
When you go to drag one of the pre-made Default tokens (the .rptok versions) onto the map the drag action is almost immediately paused (like above) while the dialog warning about mismatched versions (this will only happen in a dev environment or by forcing the MT version to be less than 1.3.b55) is shown.

This does not fail on macOS with MT v1.9.2. Tested with Dragon, Eagle, and Hero. (Although the token image is scaled to approximately 3x. Switching to the Config tab and double-clicking on the image in the bottom-left resets the size. Separate bug?)

Perhaps with full debugging turned on, log files from Windows and macOS can be compared to see how the code flow is different? I've attached my log file for the steps given above. I believe line 187 is where the files in the Resource Library are scanned to determine how to display them in the panel. Dragging from the Resource Library to the map doesn't seem to generate a log entry. Then line 299 starts a drag operation and an exception occurs:

2021-07-01 10:24:40.770 INFO  net.rptools.maptool.client.TransferableHelper - Selected: java.awt.datatransfer.DataFlavor[mimetype=text/uri-list;representationclass=java.lang.String]
2021-07-01 10:24:40.772 INFO  net.rptools.maptool.client.TransferableHelper - /Users/franke/Addons/contrib/Dorpond/Tokens/Fantasy/Misc13.png
java.lang.IllegalArgumentException: URI is not absolute
        at java.net.URL.fromURI(Unknown Source) ~[?:?]
        at java.net.URI.toURL(Unknown Source) ~[?:?]
        at net.rptools.maptool.client.TransferableHelper.textURIListToFileList(TransferableHelper.java:318) ~[MapTool.jar:1.9.2]
        at net.rptools.maptool.client.TransferableHelper.getAsset(TransferableHelper.java:234) ~[MapTool.jar:1.9.2]
        at net.rptools.maptool.client.ui.token.ImageAssetPanel.drop(ImageAssetPanel.java:210) ~[MapTool.jar:1.9.2]
        at java.awt.dnd.DropTarget.drop(Unknown Source) ~[?:?]

The log shows other errors, but I'll file separate bug reports for those.

[Phergus]

I believe that this freeze doesn't happen under Linux either. A Windows only thing apparently.

This does not fail on macOS with MT v1.9.2. Tested with Dragon, Eagle, and Hero.

As noted, it will only happen under a dev environment (where the version is 0.0.1) or if you manually set MT to a version <= 1.3.b55. Also the drag doesn't fail, it pauses while the dialog is open. It's very clunky.

(Although the token image is scaled to approximately 3x.

You would have to ask Dorpond(I think) but I'm pretty sure that is intentional. The Dragon image is resized to match the Huge token size while staying a single cell token. The Hero image was placed so that the figure is the right size for a human and more or less with the head centered but because of the unfortunate stance of the hero, the sword and shield end up outside of the single cell. Same situation on the Eagle.

[br00n0]

I have been able to reproduce the problem consistently today. I might try a reboot to be sure. (2 reboots did nothing)

Steps to reproduce:

1 - Open a campaign (or even create a new one)
2 - Open a token's properties window
3 - Go to the Config tab
4 - Drag either a PNG or a GIF from your desktop and try to drop it in the Portrait zone

Picture file being dragged will stop moving as soon as you are over Maptool's main window and will not respond anymore. File icon will stay there and program will not be responsive as well as the Windows desktop too.

Ending the Maptool task will close it and free the desktop.

I use 1.9.2 and tried with 3 different campaigns with either a PNG or a GIF.

Thanks!

[br00n0]

Hi, I've revisited my bug above.

I was able to drag and drop a PNG in a new token's portrait in my campaign.
I was still unable to do the same with my original token, Maptool would crash.

Here's how I fixed it, it's a work-around:
1 - Select the problematic token
2 - Save it as a .rptok file
3 - Delete the token from the campaign
4 - Save the campaign
5 - Drag and drop the new .rptok file back in the campaign
6 - Save the campaign
7 - Drag and drop a PNG in the token's portrait frame. IT WORKS!

No crash when dragging a PNG into the portrait frame of the token.

So the problem is probably linked to the state of an existing token VS a newly created one.

Hope this helps!

[Azhrei]

This has been reported on a separate Discord server with a workaround:

I think I figured it out. I would set the token to quadprops [a property type] and then try to input the art when I should’ve hit ok after setting to quadprops and then going back in to place the art

In summary, it sounds like the workaround is creating the token, then opening and closing the token editor. After that, it works.

The discussion starts here and span less than an hour (this is on the Verum server): https://discord.com/channels/164927564354289665/598682594275622922/874455720957993000

[Phergus]

Yup that's one way. Or make a change to the token first such as changing to PC or NPC, enabling/disabling Visible to Players, changing Vision type. Pretty much doing anything but trying to change one of the token images as the very first thing.

[FullBleed]

I almost always use MT's resource explorer (masochistic, I know) ... so I've never seen this.

Maybe @kwvanderlinde could take a look at this... he seems well versed on MT's file interactions.

[kwvanderlinde]

Maybe @kwvanderlinde could take a look at this... he seems well versed on MT's file interactions.

I think you're overestimating my familiarity with this stuff 😄 Still, I can't really ignore a name drop like that so I guess I'm going down the rabbit hole...

I managed to reproduce the bug on fresh installs of MapTool 1.9.2, 1.9.3 and 1.10.3. Debug information shows that all these versions run on AdoptOpenJDK 16. That's quite convenient since Google brought me to these JDK bugs that affect JDK 16:

• Drag And Drop hangs on Windows
• DragAndDrop hangs on Windows

The latter bug seems to be exactly the cause of the freezing reported here and affects versions going back to Java 8. It is marked as fixed in Java 17 with a backport to JDK 16.0.2. I verified that the backport fixes our issue by running MT 1.9.2 from Intellij on different JDK versions. I was able to reproduce the issue with OpenJDK 16.0.1, but not with Azul Zulu 16.0.2 or OpenJDK 17.0.1.

So the good news is that if we can update MT's version of Java this issue should just go away.

[Phergus]

Tested with 16.0.2 from https://adoptium.net/releases.html?variant=openjdk16 and could no longer reproduce the freeze.

It looks like AdoptOpen is rebranding or something and we need to change the build.gradle to use the downloads from Adoptium instead in any case.

Should we go ahead to Java 17 for 1.11? No guts, no glory!

[kwvanderlinde]

Should we go ahead to Java 17 for 1.11? No guts, no glory!

I for one would be very happy to move to Java 17 as it should fix another bug that I constantly run into: #2754