[Mac] Holding letter key on keyboard does not show letter variations

[bjoernm]

Normally, holding a letter key in any text field on Mac OSX opens menu showing letter variations such as diacritics for non-english letters.

This can generally work in a contentEditable (the screenshot is taken from a contentEditable on this web page). However, it does not work in Prosemirror. Pressing a letter key longer has no effect.

[marijnh]

This is caused by the way ProseMirror handles keypress events. I guess the browser only shows this menu on direct text input, which we're not letting through.

CC @johanneswilm : Here's another interesting problem in the way an editor has to deal with browser events. Even though keypress provides all the information about intent that we need, overriding it still breaks browser behavior. Not sure what a solution would look like. Maybe a variant of preventDefault that signals 'I handled this, but in a way that resembles the default behavior'. But yeah, that's probably not going to happen anytime soon.

[johanneswilm]

I see. yes, this is an issue. This looks like some type of IME-derivative. We will need to take this to the W3C Editing taskforce.

[WesleyKapow]

Just tried this, I can get the popup menu within prosemirror, but selecting the letter results in odd behavior. Sometimes it works and sometimes it replaces the wrong char either before or after the letter I was working with.

Same issue as posted here: #96

[masayuki-nakano]

This looks like some type of IME-derivative.

Yes, it's actually an IME. If preceding keydown event's default is prevented, browsers shouldn't send the key event to IME.

[johanneswilm]

@masayuki-nakano: What if one wants to let the IME happen? Is there a compositionstart event before the keypress event that one can listen so that the JS knows not to handle the keypress event?

Even if this is currently not easily handled if one listens to keypress events, can we figure out a way to handle this once we use the beforeinput event?

[masayuki-nakano]

@johanneswilm unfortunately, web contents don't receive any composition events with it since the behavior is much odd even for Cocoa applications.

The operation causes a lot of "keydown" events without keypress events except first one because the IME consumes the NSKeyDown events after web contents handle "keydown". And when user chooses one of the characters in the popup, the IME selects the first character's range and calls insertText with committed character. So, the IME does not use marked range. That's the cause of browsers don't fire composition events.

When insertText is called, Safari and Chrome just fires textInput event. Firefox fires keypress event whose code value is empty string. (Of course, those of them are not fired between keydown and keyup.)

I think that UIEvents should define that browsers should fire a set of composition events when text inserts without physical key press. And all browsers should fix the behavior. (beforeinput event is also available if browsers will implement it.)

[marijnh]

This is fixed now (by letting the browser behavior go through unobstructed for regular typing).