• Type: Bug
• Component: javafx
• Sub-Component: graphics
• Affected Version: 8

• Priority: P3
• Status: Resolved
• Resolution: Fixed

• Submitted: 2013-06-25
• Updated: 2015-06-12
• Resolved: 2014-04-11

JDK 8
8u20Fixed

Thanks for your help. Fortunately I just found a Java fix, which (until now) works for me. Hopefully it will still work tomorrow ;-). It's probably way better to replace glass.dll. I am also not sure about the license issue. It just inverts and restores the resizable property, which seems to trigger a repaint. It also works for the "show desktop" case and it doesn't blink in the taskbar (which was caused by the requestFocus()). stage.xProperty().addListener(new ChangeListener<Number>() { @Override public void changed(ObservableValue<? extends Number> observableValue, Number number, Number number2) { if (stage.isIconified()) { stage.setResizable(!stage.isResizable()); stage.setResizable(!stage.isResizable()); } } }); Note that using iconifiedProperty() does not work for maximized windows due to RT-36916, therefore I am using xProperty. 02-05-2014 I would note that using just the glass DLL from 8u20 is likely to be riskier than just using 8u20-ea. Also, I do not know whether the license even allows you to deploy an app this way, but we wouldn't recommend it in any case. It might be fine for your own internal testing 30-04-2014 The fix is in glass.dll, obviously. You can try and use the library from the 8u20 ea build if you wish. Note that we do not support this configuration, and we do not recommend doing this at all. I'm not sure if there's any java-only workaround for this bug that resolves all the issues (incl. the "Show Desktop" button). If you find one, please share. 30-04-2014 Unfortunately, we still have the problem. Seems, my workaroud didn't work out properly. The workaround works (Geoff's and mine), when you just click the task bar icon, but it does not (reliably) work, when you click "show desktop" on the taskbar. The requestFocus is called, but nonethless the application is black. Do you know any other workaround or things I can do/try without using 8u20-ea (where it's fixed)? Is the fix somewhere in a DLL in the jre/lib folder, which I could just exchange in the 8u5 folder? Or could I just replace a .class file in the jfxrt.jar? I know it would be dirty, but I hesitate to use an early access build for our outstanding release of our product and this bug is the only remaining JavaFX 8 bug, which got prioritized as blocker by my product owner and which I am unable to solve. 30-04-2014 It's good to have a confirmation that the fix in 8u20b10 actually works fine. Thanks, Christian! 25-04-2014 Problem 1) is hard to replicate. I think I only got it once. At that time we worked with Geoff's workaround. Maybe my new workaround fixes it. As I said, with 8u20 the problems are gone. No workaround is needed. At least the reproducible problem is gone. If I still find anything suspicious, I will file a bug (as always ;-)). 25-04-2014 I will. I just saw activity in this JIRA and noted that Christian said we still had a problem that we should track if real. 24-04-2014 Christian, what build of JDK/FX are you using? The fix for this bug has been integrated into 8u20b10 which is currently available for download at https://jdk8.java.net/download.html Can you try it and report whether you need any workarounds anymore, or if something is still broken? Also, I second to Steve: if you discover a new bug, please file a JIRA and provide all the details so that we can replicate it. 24-04-2014 Christian, if you can track down 1) with a repeatable case, please enter a JIRA for it. Indicate how long you must wait (i.e. 5 minutes) and whether the screen saver has kicked in. Thanks. 24-04-2014 This seems to work better and addresses problem 2.): stage.iconifiedProperty().addListener(new ChangeListener<Boolean>() { @Override public void changed(ObservableValue<? extends Boolean> observableValue, Boolean aBoolean, Boolean aBoolean2) { if (aBoolean2 && stage.isFocused()) { stage.requestFocus(); } } }); Btw: Problem 2.) is also fixed with 8u20. 24-04-2014 The suggested workaround by Geoff does not work in all cases. 1.) It's hard to reproduce, but I think, if the window stays longer minimized in the taskbar (a few minutes), I discovered, that it sometimes becomes black, too, after expanding it again. 2.) If the window is normally shown (not in the taskbar), then you click "show desktop" (either on the very right on the taskbar or via context menu on the taskbar), the window get iconified. If you then expand it again, it's always black. As an annyoing side effect, the window blinks in the taskbar, if you use "show desktop". Is there any other known workaround? Should I file a new bug for 2.) (since it's slightly different behavior)? 24-04-2014 Apparently, the same bug exists in FullScreenWindow.cpp, so I've updated the fix and generated a webrev: http://cr.openjdk.java.net/~anthony/g-509-taskbarMinimize-RT-31272.0/ I'll be pushing it today at ~9am PST if no objections. 11-04-2014 I tested the fix on my system and it works fine for me, too. 10-04-2014 +1 This actually agrees with MSDN http://msdn.microsoft.com/en-us/library/windows/desktop/ms646274(v=vs.85).aspx See remarks: "Remarks If the window is being activated and is not minimized, the DefWindowProc function sets the keyboard focus to the window." 10-04-2014 I've verified that the proposed solution resolves the issue. The patch (to be reviewed by Felipe and Steve): diff -r 92396a5f81f2 modules/graphics/src/main/native-glass/win/GlassWindow.cpp --- a/modules/graphics/src/main/native-glass/win/GlassWindow.cpp +++ b/modules/graphics/src/main/native-glass/win/GlassWindow.cpp @@ -309,13 +309,16 @@ HandleDestroyEvent(); return 0; case WM_ACTIVATE: + // The fActive shouldn't be WA_INACTIVE && the window shouldn't be minimized: + #define IS_FOCUS_GAINED(wParam) (LOWORD(wParam) != WA_INACTIVE && HIWORD(wParam) == 0) + if (IsInFullScreenMode()) { - HWND hWndInsertAfter = LOWORD(wParam) != WA_INACTIVE ? HWND_TOPMOST : HWND_BOTTOM; + HWND hWndInsertAfter = IS_FOCUS_GAINED(wParam) ? HWND_TOPMOST : HWND_BOTTOM; ::SetWindowPos(GetHWND(), hWndInsertAfter, 0, 0, 0, 0, SWP_ASYNCWINDOWPOS | SWP_NOACTIVATE | SWP_NOMOVE | SWP_NOOWNERZORDER | SWP_NOSIZE); } if (!GetDelegateWindow()) { - HandleActivateEvent(LOWORD(wParam) != WA_INACTIVE ? + HandleActivateEvent(IS_FOCUS_GAINED(wParam) ? com_sun_glass_events_WindowEvent_FOCUS_GAINED : com_sun_glass_events_WindowEvent_FOCUS_LOST); } 10-04-2014 It is reasonable to state that a minimized window cannot be considered focused, even if MS Windows is trying to tell us otherwise. The solution could be to treat a WM_ACTIVATE(fActive:WA_ACTIVE fMinimized:True) message as a FOCUS_LOST event because the fMinimized flag is True. In that case, the subsequent WM_ACTIVATE(fActive:WA_ACTIVE fMinimized:False) message will be correctly interpreted as a FOCUS_GAINED event, and the focus should be fixed then. 10-04-2014 This bug indeed has something to do with focus messages. A window receives the following focus-related messages when I minimize and then restore it using the Minimize button in the titlebar: <00031> 0096049A S WM_KILLFOCUS hwndGetFocus:(null) <00032> 0096049A R WM_KILLFOCUS <00049> 0096049A S WM_ACTIVATE fActive:WA_INACTIVE fMinimized:True hwndPrevious:(null) <00050> 0096049A R WM_ACTIVATE <00064> 0096049A S WM_ACTIVATE fActive:WA_ACTIVE fMinimized:True hwndPrevious:(null) <00065> 0096049A R WM_ACTIVATE <00089> 0096049A S WM_SETFOCUS hwndLoseFocus:(null) <00090> 0096049A R WM_SETFOCUS <00091> 0096049A S WM_ACTIVATE fActive:WA_ACTIVE fMinimized:False hwndPrevious:(null) <00092> 0096049A R WM_ACTIVATE However, when I perform the same action using the taskbar button, the received messages are as follows: <00037> 0096049A S WM_ACTIVATE fActive:WA_INACTIVE fMinimized:False hwndPrevious:(null) <00038> 0096049A R WM_ACTIVATE <00041> 0096049A S WM_KILLFOCUS hwndGetFocus:(null) <00042> 0096049A R WM_KILLFOCUS <00054> 0096049A S WM_ACTIVATE fActive:WA_ACTIVE fMinimized:True hwndPrevious:(null) <00055> 0096049A R WM_ACTIVATE <00093> 0096049A S WM_SETFOCUS hwndLoseFocus:(null) <00094> 0096049A R WM_SETFOCUS <00095> 0096049A S WM_ACTIVATE fActive:WA_ACTIVE fMinimized:False hwndPrevious:(null) <00096> 0096049A R WM_ACTIVATE The difference here is that Windows sends us WM_ACTIVATE(fActive:WA_ACTIVE fMinimized:True) message, so Glass and FX consider the window active while it's minimized. And therefore, when we receive a WM_ACTIVATE(fActive:WA_ACTIVE fMinimized:False) when the window is being restored, we ignore this focus message because the window has already been focused from our perspective. 10-04-2014 Oh, I guess it needs hello.css to be present somewhere. False alarm then. 10-04-2014 @Kevin: the attached HelloFontSize fails to start with FX8u20dev/JDK8GA. Is this a known issue? The exception thrown is: Exception in Application start method java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(Lau ncherImpl.java:363) at com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImp l.java:303) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:767) Caused by: java.lang.RuntimeException: Exception in Application start method at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherIm pl.java:875) at com.sun.javafx.application.LauncherImpl.lambda$launchApplication$133( LauncherImpl.java:157) at com.sun.javafx.application.LauncherImpl$$Lambda$48/4940284.run(Unknow n Source) at java.lang.Thread.run(Thread.java:744) Caused by: java.lang.NullPointerException at HelloFontSize.start(HelloFontSize.java:145) at com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$139 (LauncherImpl.java:821) at com.sun.javafx.application.LauncherImpl$$Lambda$51/22235630.run(Unkno wn Source) at com.sun.javafx.application.PlatformImpl.lambda$runAndWait$151(Platfor mImpl.java:319) at com.sun.javafx.application.PlatformImpl$$Lambda$44/13455811.run(Unkno wn Source) at com.sun.javafx.application.PlatformImpl.lambda$null$149(PlatformImpl. java:288) at com.sun.javafx.application.PlatformImpl$$Lambda$47/14871004.run(Unkno wn Source) at java.security.AccessController.doPrivileged(Native Method) at com.sun.javafx.application.PlatformImpl.lambda$runLater$150(PlatformI mpl.java:287) at com.sun.javafx.application.PlatformImpl$$Lambda$45/5330537.run(Unknow n Source) at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatch er.java:95) at com.sun.glass.ui.win.WinApplication._runLoop(Native Method) at com.sun.glass.ui.win.WinApplication.lambda$null$127(WinApplication.ja va:102) at com.sun.glass.ui.win.WinApplication$$Lambda$37/14944660.run(Unknown S ource) ... 1 more Exception running application HelloFontSize 10-04-2014 Thanks Geoff! Your workaround works for me, too!! :-) 10-04-2014 It seems that we need to decide what the origin of a minimized window is on all platforms and make it consistent. 09-04-2014 Thanks for the hints. Maybe that will help us find a solution. 09-04-2014 It occurred to me that this bug could be related to focus. As there is no focus lost event when the window is minimised using the task bar there is no focus gained event when it is restored, so the window is not called to repaint. My workaround above puts the focus request in the queue and so causes the repaint. I could be way off, knowing nothing about the internals of java fx of course...! 07-04-2014 I've found a programmatic workaround, not sure how applicable it is to other cases. The focus property is not updated when you minimise a stage using the task bar, but the xProperty is. When minimised (on my system at least) is is set to -32,000. I've set a ChangeListener on the xProperty of the stage, and in it I call: if (newValue.intValue() < 0) primaryStage.requestFocus(); This doesn't bring focus back to the now minimised window, but when the window is again activated it will be repainted properly. 07-04-2014 This seems more serious than we originally thought, so I am raising the priority to P3 and targeting it to 8u20. 03-04-2014 Please solve asap this bug! 28-03-2014 The fix is critical for our apps - request resolution as soon as possible Thank you 28-03-2014 https://community.oracle.com/thread/3538052 "Screen doesn't render after a some idle time" I see this happening quite often. Steps to reproduce, run any Javafx application and click on the icon on task bar and minimize and maximize it. the window goes blank and black. Only when we mouse over or click on any component not the pane, it repaints. I am using windows 7 on a 64 bit machine. Running JDK 8 on Netbeans 8 environment. 26-03-2014 Reported a couple of times on Oracle forums: https://community.oracle.com/thread/3538052 "Screen doesn't render after a some idle time" https://community.oracle.com/thread/3539091 "Java 8: Application becomes black after it is maximized from taskbar" 26-03-2014 Is there any workaround? E.g. manually trigger a repaint after maximizing the window? 26-03-2014 I'm also getting this bug when the window is restored via Stage.setIconified(false), as long as it was minimized via clicking the Windows taskbar icon. 03-03-2014 Based on Chien's comments, this is likely a glass or quantum issue. Given that it repaints eventually, and that there is a trivial workaround (either move your mouse into the window and it will eventually repaint, or else minimize using the window decoration), this is not a P3 bug. Lowering to P4 and moving out of FX 8. 27-11-2013 I see a different timing behavior when I instrumented a print line in ViewPainter.paintImpl(). I saw the instrumented line printed when I clicked on the icon to collapse HelloComboBox, but no print line when I clicked the icon to expand the program next. This behavior is opposite to shapet3dtest.MixedShapesT3D where no print on collapse and print on expand. 26-11-2013 I verified that this bug happens on all pipes including sw and j2d using HelloComboBox. Programs without UI Control such as HelloRectangle and shapet3dtest.MixedShapesT3D seem to work fine. 26-11-2013 I verified that this is not the same issue as RT-33028 (the fix for that issue doesn't affect this one). The easiest way for me to reproduce it is to run the "HelloFontSize" toy (attached) and minimize it by pressing the icon in the task bar. If you iconify it using the "minimize" button on the window title bar, the bug will not reproduce. 31-10-2013 The symptoms of this bug are similar to RT-33028. 30-10-2013