普通の1行ボックス (github の検索とか)は Enter そのまま通るので

SKK は英字入力もそのままできるせいで常時 SKK 有効化していたんだけど、さすがにこのレベルの (xim レイヤーの)バグを直す知識はないので、入力メソッド OFF のホットキーを用意することで運用で対処しようと思う

今のところ C-j と Muhenkan を入力メソッド有効化に割り当ててるので、 C-S-j と Shift-Muhenkan を入力メソッド無効化に割り当てた

分析と思い付き #らりおメモ #らりおメモTODO

事実:
Enter のみならず、上下キー等も反応しない場合がある。
javascript 使ってるらしき場合特にそうで、典型的には google のサジェストとか Mastodon / gnusocial (qvitter) の検索ボックスなど。

これらは fcitx の直接入力自体ではうまくハンドルされているので、 fcitx-skk か libskk が良くない処理をしていることを疑うべきである。

fcitx-skk で処理しているのは
https://github.com/fcitx/fcitx-skk/blob/abedca1fd37cf47a462d728b2afca514d708e05c/src/skk.c#L556-L566
この部分で、たとえば commit-unhandled 等でパススルーされたキーイベントは process_key_event() が false を返すから、 IRV_TO_PROCESS で fcitx-skk (fcitx) が処理せずイベントを素通しすることになる。
つまり、 fcitx-skk 自体は妥当なことをしているように思われる。

さて libskk の該当部分はこれ
https://github.com/ueno/libskk/blob/master/libskk/context.vala#L499-L511
で、フィルタを素通りしたキーイベントについて、モード等に応じて適当なイベントハンドラを呼び出す形になっている。
process_key_event_internal は最近読んでいたし基本的には該当のモード (state) のハンドラに丸投げするだけなので、 filter_key_event を疑ってみる。

https://github.com/ueno/libskk/blob/master/libskk/context.vala#L203-L207
デフォルトのフィルタは state スタックの一番上から持ってきているが、デフォルト(スタックの一番底)は
https://github.com/ueno/libskk/blob/master/libskk/context.vala#L230
このように設定されている。

State の初期値はあまり関係なかったわ……
https://github.com/ueno/libskk/blob/d5df1624942f97d39ca8f76102e56ee4d6a7302d/libskk/context.vala#L203-L207
フィルタは typing_rule として保持されているから、 Rule の該当処理のデフォルトを見る。

https://github.com/ueno/libskk/blob/d5df1624942f97d39ca8f76102e56ee4d6a7302d/libskk/rule.vala#L170-L181
この辺でデフォルト設定の候補というかプリセットみたいなのを用意して、
https://github.com/ueno/libskk/blob/d5df1624942f97d39ca8f76102e56ee4d6a7302d/libskk/rule.vala#L216-L227
ここで処理。
フィルタが明示的に用意されなければ、 "simple" ルールが使われるように見える。

"simple" として使われるルールは
https://github.com/ueno/libskk/blob/d5df1624942f97d39ca8f76102e56ee4d6a7302d/libskk/key-event-filter.vala#L55-L67
このクラス。
https://github.com/ueno/libskk/blob/d5df1624942f97d39ca8f76102e56ee4d6a7302d/libskk/key-event-filter.vala#L60-L62
ここにコメントとともにあるように、キーの開放(押し上げ)が無視されている。

これは明らかに怪しい。
javascript での入力ハンドリングにリリースイベントを使っているとしたら、 libskk 側でそれが握り潰されていることが考えられそうだ。

https://github.com/ueno/libskk/blob/d5df1624942f97d39ca8f76102e56ee4d6a7302d/libskk/context.vala#L507-L509
リリースイベントが無視されて null が返却されると、 process_key_event() 自体は true を返す。これはイベントが libskk によって消費されたことを意味しており、結果 fcitx-skk から元のアプリケーションにイベントが伝達されることはない。

つまりこれがバグの正体だ。
本来、 libskk 側で状態変化が発生しない場合のキーイベントは素通しさせるべきだが、 libskk のデフォルトフィルタでは無条件にリリースイベントを捕獲してしまっているので、これを修正してやれば良いということになる。

……ということで、今からパッチ書きます

リリースイベントを無条件に素通しさせると、 libskk で処理済のイベントをアプリケーションが改めて入力として受け取ることになって二重になるから、「 libskk で処理されなかったイベントの release のみ素通しする」ことが必要になる。
ということは、「RELEASE でなかった直前の同種イベントが libskk によって処理されたか」を記憶しておく必要がありそうかな？

libskk 側に、あるキーイベントの RELEASE より前に次のキーイベント(非 RELEASE) が渡されることってあるかな？

普通にありえそうなので想定しておこう