Mastodon の検索ボックスが動かなくなった件、どうも fcitx-skk を使用中に commit-unhandled 経由で流した \n コマンドが届いてないっぽいということがわかった (gnusocial (qvitter) の検索ボックスでも同様の問題が起きた)
fcitx-skk でなく fcitx での直接入力を使うとちゃんと Enter イベントが通るので、不思議
普通の1行ボックス (github の検索とか)は Enter そのまま通るので
SKK は英字入力もそのままできるせいで常時 SKK 有効化していたんだけど、さすがにこのレベルの (xim レイヤーの)バグを直す知識はないので、入力メソッド OFF のホットキーを用意することで運用で対処しようと思う
今のところ C-j と Muhenkan を入力メソッド有効化に割り当ててるので、 C-S-j と Shift-Muhenkan を入力メソッド無効化に割り当てた
事実:
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) が渡されることってあるかな？
javascript 経由で何かあると駄目なのかなと思っている