doh.robot.typeKeys and doh.robot.KeyPress seems not support backslash key

[Zebulon]

The '\' char seems not working when using doh.robot.typeKeys and doh.robot.KeyPress?

in the JVM console, i got

Sun May 03 11:45:33 CEST 2009: > _typeKey Robot 92, 0 Sun May 03 11:45:33 CEST 2009: Error in _typeKey java.lang.NullPointerException?

at DOHRobot.getVKCode(DOHRobot.java:665) at DOHRobot.access$2400(DOHRobot.java:12) at DOHRobot$21.run(DOHRobot.java:911) at java.security.AccessController?.doPrivileged(Native Method) at DOHRobot._typeKey(DOHRobot.java:901) at DOHRobot.access$2600(DOHRobot.java:12) at DOHRobot$KeyPressThread?.run(DOHRobot.java:1029)

Sun May 03 11:45:33 CEST 2009: < _typeKey Robot

So, there is a crash on the ASCII 92 char ( which is backslash ) It seems to be supported in the code though ?

Here is the code portion from DOHRobot.java

int[] mykeys = new int[]{ KeyEvent?.VK_COMMA, KeyEvent?.VK_MINUS, KeyEvent?.VK_PERIOD, KeyEvent?.VK_SLASH, KeyEvent?.VK_SEMICOLON, KeyEvent?.VK_LEFT_PARENTHESIS, KeyEvent?.VK_NUMBER_SIGN, KeyEvent?.VK_PLUS, KeyEvent?.VK_RIGHT_PARENTHESIS, KeyEvent?.VK_UNDERSCORE, KeyEvent?.VK_EXCLAMATION_MARK, KeyEvent?.VK_DOLLAR, KeyEvent?.VK_CIRCUMFLEX, KeyEvent?.VK_AMPERSAND, KeyEvent?.VK_ASTERISK, KeyEvent?.VK_QUOTEDBL, KeyEvent?.VK_LESS, KeyEvent?.VK_GREATER, KeyEvent?.VK_BRACELEFT, KeyEvent?.VK_BRACERIGHT, KeyEvent?.VK_COLON, KeyEvent?.VK_BACK_QUOTE, KeyEvent?.VK_QUOTE, KeyEvent?.VK_OPEN_BRACKET, KeyEvent?.VK_BACK_SLASH, KeyEvent?.VK_CLOSE_BRACKET, KeyEvent?.VK_EQUALS }; for (int i = 0; i < mykeys.length; i++){

vkKeys.add(new Integer(mykeys[i])); }

Wait for feedback, its blocking for me as i want to type a windows path which needs like 'c:
temp
'

Thanks

[haysmark]

I ran the following test with the following modification to include a backslash:

​http://archive.dojotoolkit.org/nightly/checkout/util/doh/tests/robot.html

doh.register("doh.robot",
{
	name:"dojorobot1",
	timeout:6900,
	setUp:function(){
		document.getElementById('textbox').value="hi";
	},
	runTest:function(){
		var d=new doh.Deferred();
		doh.robot.mouseMove(30, 30, 500);
		doh.robot.mouseClick({left:true}, 500);
		doh.robot.typeKeys(" again\\", 500, 2500);
		doh.robot.sequence(function(){
			if(document.getElementById('textbox').value=="hi again\\"){
				document.getElementById('textbox').value += ": passed";
				d.callback(true);
			}else{
				document.getElementById('textbox').value += ": failed";
				d.errback(new Error("Expected value 'hi again', got "+document.getElementById('textbox').value));
			}
		}, 900);
		return d;
	}
});

I tested in FF3,IE8, and Safari.

[haysmark]

To clarify, I ran the tests on Windows. The tests passed. Since you are constructing Windows file paths, I assume you are also running on Windows? What browser do you see this behavior?

[Douglas Hays]

The locale and keyboard layout might be important as well.

[Zebulon]

Hi, To be exact, i tried to use doh.robot.typeKeys to enter a path when the browse popup appears ( with an input type = file , when you click on browse, a popup appear ) im on FR locale, with a french keyboard.

I cant test now, but if you are unable to reproduce the problem, i'll give you a dump of my code.

Im running the tests under windows yes. and firefox 3.0.10

[Zebulon]

Ok, i just tried your example and have the same problem with a input type = text

Tue May 12 22:54:12 CEST 2009: > _typeKey Robot 92, 0 Tue May 12 22:54:12 CEST 2009: Error in _typeKey java.lang.NullPointerException?

at DOHRobot.getVKCode(DOHRobot.java:665) at DOHRobot.access$2400(DOHRobot.java:12) at DOHRobot$21.run(DOHRobot.java:911) at java.security.AccessController?.doPrivileged(Native Method) at DOHRobot._typeKey(DOHRobot.java:901) at DOHRobot.access$2600(DOHRobot.java:12) at DOHRobot$KeyPressThread?.run(DOHRobot.java:1029)

Tue May 12 22:54:12 CEST 2009: < _typeKey Robot

[haysmark]

Ok, indeed I was able to reproduce this on a French keyboard layout. It seems that the robot is trying to press Alt-Graph and is getting another exception much earlier in the test, hence it is unable to press any character requiring the use of Alt-Graph, including \.

[Jared Jurkiewicz]

(In [17609]) Adding in basic performance module support. \!strict refs #9243

[Jared Jurkiewicz]

(In [17610]) Adding in basic performance module support. \!strict refs #9243

[Jared Jurkiewicz]

Ignore the previous, invalid refs. Transposed a number in the tracker (#9234).

[haysmark]

New JAR file.

[haysmark]

Refs #9243. Enable the robot to get past dead keys in the keyboard detection stage (dead keys still not supported).

[haysmark]

Hi, I attached a potential fix. I am hoping you will test it by applying the patch to your /util then replacing the JAR with the attached file. I would be interested to know if in the JVM console it says, "Error pressing alt graph" followed by a stack trace.

I think the robot did not detect the backslash because it previously tried to test the dead key ' (alt graph + è) and this behavior confused the robot!

[Nathan Toone]

(In [17735]) Refs #9243 - toShow is not defined when running test directly !strict

[Nathan Toone]

(In [17741]) Refs #9243 - fix double byId !strict

[haysmark]

Update: after exploring the JDK's JNI code for awt_Component, I found that Sun actually does not support using the robot to press alt gr on Windows. They are using the native Windows keybd_event which in turn does not list alt gr explicitly:

​http://msdn.microsoft.com/en-us/library/ms645540(VS.85).aspx

However Windows takes alt gr and generates LCONTROL+RMENU instead, so if we were to create a C++ JNI class that could simply press RMENU, then implementing alt gr would be feasible. It's not enough to press ctrl+alt in the Java code because Safari will display the Activity window on ctrl+alt+a but not ctrl+(alt gr)+a.

In the meantime, if you are doing file upload tests, I suggest instead of clicking Browse, use doh.robot.setClipboard to enter file paths and backslashes directly into the system clipboard, then use the operating-system specific paste command to paste the filename into the textbox.

[Colin Snover]

Bulk update of open ticket priorities.

[bill]

Presumably this will never be fixed, because we'll switch to using WebDriver?. Well, I guess in a sense that would fix it, but anyway, probably not worth keeping this ticket open.