Bug 200221 - [GTK] Can't type back-ticks and accents in Riot
Summary: [GTK] Can't type back-ticks and accents in Riot
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL: https://github.com/aperezdc/revolt/is...
Keywords:
Depends on:
Blocks:
 
Reported: 2019-07-29 01:57 PDT by Philippe Normand
Modified: 2019-08-30 03:23 PDT (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Philippe Normand 2019-07-29 01:57:36 PDT
Using a keyboard with Spanish layout in Matrix Riot web-app, characters like `éà can't be typed in the message composer. Safari works fine so I assume this is a bug in the GTK port input methods handling?
Comment 1 Carlos Garcia Campos 2019-07-29 02:13:10 PDT
It works for me.
Comment 2 Philippe Normand 2019-07-29 02:18:19 PDT
Please check with Riot-web 1.3.0.
Comment 3 Philippe Normand 2019-07-29 02:19:02 PDT
See also this issue: https://github.com/vector-im/riot-web/issues/7440
Which was closed :)
Comment 4 Philippe Normand 2019-07-29 02:20:20 PDT
Actually the fun moved to https://github.com/vector-im/riot-web/issues/7665
Comment 5 Carlos Garcia Campos 2019-07-29 02:31:04 PDT
I can reproduce with recent riot
Comment 6 Adrian Perez 2019-07-29 02:40:37 PDT
For the sake of completeness, some more observations using a
Spanish (Spain) keyboard layout:

 * Writing letters with accents like ‘á’, composed by ‘'’ (dead) + ‘a’:
   - Works in Firefox and Chromium.
   - Does not work in WebKitGTK.

 * Writing a plain backtick ‘`’, composed by ‘`’ (dead) + space:
   - Does not work in Firefox, nor Chromium, nor WebKitGTK.

Probably needs better testing/investigation, but this difference makes
me think that there might been some special-casing in the text editor
widget to fix some cases but not a proper solution which would always
handle things correctly. The bug for the Slate editor is this one:

  https://github.com/ianstormtaylor/slate/issues/2368

On the other hand, I cannot tell at the moment whether it only Slate
at fault here, or whether there may be something we need fixing on
our end.
Comment 7 Adrian Perez 2019-07-29 02:43:46 PDT
(In reply to Adrian Perez from comment #6)
> For the sake of completeness, some more observations using a
> Spanish (Spain) keyboard layout:
> 
>  * Writing letters with accents like ‘á’, composed by ‘'’ (dead) + ‘a’:
>    - Works in Firefox and Chromium.
>    - Does not work in WebKitGTK.
> 
>  * Writing a plain backtick ‘`’, composed by ‘`’ (dead) + space:
>    - Does not work in Firefox, nor Chromium, nor WebKitGTK.

Forgot to mention: I get the same behaviour in X11 and Wayland (tried both
with GNOME Shell and the Sway compositor), so I think we can tentatively
say it is not a problem of a particular windowing system.
Comment 8 Jordi Mallach 2019-08-02 03:54:00 PDT
(In reply to Adrian Perez from comment #6)
>  * Writing a plain backtick ‘`’, composed by ‘`’ (dead) + space:
>    - Does not work in Firefox, nor Chromium, nor WebKitGTK.

FWIW, this works for me in FF. I see no glitches or problems in FF at all.
Comment 9 Pablo Saavedra 2019-08-04 03:20:16 PDT
(In reply to Philippe Normand from comment #3)
> See also this issue: https://github.com/vector-im/riot-web/issues/7440
> Which was closed :)

The issue is related to slate (the framework used by Riot to implement the rich text entry). 

I can reproduce the same behaviour with the back-tips in https://www.slatejs.org/#/rich-text
Comment 10 Pablo Saavedra 2019-08-04 03:50:12 PDT
(In reply to Pablo Saavedra from comment #9)
> (In reply to Philippe Normand from comment #3)
> > See also this issue: https://github.com/vector-im/riot-web/issues/7440
> > Which was closed :)
> 
> The issue is related to slate (the framework used by Riot to implement the
> rich text entry). 
> 
> I can reproduce the same behaviour with the back-tips in
> https://www.slatejs.org/#/rich-text

There are a couple of open issues in the upstream code:

* https://github.com/ianstormtaylor/slate/issues/2781
* https://github.com/ianstormtaylor/slate/issues/2368
Comment 11 Pablo Saavedra 2019-08-04 23:53:48 PDT
(In reply to Pablo Saavedra from comment #10)
> (In reply to Pablo Saavedra from comment #9)
> > (In reply to Philippe Normand from comment #3)
> > > See also this issue: https://github.com/vector-im/riot-web/issues/7440
> > > Which was closed :)
> > 
> > The issue is related to slate (the framework used by Riot to implement the
> > rich text entry). 
> > 
> > I can reproduce the same behaviour with the back-tips in
> > https://www.slatejs.org/#/rich-text
> 
> There are a couple of open issues in the upstream code:
> 
> * https://github.com/ianstormtaylor/slate/issues/2781
> * https://github.com/ianstormtaylor/slate/issues/2368

In https://www.slatejs.org/#/input-tester you can see how slate gets the keycode as undefined in WebKitGTK but OK in other browsers like Chromium
Comment 12 Philippe Normand 2019-08-05 08:09:29 PDT
That's funny, I have locally added composited-characters support in GstWPE and the editor now works as expected, as opposed to WebKitGTK.

The core issue might be related with a bug in the way the GTK WebView widget deals with its GtkImContext.
Comment 13 Philippe Normand 2019-08-06 00:36:32 PDT
Yep, I confirm this issue is specific to GTK. Can't reproduce the problem if I use WPE/Cog.
Comment 14 Carlos Garcia Campos 2019-08-30 03:23:54 PDT
It seems the problem is that slate is handling beforeinput and preventing the default implementation of insertFromComposition typing command. 

The reason why characters with accent work in other browsers is because they are not handled by the input method, the sequence is sent to the editor "Dead" "Quote" + "a" "KeyA" for example. GTK input method handles those cases and results is sent to the editor as final composition results using the insertFromComposition command. 

Any other composition will fail too, for example  CTRL + Shift + u + 0061 -> "a", but still works in other browsers (at least chromium and firefox). In this case the reason seems to be that other browsers don't implement the Input Events Level 2 for IME composition (See https://www.w3.org/TR/input-events-2/#event-order-during-ime-composition). So, they use insertCompositionText for all the composition and the final result result too. We use insertFromComposition for the final results.

I haven't been able to try it out in mac because I don't know how to write composed strings there.

So, I would say it's a bug in stale. The problem is that only affects us, for now at least.