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 で処理しているのは
github.com/fcitx/fcitx-skk/blo
この部分で、たとえば commit-unhandled 等でパススルーされたキーイベントは process_key_event() が false を返すから、 IRV_TO_PROCESS で fcitx-skk (fcitx) が処理せずイベントを素通しすることになる。
つまり、 fcitx-skk 自体は妥当なことをしているように思われる。

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

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

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

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

Follow

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

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

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

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

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

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

C-S-a みたいな modifier key がある場合の扱いがややこしそうということに気付いてしまった、つらい

パッチ書けたのでローカルで動作確認してからプルリク投げます

思ったより条件が厄介そうだったのでもう少しかかる……

Let key release events pass through by lo48576 · Pull Request #52 · ueno/libskk
github.com/ueno/libskk/pull/52

結局完璧な方法が思い付かなかったのでかなり妥協して、リリースイベントを全て素通しさせることにしました。
このパッチを使えば、 google のサジェストでの上下キーや Mastodon の検索ボックスでの Enter キーなどが正しく動きます

Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!