electron: [Bug]: Electron ignores XCompose settings when running natively on Wayland
Preflight Checklist
- I have read the Contributing Guidelines for this project.
- I agree to follow the Code of Conduct that this project adheres to.
- I have searched the issue tracker for a feature request that matches the one I want to file, without success.
Electron Version
12.0.7
What operating system are you using?
Other Linux
Operating System Version
Arch Linux
What arch are you using?
x64
Last Known Working Electron version
No response
Expected Behavior
-
Start a Sway session.
-
Run
swaymsg 'input * xkb_options "compose:menu"'
to enable XCompose on theMenu
key. (Seeman 7 xkeyboard-config | grep 'compose:'
for keys other thanMenu
that you can use.) -
Put
--enable-features=UseOzonePlatform --ozone-platform=wayland
into your
~/.config/electron-flags.conf
. -
Run the Hash sample Electron app. I.e. do
git clone https://github.com/electron/simple-samples . cd hash npm start
-
Focus on the first input field in the Hash app window.
-
Input symbols using XCompose:
-
Press the following in sequence:
Menu
-
-
-
. It must produce the em-dash symbol in the input field, “—
”. -
Press the following in sequence:
Menu
=
>
. It must produce the double arrow symbol, “⇒
”.
-
Actual Behavior
The last step does not produce any of the expected symbols in the input field. Instead of em-dash it produces three sort minus signs “---
”, and instead of double arrow it produces “=>
”.
Testcase Gist URL
No response
Additional Information
Everything works as expected and XCompose produces “—
” and “⇒
” if I omit the step 3, i.e. run Electron without the --enable-features=UseOzonePlatform --ozone-platform=wayland
options.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 2
- Comments: 24 (5 by maintainers)
Wow that bot is aggressive. When the devs don’t have the time to even notice an issue we have to post every 3 months that the issue did not miraculously fix itself? Sorry, that’s ridicolous.
This issue has been closed due to inactivity, and will not be monitored. If this is a bug and you can reproduce this issue on a supported version of Electron please open a new issue and include instructions for reproducing the issue.
A fix for this has recently been merged upstream (https://crrev.com/c/3207928) and will be included in Chromium 98 (release scheduled for Feb 1, 2022).