JDK-8097034 : [Glass, French Keyboard] cannot type backquote in TextArea & TextField
  • Type: Bug
  • Component: javafx
  • Sub-Component: controls
  • Affected Version: 7u45
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-01-10
  • Updated: 2015-06-12
  • Resolved: 2014-04-16
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
8u20Fixed
Related Reports
Relates :  
JDK-8096685 - Polytonic displays incorrectly when typed in (via TextField)
Relates :  
JDK-8094058 - Apostrophe as dead key doesn't work on Windows 8.1 Latvian (Standard) keyboard layout
Description
Cannot type characters backquote "`" or tilde "~" in TextArea. Same issue for TextField
But it is possible to paste them.
Comments
This fix has caused regressions for other keyboard layouts, starting with 8u20. See RT-39804 and RT-39464.
21-04-2015
Like I said, I have tested several accents in a row. If you stack three accents, the first two are reported as simple TYPED events, and the last one remains active until another key is pressed. Native apps behave like that, and so does FX. So there's no problems with this case.
16-04-2014
Again the fix looks good. The only case I can see is if it is possible to have 3 dead keys stacked (because we only look for two). I am pretty sure this can't happen. +1 (release the code when the repo is open again)
15-04-2014
Here's the latest version of the fix: http://cr.openjdk.java.net/~anthony/g-507-frenchBackquote-RT-35261.3/ It address all the corner cases mentioned above. Again, I've tested on both French and German layouts, tried different combinations of keys (several accents in a row, keys that can't be accented, keys auto-repeating, etc.), and it looks like FX produces the same characters that native apps do (I've compared with Notepad).
15-04-2014
Here's what happens when I type AltGr+7 followed by [: Notepad: <00001> 001205FC P WM_KEYDOWN nVirtKey:VK_CONTROL cRepeat:1 ScanCode:1D fExtended:0 fAltDown:0 fRepeat:0 fUp:0 <00002> 001205FC P WM_KEYDOWN nVirtKey:VK_MENU cRepeat:1 ScanCode:38 fExtended:1 fAltDown:1 fRepeat:0 fUp:0 <00003> 001205FC P WM_KEYDOWN nVirtKey:'7' cRepeat:1 ScanCode:08 fExtended:0 fAltDown:1 fRepeat:0 fUp:0 <00004> 001205FC P WM_DEADCHAR chCharCode:'96' (96) cRepeat:1 ScanCode:08 fExtended:0 fAltDown:1 fRepeat:0 fUp:0 <00005> 001205FC P WM_KEYUP nVirtKey:'7' cRepeat:1 ScanCode:08 fExtended:0 fAltDown:1 fRepeat:1 fUp:1 <00006> 001205FC P WM_SYSKEYUP nVirtKey:VK_CONTROL cRepeat:1 ScanCode:1D fExtended:0 fAltDown:1 fRepeat:1 fUp:1 <00007> 001205FC P WM_KEYUP nVirtKey:VK_MENU cRepeat:1 ScanCode:38 fExtended:1 fAltDown:0 fRepeat:1 fUp:1 <00008> 001205FC P WM_KEYDOWN nVirtKey:VK_OEM_6 cRepeat:1 ScanCode:1A fExtended:0 fAltDown:0 fRepeat:0 fUp:0 <00009> 001205FC P WM_CHAR chCharCode:'96' (96) cRepeat:1 ScanCode:1A fExtended:0 fAltDown:0 fRepeat:0 fUp:0 <00010> 001205FC P WM_CHAR chCharCode:'94' (94) cRepeat:1 ScanCode:1A fExtended:0 fAltDown:0 fRepeat:0 fUp:0 <00011> 001205FC P WM_KEYUP nVirtKey:VK_OEM_6 cRepeat:1 ScanCode:1A fExtended:0 fAltDown:0 fRepeat:1 fUp:1 FX: <00001> 000906BE P WM_KEYDOWN nVirtKey:VK_CONTROL cRepeat:1 ScanCode:1D fExtended:0 fAltDown:0 fRepeat:0 fUp:0 <00002> 000906BE P WM_KEYDOWN nVirtKey:VK_MENU cRepeat:1 ScanCode:38 fExtended:1 fAltDown:1 fRepeat:0 fUp:0 <00003> 000906BE P WM_KEYDOWN nVirtKey:'7' cRepeat:1 ScanCode:08 fExtended:0 fAltDown:1 fRepeat:0 fUp:0 <00004> 000906BE P WM_DEADCHAR chCharCode:'96' (96) cRepeat:1 ScanCode:08 fExtended:0 fAltDown:1 fRepeat:0 fUp:0 <00005> 000906BE P WM_KEYUP nVirtKey:'7' cRepeat:1 ScanCode:08 fExtended:0 fAltDown:1 fRepeat:1 fUp:1 <00006> 000906BE P WM_SYSKEYUP nVirtKey:VK_CONTROL cRepeat:1 ScanCode:1D fExtended:0 fAltDown:1 fRepeat:1 fUp:1 <00007> 000906BE P WM_KEYUP nVirtKey:VK_MENU cRepeat:1 ScanCode:38 fExtended:1 fAltDown:0 fRepeat:1 fUp:1 <00008> 000906BE P WM_KEYDOWN nVirtKey:VK_OEM_6 cRepeat:1 ScanCode:1A fExtended:0 fAltDown:0 fRepeat:0 fUp:0 <00009> 000906BE P WM_DEADCHAR chCharCode:'94' (94) cRepeat:1 ScanCode:1A fExtended:0 fAltDown:0 fRepeat:0 fUp:0 <00010> 000906BE P WM_KEYUP nVirtKey:VK_OEM_6 cRepeat:1 ScanCode:1A fExtended:0 fAltDown:0 fRepeat:1 fUp:1 The logs are the same up to the last WM_KEYDOWN event. I think I understand why that happens. Notepad doesn't clear the dead key status from the keyboard layout, and so Windows is able to detect that another accent key is pressed while the first accent was active. So it translates both characters to the regular WM_CHAR messages. FX clears the dead key status by calling ::ToAscii, and therefore Windows doesn't know about it anymore. So it just sends us another WM_DEADCHAR message for the second dead key. A fix is to check if there's a dead key pending when we're processing the HandleViewDeadKeyEvent(), and if so, then drop the dead key status and send two TYPED events to FX instead. This will emulate what native apps do.
15-04-2014
1. I'm not sure it's possible to type several dead keys. For instance, with French layout if I type AltGr+7 and then [ (which correspond to deadkeys ` and ^ correspondingly), then Notepad will output "`^" - i.e. both dead characters w/o any modifiers. FX behaves differently though. With the current fix the first dead key is ignored altogether, and the second dead key affects the following character typed. This looks like a bug. I'll investigate. 2. This case works fine: FX will produce separate accent character followed by the untranslated character. Native apps do the same.
15-04-2014
Yet another update that fixes a compilation issue in FullScreenWindow.cpp: http://cr.openjdk.java.net/~anthony/g-507-frenchBackquote-RT-35261.2/
15-04-2014
Felipe is not around. The fix looks good. Questions: - it must never be possible to stack dead keys or the fix won't work (not sure that it is ever possible) - if you type ` then 'z' (a character that does not lead to and accented character, both the ` and the 'z' events need to be sent) I realize I could apply the patch but I don't have the keyboards (yes I know I can set the layouts).
15-04-2014
An updated fix with the FullScreenWindow.cpp included: http://cr.openjdk.java.net/~anthony/g-507-frenchBackquote-RT-35261.1/
15-04-2014
(added Felipe to watch list)
15-04-2014
Steve, Felipe, Please review this fix: http://cr.openjdk.java.net/~anthony/g-507-frenchBackquote-RT-35261.0/ I've tested it with French and German keyboard layouts. I've tried various accents/modifiers, both single-key and multi-key (like the AltGr+7 one). Everything seems to work just fine with this fix.
15-04-2014
Sounds good. SWT had the idea of key up/down only (no typed). Magic could occur in the IME or anywhere in the operating system that the application could not see (and really, was not prepared to do anything about). All the application cared about was that it should process keys. Glass solution makes sense for Glass.
15-04-2014
The SWT solution doesn't work well for FX for two reasons: 1. Glass (as well as AWT) send key press/release events for all keys, including deadkeys. At least in the case of AltGr+7 they do. And I think this is reasonable - a user presses some keys, and the toolkit should let an app process the events however it wants. 2. Glass reports character codes for both pressed and released events, meaning that it calls ::ToAscii on WM_KEYUP, too. This will result in resetting the dead key status when processing the RELEASED events for the AltGr and 7 keys, and so the subsequent WM_CHAR won't see them anyway. And we can't just drop the RELEASED events because the preceding PRESSED events won't be balanced then. We could synthesize the balancing parts, of course, but this doesn't seem good. So I decided to do another thing. When we detect that a dead key is pressed (::ToAscii() returns 2), we store the dead key character. Later, when processing a WM_CHAR event, we detect that we've got a stored dead key, and then we call ::FoldString() to convert the reported character and the dead key to the actual character with all the accents applied. This seems to work fine for Alt+7 keys on French keyboards.
15-04-2014
The methods are "bad" because they seem to clear the DEAD status of the keyboard layout (and it kind of makes sense - they need to use the status, and usually the status should be cleared after being used). Peeking for WM_DEADCHAR seems like a good workaround. After all, HandleViewKeyEvent() ignores dead keys anyway, so if just skip the call altogether, then nothing should break. I'll try that. Thanks for the suggestion.
14-04-2014
SWT peeked for WM_DEADCHAR to know that a dead key was coming. It then avoided the offending calls. Not sure what Glass should do. In the comments of the code both these win32 calls are mentioned as being bad.
14-04-2014
In fact, it's both ::ToAsciiEx() and a subsequent call to ::ToUnicodeEx() that make things worse. If I comment out both calls, then I can get the �� character with WM_CHAR. If at least one of the calls is present in HandleViewKeyEvent(), then I get the i character instead.
14-04-2014
It is a call to ::ToAsciiEx() in ViewContainer::HandleViewKeyEvent() that hurts us.
14-04-2014
��� yep ��� you will find the win32 call that screws up Windows keyboard handling. It was so long ago that I hit this ...
14-04-2014
If I comment out the WM_[SYS]KEY[DOWN|UP] handling, then FX receives the �� character with the WM_CHAR message as expected. Note that after our internal processing, we do pass the messages to the DefWindowProc(). It looks like we also do something along the way that tells Windows to ignore the dead key and return the simple i character instead. Investigating...
14-04-2014
DefWindowProc() is called for all messages that you do not process, correct? Also, I dimly remember that calling certain Win32 API could blow the keyboard's mind if called during WM_CHAR processing. How about constructing a simple C code example to show that you are getting the right WM_'s and the morph that into the Glass C code?
01-04-2014
Here's what a Swing app receives: <00001> 00BE0798 S WM_IME_SETCONTEXT fSet:1 iShow:C000000F <00002> 00BE0798 S WM_IME_NOTIFY dwCommand:IMN_OPENSTATUSWINDOW dwCommand:00000002 dwData:00000000 <00003> 00BE0798 R WM_IME_NOTIFY <00004> 00BE0798 R WM_IME_SETCONTEXT <00005> 00BE0798 P WM_KEYDOWN nVirtKey:VK_CONTROL cRepeat:1 ScanCode:1D fExtended:0 fAltDown:0 fRepeat:0 fUp:0 <00006> 00BE0798 P WM_KEYDOWN nVirtKey:VK_MENU cRepeat:1 ScanCode:38 fExtended:1 fAltDown:1 fRepeat:0 fUp:0 <00007> 00BE0798 P WM_KEYDOWN nVirtKey:'7' cRepeat:1 ScanCode:08 fExtended:0 fAltDown:1 fRepeat:0 fUp:0 <00008> 00BE0798 P WM_DEADCHAR chCharCode:'96' (96) cRepeat:1 ScanCode:08 fExtended:0 fAltDown:1 fRepeat:0 fUp:0 <00009> 00BE0798 P WM_KEYUP nVirtKey:'7' cRepeat:1 ScanCode:08 fExtended:0 fAltDown:1 fRepeat:1 fUp:1 <00010> 00BE0798 P WM_SYSKEYUP nVirtKey:VK_CONTROL cRepeat:1 ScanCode:1D fExtended:0 fAltDown:1 fRepeat:1 fUp:1 <00011> 00BE0798 P WM_KEYUP nVirtKey:VK_MENU cRepeat:1 ScanCode:38 fExtended:1 fAltDown:0 fRepeat:1 fUp:1 <00012> 00BE0798 P WM_KEYDOWN nVirtKey:'I' cRepeat:1 ScanCode:17 fExtended:0 fAltDown:0 fRepeat:0 fUp:0 <00013> 00BE0798 P WM_CHAR chCharCode:'236' (236) cRepeat:1 ScanCode:17 fExtended:0 fAltDown:0 fRepeat:0 fUp:0 <00014> 00BE0798 P WM_KEYUP nVirtKey:'I' cRepeat:1 ScanCode:17 fExtended:0 fAltDown:0 fRepeat:1 fUp:1 <00015> 00BE0798 S WM_IME_SETCONTEXT fSet:0 iShow:C000000F <00016> 00BE0798 S WM_IME_NOTIFY dwCommand:IMN_CLOSESTATUSWINDOW dwCommand:00000001 dwData:00000000 <00017> 00BE0798 R WM_IME_NOTIFY <00018> 00BE0798 R WM_IME_SETCONTEXT This is not much different from what Glass receives, but the WM_CHAR provides the correct character code for Swing.
01-04-2014
This didn't really help. Note that WM_KEYUP/DOWN do go through the DefWindowProc. I've added the same processing for WM_IME and WM_CHAR messages but this didn't change anything.
01-04-2014
Of course not! :) I assume that if I process a message, then I don't need the default processing. I'll give it a try and see if this changes anything.
01-04-2014
Are you calling the DefWindowProc() for WM_CHAR and elsewhere?
01-04-2014
Actually, here's events that a Notepad window receives when I press AltGr+7 followed by 'i': <00001> 00330598 S WM_IME_SETCONTEXT fSet:1 iShow:C000000F <00002> 00330598 R WM_IME_SETCONTEXT <00003> 00330598 S WM_IME_NOTIFY dwCommand:IMN_SETCOMPOSITIONFONT dwCommand:0000000A dwData:00000000 <00004> 00330598 R WM_IME_NOTIFY <00005> 00330598 S WM_IME_NOTIFY dwCommand:IMN_SETCOMPOSITIONWINDOW dwCommand:0000000B dwData:00000000 <00006> 00330598 R WM_IME_NOTIFY <00007> 00330598 P WM_KEYDOWN nVirtKey:VK_CONTROL cRepeat:1 ScanCode:1D fExtended:0 fAltDown:0 fRepeat:0 fUp:0 <00008> 00330598 P WM_KEYDOWN nVirtKey:VK_MENU cRepeat:1 ScanCode:38 fExtended:1 fAltDown:1 fRepeat:0 fUp:0 <00009> 00330598 P WM_KEYDOWN nVirtKey:'7' cRepeat:1 ScanCode:08 fExtended:0 fAltDown:1 fRepeat:0 fUp:0 <00010> 00330598 P WM_DEADCHAR chCharCode:'96' (96) cRepeat:1 ScanCode:08 fExtended:0 fAltDown:1 fRepeat:0 fUp:0 <00011> 00330598 P WM_KEYUP nVirtKey:'7' cRepeat:1 ScanCode:08 fExtended:0 fAltDown:1 fRepeat:1 fUp:1 <00012> 00330598 P WM_SYSKEYUP nVirtKey:VK_CONTROL cRepeat:1 ScanCode:1D fExtended:0 fAltDown:1 fRepeat:1 fUp:1 <00013> 00330598 P WM_KEYUP nVirtKey:VK_MENU cRepeat:1 ScanCode:38 fExtended:1 fAltDown:0 fRepeat:1 fUp:1 <00014> 00330598 P WM_KEYDOWN nVirtKey:'I' cRepeat:1 ScanCode:17 fExtended:0 fAltDown:0 fRepeat:0 fUp:0 <00015> 00330598 P WM_CHAR chCharCode:'236' (236) cRepeat:1 ScanCode:17 fExtended:0 fAltDown:0 fRepeat:0 fUp:0 <00016> 00330598 S WM_IME_NOTIFY dwCommand:IMN_SETCOMPOSITIONWINDOW dwCommand:0000000B dwData:00000000 <00017> 00330598 R WM_IME_NOTIFY <00018> 00330598 P WM_KEYUP nVirtKey:'I' cRepeat:1 ScanCode:17 fExtended:0 fAltDown:0 fRepeat:1 fUp:1 <00019> 00330598 S WM_IME_SETCONTEXT fSet:0 iShow:C000000F <00020> 00330598 S WM_IME_NOTIFY dwCommand:IMN_CLOSESTATUSWINDOW dwCommand:00000001 dwData:00000000 <00021> 00330598 R WM_IME_NOTIFY <00022> 00330598 R WM_IME_SETCONTEXT And here's the messages received by Glass when pressing the same keys: <00001> 000A07A4 S WM_IME_SETCONTEXT fSet:1 iShow:C000000F <00002> 000A07A4 S WM_IME_NOTIFY dwCommand:IMN_OPENSTATUSWINDOW dwCommand:00000002 dwData:00000000 <00003> 000A07A4 R WM_IME_NOTIFY <00004> 000A07A4 R WM_IME_SETCONTEXT <00005> 000A07A4 P WM_KEYDOWN nVirtKey:VK_CONTROL cRepeat:1 ScanCode:1D fExtended:0 fAltDown:0 fRepeat:0 fUp:0 <00006> 000A07A4 P WM_KEYDOWN nVirtKey:VK_MENU cRepeat:1 ScanCode:38 fExtended:1 fAltDown:1 fRepeat:0 fUp:0 <00007> 000A07A4 P WM_KEYDOWN nVirtKey:'7' cRepeat:1 ScanCode:08 fExtended:0 fAltDown:1 fRepeat:0 fUp:0 <00008> 000A07A4 P WM_DEADCHAR chCharCode:'96' (96) cRepeat:1 ScanCode:08 fExtended:0 fAltDown:1 fRepeat:0 fUp:0 <00009> 000A07A4 P WM_KEYUP nVirtKey:'7' cRepeat:1 ScanCode:08 fExtended:0 fAltDown:1 fRepeat:1 fUp:1 <00010> 000A07A4 P WM_SYSKEYUP nVirtKey:VK_CONTROL cRepeat:1 ScanCode:1D fExtended:0 fAltDown:1 fRepeat:1 fUp:1 <00011> 000A07A4 P WM_KEYUP nVirtKey:VK_MENU cRepeat:1 ScanCode:38 fExtended:1 fAltDown:0 fRepeat:1 fUp:1 <00012> 000A07A4 P WM_KEYDOWN nVirtKey:'I' cRepeat:1 ScanCode:17 fExtended:0 fAltDown:0 fRepeat:0 fUp:0 <00013> 000A07A4 P WM_CHAR chCharCode:'105' (105) cRepeat:1 ScanCode:17 fExtended:0 fAltDown:0 fRepeat:0 fUp:0 <00014> 000A07A4 P WM_KEYUP nVirtKey:'I' cRepeat:1 ScanCode:17 fExtended:0 fAltDown:0 fRepeat:1 fUp:1 <00015> 000A07A4 S WM_IME_SETCONTEXT fSet:0 iShow:C000000F <00016> 000A07A4 S WM_IME_NOTIFY dwCommand:IMN_CLOSESTATUSWINDOW dwCommand:00000001 dwData:00000000 <00017> 000A07A4 R WM_IME_NOTIFY <00018> 000A07A4 R WM_IME_SETCONTEXT The differences: 1. After switching to the Glass window we don't receive the WM_IME_NOTIFY dwCommand:IMN_SETCOMPOSITIONFONT message. 2. The IMN_SETCOMPOSITIONWINDOW dwCommand parameter differs. 3. The WM_CHAR returns a character code 236 for Notepad and 105 for Glass. This explains why Glass doesn't see the �� character. 4. Notepad receives an additional WM_IME_NOTIFY message after WM_CHAR and before the final WM_KEYUP. Glass doesn't.
01-04-2014
I can reproduce the issue with French keyboard layout. When I press AltGr+7, Glass doesn't receive any WM_IME_ window messages, although I think it should receive WM_IME_STARTCOMPOSITION in this case.
01-04-2014
This seems bad. We should fix this for 8u20.
26-03-2014
Sorry Kevin, the issue is not resolved with jdk8u20b05 that I downloaded tonight. I'am afraid you have to buy a french keyboard! Here are the output when I pressed the "��" character key code pressed : DIGIT7 char typed : �� key code typed : UNDEFINED key code released : DIGIT7 char released : When I pressed the "7" character with SHIFT+"��": key code pressed : SHIFT key code pressed : DIGIT7 char typed : 7 key code typed : UNDEFINED key code released : DIGIT7 char released : -When I pressed ALT-GRAPH+"��" followed by SPACE, the sequence which should print the backquote "`" on my keyboard, key code pressed : CONTROL key code pressed : ALT_GRAPH key code pressed : DIGIT7 key code released : DIGIT7 char released : key code released : CONTROL char released : key code released : ALT_GRAPH char released : key code pressed : SPACE char typed : key code typed : UNDEFINED key code released : SPACE char released : You see that the key code typed is UNDEFINED. This is maybe specific to this keyboard : when key "~" or "`" are pressed, the character which is typed depends on the key which is typed next. For example, typing "~" + "n" print a "��", typing "`" + "i" print "��". But typing "`"+q, print "`q".
26-03-2014
Presidio was the original (and now very old) FX 2.0 release. I would expect that the issue would still reproduce in JDK 8, so thank you for confirming that. Can you try it with the JDK 8u20 early access release? We hope your issue will be fixed by the recent fix for RT-32300 in 8u20.
26-03-2014
Kevin, I reproduced the issue today with Java 1.8.0b132...To which releasecorrespond "Presidio"?
26-03-2014
Early access versions of 8u20 are now available. Can you test it and let us know whether it works (in which case we can close this as a duplicate) ?
26-03-2014
OK, I understand it is not easy to test without the concrete keyboard.
13-01-2014
Daniel, when an early access build for 8u20 becomes available, please confirm that the bug is fixed for you. If not, please indicate in this JIRA and we will target it for 8u20 or 9. Thanks!
13-01-2014
Thanks for the code. We have recently fixed keyboard problems on non-English platforms. The code has been released in 8u20 but I don't think there are any early access builds available. I don't have a French keyboard and the bug was on a German keyboard but I'm betting this is fixed. When early access builds for 8u20 become available, can you retest? I am going to reopen this bug and target it for 'Lombard Updates' but it is unlikely that we will fix it there as these updates are mostly for crashes and exceptions.
13-01-2014
Can you reproduce with java1.7.0_45 ? I suspect the bug has something to do with my french keyboard : the backquote is with the "ALT GRAPH" and "7" key down. Here is my hello world example: /* * To change this license header, choose License Headers in Project Properties. * To change this template file, choose Tools | Templates * and open the template in the editor. */ package javafxapplication41; import javafx.application.Application; import javafx.event.ActionEvent; import javafx.event.EventHandler; import javafx.scene.Scene; import javafx.scene.control.Button; import javafx.scene.control.TextField; import javafx.scene.input.KeyEvent; import javafx.scene.layout.StackPane; import javafx.stage.Stage; /** * * @author Daniel */ public class JavaFXApplication41 extends Application { @Override public void start(Stage primaryStage) { final TextField text = new TextField(); // text.setOnAction(new EventHandler<ActionEvent>() { // @Override // public void handle(ActionEvent event) { // System.out.println("test=" + text.getText()); // } // }); text.setOnKeyTyped(new EventHandler<KeyEvent>() { @Override public void handle(KeyEvent t) { System.out.println("char typed : " + t.getCharacter()); System.out.println("key code typed : " + t.getCode()); } }); text.setOnKeyPressed(new EventHandler<KeyEvent>() { @Override public void handle(KeyEvent t) { System.out.println("key code typed : " + t.getCode()); } }); text.setOnKeyReleased(new EventHandler<KeyEvent>() { @Override public void handle(KeyEvent t) { System.out.println("key code typed : " + t.getCode()); System.out.println("char typed : " + t.getCharacter()); } }); StackPane root = new StackPane(); root.getChildren().add(text); Scene scene = new Scene(root, 300, 250); primaryStage.setTitle("Test!"); primaryStage.setScene(scene); primaryStage.show(); } /** * The main() method is ignored in correctly deployed JavaFX application. * main() serves only as fallback in case the application can not be * launched through deployment artifacts, e.g., in IDEs with limited FX * support. NetBeans ignores main(). * * @param args the command line arguments */ public static void main(String[] args) { launch(args); } }
10-01-2014
I tried HelloTextField in Windows and Mac and it works for me in 8u20. Please provide sample code that shows the problem. https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report
10-01-2014