Summary: | [GTK] Can't type back-ticks and accents in Riot | ||
---|---|---|---|
Product: | WebKit | Reporter: | Philippe Normand <pnormand> |
Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED INVALID | ||
Severity: | Normal | CC: | aperez, bugs-noreply, cgarcia, jordi, psaavedra, rniwa |
Priority: | P2 | ||
Version: | WebKit Nightly Build | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
URL: | https://github.com/aperezdc/revolt/issues/94 |
Description
Philippe Normand
2019-07-29 01:57:36 PDT
It works for me. Please check with Riot-web 1.3.0. See also this issue: https://github.com/vector-im/riot-web/issues/7440 Which was closed :) Actually the fun moved to https://github.com/vector-im/riot-web/issues/7665 I can reproduce with recent riot 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. (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. (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. (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 (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 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 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. Yep, I confirm this issue is specific to GTK. Can't reproduce the problem if I use WPE/Cog. 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. (In reply to Carlos Garcia Campos from comment #14) > [...] > > So, I would say it's a bug in stale. The problem is that only affects us, > for now at least. Slate has gotten a major rewrite which has solved this issue (and many others as well), and today Slate works fine on WebKit-based browsers. On the other end, Riot now has its own input editor widget which *also* works perfectly on WebKit-based browsers. All in all, I think we can close this. (In reply to Adrian Perez from comment #15) > (In reply to Carlos Garcia Campos from comment #14) > > > [...] > > > > So, I would say it's a bug in stale. The problem is that only affects us, > > for now at least. > > Slate has gotten a major rewrite which has solved this issue (and many > others as well), and today Slate works fine on WebKit-based browsers. For the sake of completeness, here are the changes in Slate which fixed this: https://github.com/ianstormtaylor/slate/pull/3093 =) |