Where would be the proper place to report this crash in Compose Desktop?

# compose-desktop

[Marcin Wisniowski]

Where would be the proper place to report this crash in Compose Desktop?

[Alexander Maryanovsky]

As always, here: https://github.com/JetBrains/compose-multiplatform/issues

[Marcin Wisniowski]

https://github.com/JetBrains/compose-multiplatform/issues/4179

[Alexander Maryanovsky]

Unless it’s an obvious bug, a reproducer would really help here…

[Alexander Maryanovsky]

According to the doc, this can only happen on systems without a mouse.

[Marcin Wisniowski]

I would imagine the stack trace is not that bad here? Some Kotlin code is assuming a platform type coming from AWT is non-nullable, when it can be.

[Alexander Maryanovsky]

It’s easy to check whether it’s null. The question is what to do then.

[Marcin Wisniowski]

this can only happen on systems without a mouse

Someone using a touch screen maybe?

[Alexander Maryanovsky]

Maybe, but I’d call it a Java bug then.

[Alexander Maryanovsky]

It calls mouseDragged and then when asked about MouseInfo.getPointerInfo() it says “I dunno; no mouse here” 🤡

[Alexander Maryanovsky]

But yeah, I guess no harm in just ignoring the event if MouseInfo.getPointerInfo() is null.

[Marcin Wisniowski]

Agree it's AWT being unreasonable but my understanding of the reality is that trying to report a bug in AWT will just result in it never being fixed. Ignoring the event would be much better than an NPE.

[Marcin Wisniowski]

I received this crash report from 2 separate users with 2 versions of Windows 10, so it's not a unique setup.

[Alexander Maryanovsky]

https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8185890 maybe this

[Alexander Maryanovsky]

Although says it’s been fixed in JDK 10

[Ivan Matkov]

The question is what to do then.

@Alexander Maryanovsky We already have ComposeScene.lastKnownPointerPosition
that was introduced for cases when AWT one is not available. I guess it will be simple fix

[Alexander Maryanovsky]

Yes, we could reimplement it without MouseInfo.getPointerInfo(). Maybe even better that way. Not 100% sure ComposeScene.lastKnownPointerPosition is the right thing to use, but maybe just regular drag offset.

[Alexander Maryanovsky]

I’m also not sure how the current implementation works if you drag the window across monitors.

[Alexander Maryanovsky]

Looks like the coords are local to the device

[Marcin Wisniowski]

Dragging across monitors definitely works currently.

[Alexander Maryanovsky]

Yeah, sounds like it should

[Marcin Wisniowski]

WindowDraggableArea has other issues in it's behavior though, like being unable to drag a window outside of a monitor - it always has to be completely visible, unlike normal OS dragging. But that's unrelated to this.

[Alexander Maryanovsky]

I think that’s a Java or a window-manager (or their combo) limitation.

[Marcin Wisniowski]

@Alexander Maryanovsky Turns out that issue is solved in JBR: https://youtrack.jetbrains.com/issue/CMP-7793/Use-JBR-API-in-WindowDraggableArea-on-Linux

[Alexander Maryanovsky]

I’m not sure we can use JBR APIs like that.

[Marcin Wisniowski]

My understanding is that the JBR API is safe to use and whether it's supported or not is checked at runtime, so it's not tying anything to using the JBR, just enhancing functionality when you do run on the JBR. You'd know better, of course.

[Alexander Maryanovsky]

But didn’t we already fix the crash?

[Marcin Wisniowski]

The crash is fixed, I was referring to the other issues, like not being able to drag a window outside the screen. Like I wrote in the issue.

[Alexander Maryanovsky]

I see