Code hints can handle Enter key even after they should dismiss

[njx]

1. Open a JS file in the brackets project
2. At the top of the file, type foo.
3. Wait for default guessed code hints to appear
4. Quickly type a; and hit Enter immediately afterward

Result: you get foo.abort; (or some other guessed code hint beginning with a)
Expected: since you typed ; before hitting Enter, the code hints should have dismissed and not processed it.

[njx]

There seems to be a timing issue where, if code hints are lagging due to a large project, they still handle keys even after the hint menu should have been dismissed by a non-matching character. I ran into this a couple of times today and it made code hints feel really flaky.

[njx]

To @dangoor, medium priority, nominating for sprint 31.

[redmunds]

@dangoor I can take this one if you haven't fixed it, yet.

[dangoor]

@redmunds go for it!

[redmunds]

Using console.log() statements, I verified that ; key event comes before Enter key event, and item from hint list is incorrectly entered into page. I am not quite sure how to fix this.

Problem is that CodeHintList.prototype._keydownHook needs to make a synchronous decision whether or not to handle Enter key while there is an asynchronous editor update happening. CodeHintList can cache which key(s) were pressed, but can't create a Deferred object (or possibly an array) and wait to process Enter key when it's resolved -- it needs to decide now, so it can indicate to caller whether key was handled.

Possible solution: append cached text (e.g. ';') to code hint filter (e.g. 'a') to see if resulting text (e.g. 'a;') is in current hint list?

[njx]

Yes, this is tricky and there isn't an easy solution we can think of. Removing from the sprint since this isn't a new bug, but leaving medium priority.

[njx]

BTW, I like your proposed heuristic of checking the current text against the previous hint list. I actually wonder if that's something that we could get providers to guarantee--i.e., appending a character to text will always narrow the list. (Or have a flag on the provider indicating that it's willing to guarantee that.)

In fact, I wonder if doing that would actually speed things up in common cases, because if the user is just typing, we wouldn't have to re-run the hinter for each new character (or for backspace)--we would just keep filtering. We would only re-run the hinter if the user did some other edit. (But maybe we already do something like this?)

[redmunds]

Nominating for Sprint 32.

[RaymondLim]

FBNC to @njx

[njx]

Yup, seems fixed. Closing.