JDK-8166677 : HTMLEditor freezes after restoring previously maximized window
  • Type: Bug
  • Component: javafx
  • Sub-Component: web
  • Affected Version: 8u102,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2016-09-16
  • Updated: 2017-09-07
  • Resolved: 2016-10-06
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9
8u131Fixed 9Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.8.0_102"
Java(TM) SE Runtime Environment (build 1.8.0_102-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.102-b14, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 10.0.10586]

A DESCRIPTION OF THE PROBLEM :
HTMLEditor freezes after restoring previously maximized window; You no longer see the entered text when inputting the text. After resizing the window, the editor "unfreezes" and the previously entered text is shown.

REGRESSION.  Last worked in version 8u77

ADDITIONAL REGRESSION INFORMATION: 
java version "1.8.0_66"
Java(TM) SE Runtime Environment (build 1.8.0_66-b18)
Java HotSpot(TM) 64-Bit Server VM (build 25.66-b18, mixed mode)

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run the test case in attachment.

1. Maximize the window
2. Enter some text
3. Minimize the window
4.. Restore the window by clicking on the icon in the Windows task bar
5. Try to enter some more text

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
additional text is show on screen and caret is blinking
ACTUAL -
no caret visible, the inputted text is not shown.

after resizing the window, the inputted text "magically" appears

ERROR MESSAGES/STACK TRACES THAT OCCUR :
None displayed (no crash)

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.web.HTMLEditor;
import javafx.stage.Stage;

public class HTMLEditorTest extends Application {

	@Override
	public void start(Stage primaryStage) throws Exception {
		final HTMLEditor htmlEditor = new HTMLEditor();
		primaryStage.setScene(new Scene(htmlEditor, 800, 600));
		primaryStage.show();
	}

	public static void main(String[] args) {
		launch(args);
	}

}

---------- END SOURCE ----------


Comments
Additional Information from submitter: ============================== java version "1.8.0_101" Java(TM) SE Runtime Environment (build 1.8.0_101-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode) ====================================================================== Checked this issue against 8,8u101,8u102,8u112ea,9ea on Windows 7 and could reproduce the issue as reported by the submitter. Steps to reproduce: ************************* - Run the attached test program(HTMLEditorTest.java) with JDK - Enter some text - Maximize the window - Minimize the window - Restore the window by clicking on the application in the Windows task bar - Try to enter some more text Result: ********* OS : Windows 7 64 bit, Linux (Ubuntu 14.04 TLS) JDK: ++++ 8 b132 : Pass 8u101 b13 : Pass 8u101 b52 : Pass 8u76 b12 : Pass 8u102 b01 : Fail <<========= introduced version 8u112ea b04 : Fail 9ea+133 : Fail
10-03-2017

Changeset: 3749103a757c Author: mbilla Date: 2016-10-06 22:49 +0530 URL: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/3749103a757c
06-10-2016

Approved to backport to 8u-dev for 8u122.
06-10-2016

+1
06-10-2016

Looks good. After applying your patch I verified that HTMLEditor no longer freezes and also that the test case for JDK-8087997 passes (so JDK-8087997 can be closed as a duplicate).
06-10-2016

webrev: http://cr.openjdk.java.net/~mbilla/8166677/webrev.02/ Executed the unit test cases of web and graphics and all passed.
06-10-2016

I think the existing behavior is an oversight and not intended. Given that a window can transition from iconified directly to maximized, we need to clear the iconified property on Stage in order for the state to match the actual state of the window.
04-10-2016

Debugged Quantum code and in file GlassWindowEventHandler.java, added below line for WindowEvent.MAXIMIZE public Void run() { if (stage == null || stage.stageListener == null) { return null; } switch (type) { case WindowEvent.MINIMIZE: stage.stageListener.changedIconified(true); break; case WindowEvent.MAXIMIZE: stage.stageListener.changedIconified(false); // Added stage.stageListener.changedMaximized(true); break; case WindowEvent.RESTORE: stage.stageListener.changedIconified(false); stage.stageListener.changedMaximized(false); break; I tested the fix and HTMLEditor freezing not observed. But as per the comments in Stage.java, in full screen mode, the variables iconified, resizable continue to represent the same value as in non-fullscreen mode. Need more clarity on this issue whether the existing functionality is the expected behaviour or not? * However once in full-screen mode, {@code Stage}'s {@code x}, {@code y}, * {@code width}, and {@code height} variables will continue to represent * the non-full-screen position and size of the window; the same for * {@code iconified}, {@code resizable}, {@code style}, and {@code * opacity}. If changes are made to any of these attributes while in * full-screen mode, upon exiting full-screen mode the {@code Stage} will * assume those attributes. * </p> * <p> * In case that more {@code Stage} modes are set simultaneously their order * of importance is {@code iconified}, fullScreen, {@code maximized} (from * strongest to weakest).
04-10-2016

+1 Looks ok.
04-10-2016

+1, Looks good to me.
03-10-2016

Incorporating above comment.. webrev: http://cr.openjdk.java.net/~mbilla/8166677/webrev.01/
30-09-2016

webrev: http://cr.openjdk.java.net/~mbilla/8166677/webrev.00/ This fix will not effect JDK-8147851 as i retained the code to check for the size of view. In general, isMaximized and isIconified should be mutually exclusive. There is already an issue reported (JDK-8087997), which is similar to current issue.
29-09-2016

The commit http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/57564ab53438 for JDK-8147851 is causing this regression. I reverted the fix for JDK-8147851 and no freeze observed. Working on solution... Issue is with below code: boolean iconified = (window instanceof Stage) ? ((Stage)window).isIconified() : false; iconfied returns true when screen is minimized and when restore the screen, iconfied returns false. But when the screen is in Maximum size and minimized and restore back -> iconfied value not changing back to false and always returning true and below code (value of reallyVisible) is false. boolean reallyVisible = isTreeReallyVisible();
29-09-2016

Thanks Abhijit for testing.. So seems like this issue is a regression between 8u102 b00 and 8u102 b01.
29-09-2016

One quick, minor comment. If we do go with your proposed fix, the following: && (maximized ? true: !iconified); could reduce to: && (maximized || !iconified); which I think is a little clearer.
29-09-2016

In effect, your proposed fix is a workaround for the underlying problem. If possible I would prefer that we fix the root cause, so that the iconified flag is correct. If that is too difficult / risky, then we might proceed with reviewing your proposed fix.
29-09-2016

Lowering the priority back down to P3 since there is an easy workaround.
26-09-2016

Answering my own question: it still fails when the HTMLEditor is wrapped in a StackPane. There is a simple workaround: After restoring the window, unmaximize it, then maximize it again. It will work correctly.
26-09-2016

One thing to try is to wrap the HTMLEditor in a Stack Pane. It is not expected that a WebView, an HTMLEditor, or any other control, should be used as the root of a Scene. If the problem only happens when HTMLEditor is a root node, then the priority can be lowered.
26-09-2016

Raising priority to P2 given the severity of the bug.
26-09-2016