search

monkeytypegame / monkeytype

The most customizable typing website with a minimalistic design and a ton of features. Test yourself in various modes, track your progress and improve your speed.
https://monkeytype.com/
GNU General Public License v3.0
15.26k stars 2.32k forks source link

Linux Unicode Input not supported (Ctrl+Shift+U+hex code) #329

Closed precondition closed 2 years ago

precondition commented 4 years ago

The website does not support symbols/letters entered via GNU/Linux's ibus unicode input system.

I am currently on XFCE Ubuntu and if I do something like Ctrl+Shift+U E9space to get the character "é", nothing prints, it's as if I am not doing anything.

Unicode input works in Firefox's fields so the problem isn't in the browser. In fact, unicode input works in most sites except typing tests site. Typeracer.com is the only typing site that I know which supports ibus unicode input.

Unlike issue #36, this does not involve dead keys. It's more of a compose sequence. However, this issue probably falls under the umbrella of #35 as it is an input method requiring multiple keystrokes for a single character.

Miodec commented 4 years ago

Well, to my understanding, dead keys are basically a compose sequence, just with a dedicated, character. Both involve the preprocessor on the input field waiting for all the keypresses before replacing/inputting the character into the field. The issue is that I'm not looking at the input field change, but the raw keypress events.

This will most likely be fixed when I move over to reacting to text field updates in order to fix dead keys.

precondition commented 4 years ago

Speaking of dead keys, I've also noticed that dead keys work if the ibus dæmon is not running but encounter the same problem as described in this issue if I have ibus running in the background.

Miodec commented 3 years ago

Alright, recent update maaaybe fixed this issue. Could you test again?

precondition commented 3 years ago

It types "Process" when I activate unicode input mode with Ctrl+Shift+U and "Process" gets also typed on monkeytype on any of the keypresses consumed by Unicode Mode.

Miodec commented 3 years ago

Shouldn't print Process anymore. Try again

precondition commented 3 years ago

It does not print Process anymore indeed. In fact, it does not print anything at all.

Miodec commented 3 years ago

Yeah, i didnt know if that was going to fix it as I don't understand how this unicode input mode thing works.

SeerLite commented 3 years ago

Alright, recent update maaaybe fixed this issue. Could you test again?

I've got not context from what change happened there but I'm guessing it has to do with adding #wordsInput to allow keys? The thing is IBus doesn't really generate any keypresses:

I discovered this by removing all styling properties from #wordsInput and noticed characters inserted by IBus are shown on the text field, unlike normal normal keypresses which are ignored. image Relevant part of the code.

A way to fix this would be to use characters inserted in the text input instead of using direct keypresses (something like how typings.gg does it). This would be quite the big change though.

Or maybe even better: instead of using only characters from the text input, use keypresses like usual and if at some point a new character is found in the text box, remove it and use it as a keypress.

SeerLite commented 3 years ago

image

Looks like all states are inserted into the text field until pressing space/commiting the final character, where they're replaced with it. I'm not sure how to tackle this.

Edit: I just got a crazy idea that may solve this

SeerLite commented 3 years ago

Well, no luck. I tried:

I'm out of ideas for today. Maybe tomorrow I come up with something smarter.

precondition commented 3 years ago

Edit: Ok actually this does solve the original issue here, but doesn't fix using the keyboard dead key from the layout. (only ctrl+shift+u)

@SeerLite Personlly, I have no issues using dead keys from US INTL (AltGr version on Linux)

SeerLite commented 3 years ago

Oh, I'm using Latin American layout and the accent key (´) and other dead keys are managed by IBus, just like unicode codes. Is that not the case for you (do you not get the underline when you're about to insert them them)?

If not, maybe this fix can work for you! I'd still like to get it working with my layout though haha :s

SeerLite commented 3 years ago

Fun fact, I actually did solve this issue but only on Chrome. Firefox does something different that makes it send the final keypress. This also only happens on monkeytype... Hm

precondition commented 3 years ago

