Keyboard shortcuts changing screening when typing comments#559

When I have the keyboard shortcuts on for screening, it sometimes reads my typing in the comment box as a screening decision. I think it happens when I start with an @ and it chooses the 2nd exclusion reason, but I’m not sure that’s the only time it happens. I’ve been switching it back with no problem, but wanted to flag since it’s not ideal! Thanks!

Darn, we were so careful when adding hotkeys to make sure input elements didn’t do this. It’s totally possible this is uniquely tied to mention input in our comment box. I’ll try to repro and we’ll get a fix out ASAP, since this could subtly alter your review. Thanks a bunch for the heads up!

Frustratingly, I can’t reproduce this after a fair bit of playing around with comments + hotkey screening, like hitting the @ and numbers rapidly in succession.

I don’t want to bore you with too many details, but we implemented hotkey screening by 1. listening for any i/a or 1-9 key events on AutoLit screening pages 2. ignoring those key events whenever your cursor is inside an input element (<textarea> and <input> html elements, and a couple other cases where we weren’t able to use those html elements for input), since those key presses don’t indicate intent to screen.

So, the ways I could anticipate this failing are:

1. A “race condition” where the check in (2) occurs at the exact moment cursor focus is jumping from the comment <input> to the mention search <input> (I have to admit that I’m not sure about the “transactional” nature of cursor focus and if it would even allow for this to occur).
2. Your cursor is not focused on an input element (e.g. you might be hitting the escape key prior to hitting @). Your bug reports are so consistent I really doubt this is the case, but just wanted to check.

Some questions that will challenge my assumptions and help me understand:

1. How consistently can you reproduce this bug?
   1. Does it occur in the Screening module, Inspector, or both?
   2. Are there any specific chain of actions (e.g. rapid or press-and-hold key presses) or surrounding conditions (e.g. editing a comment vs creating new) that seem to trigger it more consistently?
2. Does it happen for anything other than @ / 2 when intending to add a mention?
   1. Does it ever trip for the i/a hotkey?
3. Are you in a browser other than Chrome or Firefox? (what I tested in)

One course of action we can immediately take, if this just relates to @ key presses, is to detect when any other key is simultaneously pressed, so that @ isn’t treated like a 2 in the first place.

Alright, persistence was critical– I can get this to spottily occur if I spam 2 with a Shift mixed in every once in a while! It is behaving like a race condition on the deadspace between the cursor jumping from the comment input to the mention input. I suspect we’ll have to get crafty with a solution for this, so before I forge ahead, I’d love to know if this occurs for anything besides mentions & my hypothesis is wrong. Thanks!

1. I think I’ve only had it occur in inspector in the screening tab, not in the screening interface, but I’m not sure
2. It does seem to only trigger at the beginning of a comment, but that’s also usually when I’m hitting 2/@
3. I’ve only noticed it hitting shift+2 at the beginning of comments to @ someone, I’ve never noticed it on the i/a or typing other numbers in the middle of a comment. The @ symbol does get typed in the comment box
4. I’m using Chrome

Thanks for your persistance in debugging! I’ll keep a closer eye out for any other behaviors now that I know to look and let you know if any come up!