Typing :) shows :( on non-US keyboard layouts

(Marco) #1

When I start to type a colon : it appears a popup with the available emoji.
Then I type the open parenthesis ) to make the smile, but it shows the frowning icon, here’s a screenshot:

If I select the proposed icon, the text is :frowning: and in the preview I see the frowning icon :frowning:

Typing :-) suggests :frowning: emoji
(cpradio) #2

I can’t repro this…

(Jens Maier) #3

Hm, this technically isn’t a bug, but the feature is designed badly.

Basically, one part of the code sees :) and pops up the autocomplete list and filters it by the open parentheses (and for whatever reason finds frowning as the best match) – while another part of the code sees :) and straight up replaces it with the :slight_smile: emoji.

Instead of putting a bandaid on this glitch, it’d be better to improve the ASCII emoji feature, integrate the ASCII-code list with the regular emoji list and perhaps make it customisable…

@cpradio: I can…

(David Maxwell) #4

You know they’re going to ask for repro steps (I can’t get to happen either - I always get smile)

(Jens Maier) #5

I’m guessing it’s a property of the browser’s locale settings.
Right now I’m using Chrome 38 64-bit on Windows 8.1 and window.navigator.language is "de".

(Marco) #6

My Chrome’s language is “it”

(Marco) #7

Setting windows locale (keyboard) to ENG it works (if you can find the colon on the scrabled up keyboard):

You have to speak English, if you want to smile. Subliminal.

(Erlend Sogge Heggen) #8

I reported this issue once as well, but I can’t recover the thread. It might have been deleted. I’m on a Mac with English language but Norwegian keyboard.

Edit: Just switched to U.S International keyboard, and the smiley shows correctly.

(Martin Anselm Meyerhoff) #9

I can confirm the behaviour on Ubuntu GNOME 14.04 with German keyboard: I type :) and get :frowning: as my first autocomplete option and :slight_smile: (as intended) in the preview. My first thought was the location of keys: ) on the German keyboard has the same location as ( on the English one. This happens on both Chromium and Firefox.

If one just keeps typing, the smiley stays. If you press “Enter”, though, you end up with just the opposite of what you want.

(Martin Anselm Meyerhoff) #10

So… I’ve looked at the source, and the thing is that autocomplete code uses raw character codes to get the character at hand. When you’re pressing shift, some magic happens that is confined to the English-speaking world. This is actually somewhat complicated as now, in 2014, it still seems to be necessary to map characters to keycodes manually… I am happy to prepare a PR for this, but I need to be nudged a little:

Is there a particular reason the autocomplete widget needs

  • to bind to both keypress and keydown events?
  • Could all of this be implemented using just the change or input events?

I realize this is cross-browser superfun.

(Jakob Borg) #11

That’s awesome! How does it cope with Dvorak and similar?

(Sam Saffron) #12

change and input is too slow. you would only get an event on release.

(Martin Anselm Meyerhoff) #13

Could this be a fix for this?

(Jeff Atwood) #16

This fix was buggy and had to be reverted as it broke stuff. Anyone want to try again?

(cpradio) #17

Just to bring everyone up to speed on where the bugs lie with the combination of changes in this thread + the fix in the following thread.

There is a small cursor issue that is now preset, that doesn’t exist in the current implementation. At least the smilies aren’t overly aggressive anymore (when the two commits are combined).

(Martin Anselm Meyerhoff) #18

There’s a third issue, which hasn’t been addressed by the fix: Backspacing into an autocompletable word didn’t open the autocomplete on Firefox only. I’d volunteer to re-do the fix more carefully, only moving those bits of code that actually mess up the smileys.

I wouldn’t write tests for this, as I don’t know how to write good integration tests in JS/discourse (sorry @sam!). Also: I’m not so sure about the actual requirements, like what fields the plugin acts on. The most prominent place where this bit of code is used is for smileys and mentions in textarea.wmd-input fields. I’ve looked through the source and I actually think all autocompletes on <input> fields are handled by something else. If someone can confirm this suspicion, I would volunteer to remove the code that handles this non-existent case in a subsequent PR.

(Sam Saffron) #19

The general fix here is quite simple and low risk.

Instead of mucking around and trying to construct a string from key codes, debounce a function that checks the actual value in the box and acts based on it.

I would be happy to accept something along these lines.

(Martin Anselm Meyerhoff) #20

Here you go:

Note: Losing focus on clicking somewhere outside the autocomplete box, an issue referenced in the “aggresive emojis” thread, is not addressed in this PR, as it’s a different bug.

(Martin Anselm Meyerhoff) #21

But that would only work after the keypress is handled (and the text appears in the box), so i’d have to add a new “change” or “input” handler. The PR below minimally moves the recognition what character we’re dealing with to the safer keypress handler - and that’s it.

(cpradio) #22

Agreed, I can repro that here on Meta easily, so it definitely isn’t related to any of your prior PRs :smile: