#27 Right key tab simulation renders useless the text area inputs.

Who had the idea of simulating a tab when the right arrow is pressed in a text area?

if( event.keyCode == KEY_RIGHT_ARROW /* This is to simulate a tab press */ ) { ...

That person expects the cursor to move to the right when the right key is pressed...

I like your writing style Claudio :D I can feel the pain across the atlantic, right into my heart. You should probably pick up writing at some point.

Anyway, this is obviously NOT the intended behavior. You might think the people developing AToMPM are some one-celled lifeforms incapable of constructing a coherent thought, but I assure you they at least have developed some intelligence. If I'm not mistaken one even got a PhD at some point... Go figure!

I would invite you to read the comments above that function (I know it's hard, just, you know, scroll up a bit):

Constructs a textarea element. In this element, Alt + Right Arrow is treated as a tab.

The intended behavior is that Alt + Right Arrow simulates a tab. That seems more reasonable, and a quick test verifies this behavior on my end. Now, I must ask: what browser are you using? Is it Chrome (the only one supported), or another one?

Thank you very much for your complaint, and if there is anything else we can do for you on this glorious day, please let me know.

I invite you to follow, with Chrome, the following steps:

1. Launch and Open AtomPM.
2. Open a model (e.g., /Formalisms/TrafficLight.defaultIcons.model)
3. Open the properties of an element (e.g., Shift+Click in the red circle, within VisualizationIcon).
4. Click the mapper textArea.
5. Switch to another window using ALT+TAB.
6. Switch back to the AtomPM window using ALT+TAB again.
7. Now place the cursor somewhere within the mapper code, and press the RIGHT_ARROW key.
8. Behold the marvelous behavior :p.
9. Think about how right Claudio is :D.

Here's what I think is happening: The onKeyDown event is being handled in step 5, which causes the currentKeys global variable to think the ALT is being pressed. However, in the same step, the onKeyUP event is not handled because you just switched to another window. This causes an inconsistency. I would have thought that the onKeyUP event would have been triggered in step 6, but it is not triggered.

When back at the textArea, any RIGHT_ARROW press will simulate a tab, because of this.

I don't see an easy way of avoiding an inconsistency in the currentKeys global variable, because it relies in behavior that is very much platform dependent, and is doomed to cause trouble in the future. My conclusion is that it is best to remove this functionality since it was most likely used by a single person in the world, and causes everyone else to have issues with the interface.

Fixed by commit 609798cdb2