Skip to content
This repository has been archived by the owner on Aug 10, 2022. It is now read-only.

Glitches upon the closure(destory) of a window in macOS 11.4 #39

Open
jukrb0x opened this issue Jul 7, 2021 · 2 comments
Open

Glitches upon the closure(destory) of a window in macOS 11.4 #39

jukrb0x opened this issue Jul 7, 2021 · 2 comments

Comments

@jukrb0x
Copy link

jukrb0x commented Jul 7, 2021

Environment: macOS 11.4 (20F71)
Weka version: weka 3.8.5 (1.0)
image

I think this problem is UI related, please fix it, it deducts the user experience. It happens on my machine, I am not sure for other system like Windows.

Recurrence

Open any one window that in applications and close it, the window will be frozen but still be displaying on the screen.

Screen.Recording.2021-07-07.at.6.40.44.PM.mov

And when opening a new application window, the previous one that has been closed will disappear(be destoryed).

It seems to be a new window is invoked, the previous one is destoryed to some custom java windows. The LogWindow totally has not a problem related to this, and the LogWindow can only have one instance, instead of like that can hold multiple Package Manager, which confused me. (Logically I do think the Package Manager shoulld have only one instance, also for some other utils)

image

image

Same thing happens to the other window in Tools. The Memory usage window also has this problem.

image

Analysis

There must be some logical problems with the closure confirming.

Firstly, some of windows should not have multiple windows, there's no reason for it, like Package Manager or Meomry usage.

The problem occurs in any window that can have multiple instances, and they all go with a closure confirming window, like this:

image

The LogWindow only has one instance, it will be closed immidiately when click the close button. The open file window has no confirm and it will close immediately as well. As shwon in the screen recording above, when close a window but the window is still upon the screen, create an arbitrary window will ensure the closed window is "destoryed". To clarify, the arbitrary window can be another application, or LogWindow, etc. and the closure confirming window is counted among it, and the screenshot below is a "About GUIChosser" window, that works as well. (I think this window might be different from the Windows.)

image

Another one is, when close a window and it has not been destoryed, switch to other apps and switch back, it might be destoryed by then. It happens sometimes. If it still exists there, click the button to close again it may close immediately or create a new window to have the same effect.

Workaround

Create any new window can destory a closed window. If create a new window that does not have the closure confirming then we can close the new window immediately.

@eibe
Copy link

eibe commented Jul 8, 2021

Can you start WEKA without any installed packages and try to reproduce this? I could not reproduce the behavior in your video (using the same version of the OS and the same version of WEKA). Did you perhaps run WEKA on an external display? That is the only other possible difference I can currently think of.

One way to start a clean version of WEKA is to rename the wekafiles folder (or delete it).

@jukrb0x
Copy link
Author

jukrb0x commented Jul 27, 2021

I was using an external display, but I've tried it with only the build-in display, still didn't work out.

and then I tried to open .jar file in the terminal, it threw an exception every time I click the dead window.

demo:

weka.mp4
terminal exception output
java.awt.IllegalComponentStateException: component must be showing on the screen to determine its location
	java.awt.Component.getLocationOnScreen_NoTreeLock(Component.java:2062)
	java.awt.Component.getLocationOnScreen(Component.java:2036)
	sun.lwawt.macosx.CAccessibility$23.call(CAccessibility.java:418)
	sun.lwawt.macosx.CAccessibility$23.call(CAccessibility.java:416)
	sun.lwawt.macosx.LWCToolkit$CallableWrapper.run(LWCToolkit.java:597)
	java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:301)
	java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
	java.awt.EventQueue.access$500(EventQueue.java:97)
	java.awt.EventQueue$3.run(EventQueue.java:709)
	java.awt.EventQueue$3.run(EventQueue.java:703)
	java.security.AccessController.doPrivileged(Native Method)
	java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
	java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:84)
	java.awt.EventQueue$4.run(EventQueue.java:733)
	java.awt.EventQueue$4.run(EventQueue.java:731)
	java.security.AccessController.doPrivileged(Native Method)
	java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
	java.awt.EventQueue.dispatchEvent(EventQueue.java:730)
	java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205)
	java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
	java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
	java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
	java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

	at java.awt.Component.getLocationOnScreen_NoTreeLock(Component.java:2062)
	at java.awt.Component.getLocationOnScreen(Component.java:2036)
	at sun.lwawt.macosx.CAccessibility$23.call(CAccessibility.java:418)
	at sun.lwawt.macosx.CAccessibility$23.call(CAccessibility.java:416)
	at sun.lwawt.macosx.LWCToolkit$CallableWrapper.run(LWCToolkit.java:597)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:301)
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
	at java.awt.EventQueue.access$500(EventQueue.java:97)
	at java.awt.EventQueue$3.run(EventQueue.java:709)
	at java.awt.EventQueue$3.run(EventQueue.java:703)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:84)
	at java.awt.EventQueue$4.run(EventQueue.java:733)
	at java.awt.EventQueue$4.run(EventQueue.java:731)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:730)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

I will get along with this problem but can see if more feedback related to this arises from others.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants