"Type Into Table Cell" keyword holds down Enter key forever

[GoogleCodeExporter]

We are using SwingLibrary 1.1.3, JVM 1.6.0.26 and RHEL5 Linux.

We have noticed that using the "Type Into Table Cell" keyword results in the 
Enter key being pressed and never released, which can have some unexpected 
effects... everything one does subsequently in a test is essentially done with 
the Enter key held down.

I believe the reason for this is that Jemmy double clicks the cell, types in 
the text, and then tries to press Enter. Unfortunately, it assumes that the 
KEY_PRESSED and KEY_RELEASED events should be generated on the same widget, 
whereas in the case of the table cell edit, the KEY_PRESSED event causes 
editing to stop and the JTextField to go away. This means the KEY_RELEASED 
event is never generated. (If you do this by hand, Swing emits the KEY_RELEASED 
event on the JTable).

See the KeyEventDriver in Jemmy for the code I'm referring to here.

Original issue reported on code.google.com by geoff.ba...@gmail.com on 22 Aug 2011 at 1:59

[GoogleCodeExporter]

How do you actually observe this behavior? 

We could probably implement functionality similar to 
JTableMouseDriver.editCell, but so that we generate pressKey and releaseKey on 
the textfield and table, respectively.

Can you Geoff implement a minimal test case to verify the correct behavior?

Original comment by janne.t....@gmail.com on 23 Aug 2011 at 12:01

• Changed state: Accepted

[GoogleCodeExporter]

One effect I have noticed is that the edit (as in the TableModel being updated 
rather than the edit component going away) does not in fact take place until 
some time afterwards, which can lead to synchronisation issues if the test 
concerned assumes the change has been processed in the model and tries to 
proceed when it hasn't. If the Enter key is released this does not happen.

Another effect has been to screw up how our recorder manages things internally. 
Because we keep track of key presses so we can figure out what semantic events 
have been caused by each other, it's very difficult to do this if a key is 
never released.

By "test case" do you mean a formal test case written with JUnit, or is a 
Python example (like the ones I attached in my other bugs) that prints stuff 
sufficient?

Original comment by geoff.ba...@gmail.com on 23 Aug 2011 at 12:24

[GoogleCodeExporter]

OK, it was fairly easy to add an example demonstrating the first effect. The 
test script edits a cell and then prints the value in the table model 
afterwards. If you give it an argument it will generate its own KEY_RELEASE. As 
you can see the edit is not completed in the first, basic case.

$ env CLASSPATH=swinglibrary-1.1.3.jar jython testscript.py
Using org.netbeans.jemmy.drivers.DefaultDriverInstaller driver installer
unchanged
$ env CLASSPATH=swinglibrary-1.1.3.jar jython testscript.py release
Using org.netbeans.jemmy.drivers.DefaultDriverInstaller driver installer
changed

It's also fairly easy to add an AWTEventListener and verify that the Enter key 
is never released in the first case.

Original comment by geoff.ba...@gmail.com on 23 Aug 2011 at 6:59

Attachments:

• sut.py
• testscript.py

[GoogleCodeExporter]

Thanks for the scripts, I will take a look whether this could be fixed without 
having to patch Jemmy.

Original comment by janne.t....@gmail.com on 24 Aug 2011 at 11:04

[GoogleCodeExporter]

Original comment by janne.t....@gmail.com on 24 Aug 2011 at 11:20

• Added labels: Target-1.2

[GoogleCodeExporter]

These issue are not going to be included in 1.2

Original comment by janne.t....@gmail.com on 13 Sep 2011 at 10:06

[GoogleCodeExporter]

Original comment by janne.t....@gmail.com on 13 Sep 2011 at 10:07

• Removed labels: Target-1.2

[GoogleCodeExporter]

Fixed this by always generating the release event, as in the attached 
testscript.

https://github.com/robotframework/SwingLibrary/commit/b0a62e342293eb89dad413d2d6
465108537b3c43

Original comment by janne.t....@gmail.com on 24 Apr 2012 at 8:20

• Changed state: Done

[GoogleCodeExporter]

Original comment by janne.t....@gmail.com on 4 May 2012 at 10:39

• Added labels: Target-1.2.1

[GoogleCodeExporter]

Original comment by janne.t....@gmail.com on 4 May 2012 at 10:40

• Added labels: Target-1.3
• Removed labels: Target-1.2.1