新生全知検索整備・中間出振るい
領下手定め環境で概ね問題なさそうだったため,新生全知検索整備の中間出振るいに踏み切った。首尾良く完了し,大成功だった。これにより後縁も最新の状態で同期され,自由自在な開発体制を取り戻した。
21時30分出振るい作業開始。断帯は21時30分から約5分。23時頃までには一通り点検・不具合修正を終えた。
その後,動作は極めて安定している。dg_fnd()
への輪数取得処理組み込みは今回初出振るいとなるが,高速化効果は,毎回輪数計算が必要になる場合の検索で数十ms(求頼1回分)の短縮なので体感速度向上はあまり期待していなかった。しかし,意外と検索時の軽快感が増している気がする。最初はプラセボ効果に近い開発者心理かと思ったが,自分の全知検索歴と検索頻度を考えれば感じ取れてもおかしくはない。嬉しい誤算だった。
輪符と知番の輪結改良
安心して後縁に手を入れられるようになったので,手始めに,輪符が生成する輪結で,第零番節付き知番がそのまま輪結先などに反映されてしまう問題を修正した。
これにより,輪符の知番が K#9-XXXX/A-YYYY
と記述されていても,輪結先は第零番節の削除をした /?fg=KNo.XXXX/YYYY
や /KNo.XXXX/YYYY
となる。第二次知番改良を経て司組が生成する知番はこれで統一するようになったが,デラングでは大量にある第零番節付き輪符が第零番節付き輪結を生成していたため,クロール効率への悪影響が懸念された。出与え属性を通して輪郭小窓の知番表示にも反映されていたため,用合い上の問題もなくはなかった。
とりあえずは量が多い基本形の輪符と重い強調輪符でのみの対応。
ついでに,再置換問題などで混乱していた時期にいったん無効化していた知番単独での輪結化も復活させた。知番接頭子の越化参照化で上手く行った。
装体は基本的に URL と同じにしたが,文字サイズは0.9emでも若干小さく感じるため1emのままにしておいた。
写し取り機能によるがたつき不具合再修正
16日の開発の「写し取り機能によるがたつき不具合修正」が間違っていたため再修正。
17日あたりから Mac 版 Safari で写し取り機能が働かないという不具合報告を受けて調査したところ,iOS 版 Safari でも働いておらず Safari 共通の問題だったことが判明した。iOS 版 Safari では手定めしたつもりだったが,貼り付け手定めまでしていなかったらしい。
16日の開発での修正が原因であることは明らかだったため,いったん修正内容を取り消し12時20分頃には復旧。改めてがたつき不具合の調査に入った。
当初,一時的に使う入力要素の高さによる問題と誤認して height: 0
にしたが,これが Safari の制限にかかったか(height: 1px
などでも変わらず)。そもそも position: fixed
にしているので高さでがたつくとは考えにくかったが,Safari 固有の描画バグかなにかだと思っていた。
よくよく観察してみると,このがたつきは要素の描画というより,入力要素捕活時の小さなスクロールによるものらしかった。ただ,手持ちの iPhone 7 では,非 PWA の Safari 縦向きで全知検索窓が画面に入る位置でしか再現しなかった。PWA や横向き,LambdaTest の iPhone 12 ではそれらしい挙動はみられず,特定条件下で Safari のウィジェットと干渉しているような気がした。
こうなるとどこまで普遍的な現象か分からないので諦めかけたが,そもそも一瞬とはいえ入力状態に入るのが間違いということに気付き,捕活時は読み取り専用にしてみたら再現しなくなった。結果的に,おまじないのようなものよりずっと理に適った解決策が見つかって良かった。
現状「コピー完了」は写し取り処理実行後,無条件で表示されるようになっているが,これが手定め時に間違った安心感を与えていたのは反省点だ。不具合を除いて写し取り自体の違了は極めて稀であり,失敗したとしても再試行コストは限りなく小さいため実用上の問題ではなかった。
写し取り機能の手定めでは貼り付け手定めまでするようにしていたが,16日の開発ではあれこれ細かい作業をしていたので抜けてしまった。「コピー完了」を確認した時点で安心してしまったのだろう。
この作業で久しぶりに LambdaTest を使った。また定期的に舞覧手定めの時間を作りたい。
その他
待っ読小窓にも輪郭一覧動的更新で消えない問題が残っていたため修正。出振るい済み。