Any Key Triggers Inline Editing

MrNazgul

Problem:
When using Editor with KeyTable, pressing most any key will trigger inline editing. I noticed this when I used my "Next Song" media key and happened to have a cell focused. I would think it to be more logical for alpha/numeric/symbol keys to initiate an edit as well as {Enter}, {Backspace}, {Spacebar}, and {Del}. I've experimented and it works with a surprising number of keys including the following:

Problematic Keys:
{Num Lock}, {Caps Lock}, {Scroll Lock}
{F1}-{F12}
{PAUSE}
{INS}
Various media keys including Right Context Menu, Vol+/-, Mute etc.

You get the idea.

Example:
You can see this behavior on this page:
KeyTable

I have looked at key for KeyTable since documentation states it will pick up keys that are not handled by KeyTable. I don't get callbacks for the various navigation keys like {TAB}, {Arrows}, {HOME}, {PgUp} but I do get callbacks with the problematic keys listed above. By this point the inline edit has already been triggered.

Workaround:
It's easy to workaround this in the key callback by filtering what keys I expect to trigger inline editing and using close() for anything else. I figured at some point it would make sense to have a more logical baseline for what keys would initiate an inline edit.

I'm positive this will land far down on one of your lists (as it should being there's a workaround) but just throwing it out there.

allan

Thanks for posting this! I'll get it fixed for the next release of KeyTable.

Allan

MrNazgul

@allan I had some additional thoughts that may warrant bearing in mind relating to this fix.

As I mentioned, the key documentation seems to indicate this callback should get fired off only when a key is pressed that Key Table doesn't consume. Based on behavior I see, this seems to mean the navigation keys ({Arrows], {Tab}, {Home}, {End}, {PgUp}, {PgDn}). I think this is reasonable, though there is a bit of goofiness using {Shift+Tab} to navigate in reverse as the {Shift} key will trigger the key, but such things are difficult to avoid.

I'm presuming (and hoping) you're not going to add {Enter}, {Backspace}, {Spacebar}, and {Del} to get swallowed up by Key Table. I indicated above those would seem to be reasonable keys that could begin editing a cell as they already do. I also think it's reasonable that they continue to show up in the key so that things like originalEvent.preventDefault() can be done. I make use of this to prevent users from deleting out dates by pressing {Del} or {Backspace} when a cell is focused but an inline edit isn't in progress.

My two cents. If you decide differently, I'm hoping there will be a type of key created on the Key Table level to allow us to intercept keys that would be consumed by Key Table in order to tweak behavior.