Oh, I'm using Latin American layout and the accent key (´) and other dead keys are managed by IBus, just like unicode codes. Is that not the case for you (do you not get the underline when you're about to insert them them)?

If not, maybe this fix can work for you! I'd still like to get it working with my layout though haha :s

I may have made a misuse of language when I mentioned GNU/Linux's ibus unicode input system in the description of the issue but I don't actually use the IBus dæmon. I only have it installed for the pinyin IME so it's almost always off. I couldn't find what's actually handling dead keys in my OS in my research. It may be something related to Gnome's GTK modules or something (although I use XFCE now). I definitely don't get an underline when I initiate a Ctrl+Shift+U unicode compose sequence like I do when I run the IBus dæmon.

SeerLite commented 3 years ago

Welp, this might or might not fix the issue for you then. Maybe whatever it is that handles the unicode code for you does exactly the same as IBus.

I disabled IBus and tested out the unicode sequence thing (on Firefox) and it doesn't work. It gets sent it directly to the textbox like with IBus, but without the first stage where it replaces the whole thing. (Sorry I'm explaining it terribly here haha.)

Also I just discovered without IBus dead keys don't work at all on Chromium for me like they do on Firefox.

Looks like this is gonna be too complicated to solve for all scenarios. The best way I can see is having different options in the settings for input handling, so users can test them out and use the one that works on their setup. But even just implementing that is gonna be a lot of work...

I'm gonna try to get the current "IBus ON" fix working and then I'll see if I can do anything else.

SeerLite commented 3 years ago

@precondition I made some changes to #753, I wonder if you could test them? You'd need to set up monkeytype locally and pull from my branch. Ask me if you need any help (though I think you know how to use git).

Currently it only works on Firefox (and it's gonna be a pain to get to work on Chrome), so if you test it do make sure it's on Firefox.

SeerLite commented 3 years ago

Alternatively try https://monkeytype-e5da5.web.app/

precondition commented 3 years ago

I have yet to set up monkeytype locally but this web app you linked to at least does not seem to like Ctrl+Shift+U unicode input either

SeerLite commented 3 years ago

If you open the inspector and remove all styling elements from #wordsInput, the text box will be visible. Like this, do you get any characters inserted there when doing the ctrl + shift + u thing?

precondition commented 3 years ago

If you open the inspector and remove all styling elements from #wordsInput, the text box will be visible. Like this, do you get any characters inserted there when doing the ctrl + shift + u thing?

Very sorry for the late reply for I was busy studying for my exams; if I remove all styling, I don't see anything appear there when typing basic keys but I do see some characters appear when I use Ctrl+Shift+U+hex. The unicode characters "stack up" one after another until I press space to move to the next word.

Screenshot Key sequences for the above screenshot: e l l e Ctrl+Shift+U e 9 Space Ctrl+Shift+U e 9 Space Ctrl+Shift+U e 8 Space
eudennis commented 3 years ago

Hello there, I have the same issue with Dead Keys. I noticed that in the https://monkeytype-e5da5.web.app/ version it is working. There any expectation if this https://monkeytype-e5da5.web.app/ will hit the production someday?

SeerLite commented 3 years ago

@eudennis Woah had forgotten about that one! If it's just about dead keys then check out #1325 if you haven't already, which likely fixes it :)

As for Ctrl+Shift+U unicode code input, I don't think I'll be trying to get that working at all in the end as there's just no way to differentiate the inserted "u" with a real "u".

eudennis commented 3 years ago

The #1325 is not implemented yet... right? Or am I missing something?

SeerLite commented 3 years ago

It's not implemented yet but you can test it out here

Miodec commented 2 years ago

The inupt rewrite is live now on the main site. Give it a quick test and let me know.

precondition commented 2 years ago

The input rewrite is live now on the main site. Give it a quick test and let me know.

It works for me now. Closing the issue.

PS: I also tested typing 'é' and 'è' in master mode and it behaves correctly too.