Quick Open: arrow keys don't work with certain German keyboard

[marcelgerber]

Steps:

1. Launch brackets
2. Press Ctrl+Alt+O to Open "Quick Open"
3. Type any file title (there should be more than one result)
4. Press arrow up and arrow down to focus another entry
5. Focus the second entry for example (not the first!)
6. Press enter to open the file

Results:
At step 4, the visual focus (blue) of the element flashes shortly, then it returns to gray.
Also, the cursor jumps from the beginning (arrow-up) to the end (arrow-down) of the input field.
At step 6, the file mentioned in the first entry is opened every time - no matter what you really have selected

If you do this with the mouse, everything works just fine.

Expected:
The entries can be selected and entered with just the keyboard

ENV: Windows 8 German
Build: 0.31.0-9569 (On branch sprint-31-hotfix,sprint-31-hotfix dd28c6a), 0.32.0-0 (master a6f426c99) -- (both tested)
Tested with extensions disabled

[peterflynn]

I can't reproduce these problems on Win 7 at work or Win 8 at home. (Except for the cursor jumping when you hit the up arrow, which I think is a known issue).

Also @SAplayer I assume you meant Ctrl+Shift+O, right? If not, do you have some sort of keyboard shortcut customizer extension running? It would be good to see if these problems occur with all your extensions disabled. (You can do that via Help > Show Extensions Folder and then temporarily moving everything from "user" into the "disabled" folder).

[peterflynn]

Oops, I see you already tested with extensions disabled. It seems unlikely this is due to OS locale, but... do you have access to another German Windows machine to see if it occurs there? Or alternatively to a non-German machine to see if it doesn't occur there?

You could also put a breakpoint in _handleItemSelect() in the QuickOpen module and see when DOM node it thinks is selected.

Also, make sure this occurs on the very first launch of Quick Open, e.g.:

1. Quit Brackets
2. Launch Brackets
3. Ctrl+Shift+O
4. Type something, e.g. "foo"
5. Press Up arrow
6. Press Down arrow
7. Press Enter

Do those steps open the wrong file? If not, what other steps do you need to do first? (There might be some precursor steps that get Quick Open into a bad state).

[marcelgerber]

Yes, I meant Ctrl+Shift+O, sorry for that.
This afternoon (in germany it's currently 7am) I can test it on another win machine (Vista, german).

[marcelgerber]

It works on my old computer (vista, german), but as I said it works not on my normal pc (just restarted and so on...)

As I logged events with console.log(selectedItem); within QuickNavigateDialog.prototype._handleItemFocus, I found that this function is called twice for every keydown: The first one is the expected one, the second one jumps back to the first file every time. But I can go to the third or fourth entry without much problems (it flashes for a short time).

Is there maybe anyone who has a similar problem?

EDIT: Okay, I've tested a bit more and my result is, that the failed second call comes from QuickNavigateDialog.prototype._handleShowResults, the first call is right (probably from .bind()).

EDIT 2: With console.log($(".smart_autocomplete_highlight").length); in QuickNavigateDialog.prototype._handleShowResults I see that the lenght is 0. I think this shouldn't happen and I'm sure this is the reason for this behaviour.
But I unfortunately can't do anything without your help because I don't even know where smart_autocomplete_highlight is used.

[marcelgerber]

Okay, I just found the reason but I don't know if I can fix it myself (I will try tomorrow):
The _handleShowResults in QuickOpen.js is called between the itemUnfocus and the itemFocus event in jquery.smart_autocomplete.js, so for a short time there is no element matching ".smart_autocomplete_highlight".
I don't know if this is an issue caused by jquery.smart_autocomplete.js or QuickOpen.js, but I will try to fix it soon.

[marcelgerber]

Ok, I just tested this with a Win7 (german) pc, it works and I only get _handleShowResults when I type, but not when I focus an entry. So this IS the problem. On my "normal" pc (I haven't got access to it until sunday...) _handleShowResults is also called when the focus changed.
I don't know why this behaviour only happens to me, but if it hasn't been fixed until sunday I will make further tests and logs within jquery.smart_autocomplete.js.

It seems to be a problem in there, but I'm sure it can also be fixed within brackets.

[marcelgerber]

Ok, now it gets weird.

I have tested it with some more console.log(). The most important is this one:

         if(current_char_count >= options.minCharLimit){
            console.log("Trigger keyIn from keyup (else): " + ev.keyCode);

(just search for the first line to find it).
I looked into the console and found this: Trigger keyIn from keyup (else): 255
I searched for the js keycode 255, but I haven't found it (I just found some who say, that this happens on Ctrl+C or Ctrl+V, but I don't do that, I just press arrow down).

But I gets weirder:
I plugged in another keyboard an IT WORKS! I don't know what happened to my normal keyboard (it's a laptop keyboard), but with it doesn't work!

Can anyone please help me fixing this? Can this be fixed within brackets or must smart-autocomplete be updated?

EDIT: Just pushed to the original repo, hope it will be fixed soon

[pthiess]

@dangoor - you got it.

[marcelgerber]

I hardly know anything about submodules, so my question is: Can we run code that is not in the main repo (to fix this issue)?
The current version doesn't works, it would only work with laktek/jQuery-Smart-Auto-Complete#29.
Or could we use anything else (maybe something own) as it is mentioned in QuickOpen.js#33 and #333?

[dangoor]

@SAplayer submodules refer to an external repository at a given commit, so we can't patch our copy alone the way we have things set up. We could fork the original repository and change our submodule to report to that if we had to.

Ultimately, as you noticed, we'd like to migrate to a cleaner autocompletion mechanism.

[marcelgerber]

Yes, maybe we can take a fork of the current submodule as a base to edit it to our preferences.

But this has no priority as it seems this only happens to me.

[njx]

FYI, see the comments in #4791 - we're going to go ahead and pull smart-autocomplete into our repo and fix the keydown/keyup issue you noted. Once that's merged, if you'd like to look into this further, please do.

[marcelgerber]

I've read along as long as it existed - silently.
I like the idea of pulling our own version out.

FYI, in the current version of smart autocomplete, this bug is already fixed. And if you want me to, I can create a PR to pull smart autocomplete in.

[njx]

Yup, I just noticed that you had submitted a patch previously. I'll take care of pulling it in. Thanks.

[marcelgerber]

Yes, it works! (with #5872)

[njx]

#5872 is merged into master now, so closing this - let us know if you're still seeing it.