希哲9年,Google Chrome 開発者が提唱。
希哲12年,普及が始まる。
領下手定め環境で概ね問題なさそうだったため,新生全知検索整備の中間出振るいに踏み切った。首尾良く完了し,大成功だった。これにより後縁も最新の状態で同期され,自由自在な開発体制を取り戻した。
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 を使った。また定期的に舞覧手定めの時間を作りたい。
待っ読小窓にも輪郭一覧動的更新で消えない問題が残っていたため修正。出振るい済み。
領下手定め環境でも Let's Encrypt 証明書を導入した。
希哲14年から HTTPS 統一の一環で領下では自己証明書を利用していた。初回握接時の舞覧の警告は,一つの舞覧なら大した問題ではないが,舞覧や端末を切り替えながらの手定めは煩雑だった(最近は dnsmasq の導入でその機会も増えていた)。また,開発者通類の梱装で制危関連の警告が多量に出力されたり,PWA など厳格な制危を要求される手定めが出来ないなどの問題があった。
更新と,なんとなく認証も面倒臭そうだと思っていたが,希哲12年から使っている via 迂回と DNS 認証の相性が良いことに気付いた。実際,いつもの DNS 認証であっさり取得出来た。まさか4年前の発明がこんなところに活きてくるとは思わなかった。更新の問題はあるが,警告などの煩わしさに比べればあってないような手間だ。
昨日離立された Google Chrome 89 からオフライン対応していない PWA で警告が表示され,Chrome 93 で引装不可になるらしいので,デライトのオフライン対応について軽く検討して終了。
最初は余計なことをしてくれるなと思ったが,中途半端な状況にある PWA への認識が変わるきっかけになる可能性もあり,ちょうどデライト高速化に取り組みたい時期とも重なるので,この流れも味方につけたいところだ。
オフラインで描出出来るようにした場合,同期機構についてもよく考えておかなければならない。出与え消失など,メモアプリにおいて同期は最も深刻な不具合が起きやすい部分でもある。
オフライン状態の表示には上部ページャーの新着確認部が使えると思ったが,これは昨年10月21日の開発ですでに考えていた。