Saturday, November 9, 2013

Giving Up on KeyEvents until after Dart 1.0

I think it safe to say that KeyEvent won't befixed in time for the Dart 1.0 release. This makes me sad, but I understand the various moving parts making this a problem. Since whining won't help, it is time to give up the ghost and move onto workarounds.

I already have a separate keyboard shortcut library that boasts some testing and isolates the untestable features for a later time when KeyEvent is fully implemented. What is still not working (or at least not tested, which is the same thing, right?) in the ICE Code Editor is navigation with arrow kyes, hitting enter in text fields and hitting escape anywhere to hide dialogs. To move on, I think it best to give up trying to generate real or fake KeyEvents.

Instead I am going to fallback to the old standby of hidden buttons. These buttons can be created with style="display:none" so that they will never be seen by humans. They can be clicked by tests and, when clicked, they can call the same methods used by the keyboard handlers. I do this with a heavy heart (OK, so I'm not entirely done whining).

The first test that I would like to get passing verifies what happens after a project list is filtered and then the down arrow key is pressed twice. In the UI, it looks something like:

Aside from the minor nuisance that the test does not work, I am rather proud of this acceptance test. It reads well and (ideally) verifies real human behavior.

Since I cannot create an event with the DOWN keyCode, this is a case in which I need a fake button. I will assume that my fake button for the down arrow key will have an ID of fake_down_key. If present, the helpers.arrowDown() method needs to click this fake down button instead of trying to generate a keydown event:

I can almost live with these changes. I have not changed any functionality, I have only added some useless code from the human perspective. Unfortunately, the test will not work as-is because it includes a check for keycodes, which there will be none for click events. So I have to amend the initial guard clause to only apply to keydown events:

I am going to have some fun in store for when the Enter key is ambiguous, but I think this will mostly work. It gives me some assurance that keyboard interaction is working. It should be fairly easy to back out once KeyEvent is fixed. Most importantly, it does not affect the existing human-facing functionality.