2024/9/21 OSS に不具合報告しまくる
#OSS活動
過去に発見した不具合を報告しそびれているので、報告する。
x ESLint の Linter.prototype.verify()がlanguageオプションを受け付けない問題
from: https://github.com/mizdra/eslint-interactive/pull/362/files#r1741102719
多分 ESLint のバグだと思うので報告しておく
報告した: https://github.com/eslint/eslint/issues/18939
not planned で閉じられていた。まあそんな気はしていた。
しかし eslint-interactive としてはESLint#calculateConfigForFileとLinter#verifyを組み合わせて使っている訳で、どうしようかな
そういう需要があることを伝えたうえで、どう問題を回避するのが適切なのか ESLint 開発チームに聞いてみる?
あるいは eslint-interactive でESLint#calculateConfigForFileとLinter#verifyを組み合わせるのをやめる?
頑張ったらLinterクラス使うのやめられると思う
=> やめた https://github.com/mizdra/eslint-interactive/pull/366
x "quickfix.biome"を付けると VS Code の formatOnSave が遅くなる問題
from: https://github.com/biomejs/biome-vscode/issues/229#issuecomment-2356257770
VS Code、VS Code 組み込みの JS/TS Extension、tsserver のどれかが悪いことまでは絞り込めてる
どれが悪いかを特定して、適切なところに報告したい
調査
そもそも"editor.codeActionsOnSave": { "source.fixAll.biome": "explicit" }ではなく、"editor.codeActionsOnSave": { "quickfix.biome": "explicit" }なのが違和感ある
VS Code の fix all の標準的な設定名はsource.fixAll.*のはず
標準的な方法から外れてるせいで、おかしくなってるんじゃないか
editor.codeActionsOnSaveでコード補完すると、source.fixAll.eslintやsource.fixAll.stylelintは出てくるが、quickfix.biomeは出てこない
https://gyazo.com/ff29c2ad2f293f5b20a12bb4aa789bed
そして vscode-eslint では、"source.fixAll.biome": "eslint"有効時も高速にファイルを保存できる
https://scrapbox.io/files/66eecf9ede0fff001dcb8ef5.mov
source.fixAll.*ってどうやったら実装できる?
stylelint の PR が参考になりそう
https://github.com/stylelint/vscode-stylelint/pull/18
https://github.com/stylelint/vscode-stylelint/pull/18/commits/d8abf4db2ff6a63ccb23d917509e6ff7372b0417 が注目すべき commit かな
けどこれ server しか手を加えてないのが違和感ある
2024/9/21 OSS に不具合報告しまくる#66eece08c75fd30000a0b508 で補完を出すためのヒントって多分 client (eslint server からのレスポンスを受け付けるやつ) が与えているはずだよね
うーん、どこでその情報を与えてるのかわかんないな
手元で調べてみたら、https://github.com/stylelint/vscode-stylelint/pull/18/files#diff-a4c65ede64197e1a112899a68bf994485b889c4b143198bac4af53425b38406fR155 の行があると、補完に出てくるぽかった
server が起動した時に、serevr からsource.fixAll.stylelintをサポートしているよと返答があったら、source.fixAll.stylelintが補完に出てくる模様
TypeScript and JavaScript Language Featuresの場合は、client からvscode.languages.registerCodeActionsProvider()でsource.fixAll.tsを登録しているっぽい
https://github.com/microsoft/vscode/blob/31e1cb3e716cf2b0579ebb6c6f723ba9b3717662/extensions/typescript-language-features/src/languageProvider.ts#L74
https://github.com/microsoft/vscode/blob/4c1716492a3e13f0e691e505d69e0079ff899f2f/extensions/typescript-language-features/src/languageFeatures/fixAll.ts#L255C10-L255C54
https://github.com/microsoft/vscode/blob/4c1716492a3e13f0e691e505d69e0079ff899f2f/extensions/typescript-language-features/src/languageFeatures/fixAll.ts#L201
https://github.com/microsoft/vscode/blob/4c1716492a3e13f0e691e505d69e0079ff899f2f/extensions/typescript-language-features/src/languageFeatures/fixAll.ts#L188
https://github.com/microsoft/vscode/blob/4c1716492a3e13f0e691e505d69e0079ff899f2f/extensions/typescript-language-features/src/languageFeatures/fixAll.ts#L130
workspace に *.tsファイルがない場合、TypeScript and JavaScript Language Featuresの client が起動しないので、source.fixAll.tsが補完に出てこないという挙動になる
https://gyazo.com/867733f30b2a1bc97ebe6e89dadcbe9e
ヘンテコな仕様だ
ところでquickfix.biomeで遅くなるのは何故なのか
TypeScript and JavaScript Language Featuresを無効化したら再現しなくなるということから察するに、TypeScript and JavaScript Language Featuresがquickfix code action に反応するようになっているのでは
で、その中で処理に時間がかかってファイル保存が遅くなっているのでは
quickfixcode actions に反応するのは合ってそう
https://github.com/microsoft/vscode/blob/31e1cb3e716cf2b0579ebb6c6f723ba9b3717662/extensions/typescript-language-features/src/languageProvider.ts#L84
https://github.com/microsoft/vscode/blob/4c1716492a3e13f0e691e505d69e0079ff899f2f/extensions/typescript-language-features/src/languageFeatures/quickFix.ts#L556-L558
https://github.com/microsoft/vscode/blob/4c1716492a3e13f0e691e505d69e0079ff899f2f/extensions/typescript-language-features/src/languageFeatures/quickFix.ts#L220
AI とか書いてあって時代だ
extensions/typescript-language-features/src/languageFeatures/quickFix.tsの一部を適当にコメントアウトしながら挙動を調べたら、何かわかるんじゃないか
/Applications/Visual\ Studio\ Code.app/Contents/Resources/app/extensions/typescript-language-features/dist/extension.jsに実体がある
minify されてた。デバッグしづらい。
試しに import('.../quickfix') の行 ごとコメントアウトしてみる
quickfix.biomeで遅くなる問題が再現しなくなった。予想通り。
vscode 手元でビルドしながら調査してみるかー
code:console
$ git clone --shallow git@github.com:microsoft/vscode.git
$ cd vscode
$ npm i
$ # Node.js v22 ではビルドスクリプトが動かないので、Node.js v20 に切り替え
$ nodenv local 20.17.0
$ ./scripts/code.sh
$ npm run watch-extensions
意外とすんなり起動して感動
setTimeout(resolve, 500);という怪しいコードを発見したので、コメントアウトしてみる
https://github.com/microsoft/vscode/blob/684f9d47a4a97d7ea747915f4d1595f86f98aaad/extensions/typescript-language-features/src/languageFeatures/quickFix.ts#L254-L256
quickfix.biomeで遅くなる問題が再現しなくなった！！！ ビンゴ！！！
setTimeout(resolve, 3000);にしたら更に遅くなったので、ここで間違いない
Delay for 500ms when there are pending diagnostics before recomputing up-to-date diagnostics.
すぐに quickfix してしまうと、コードが直前に変更されていた場合に古い診断情報を元に quickfix してしまい、おかしくなるから、ちょっと待機する、ということっぽい
まあ気持ちはわかるけど...雑すぎないか
小さなコードベースならすぐに診断情報も更新されるので、500ms も待つ必要ないと思う
大きなコードベースなら 500ms 以上待つ必要があると思う
診断情報が更新されるまで正確に待機すべきでは
"quickfix": "explicit"や"quickfix.ts": "explicit"で待機するのは分かるけど、"quickfix.biome": "explicit"で待機するのはおかしくないか
"quickfix.biome": "explicit"はjs/ts拡張機能では無視するべきでは?
問題の原因は分かったけど、どう報告するかなー
一旦 VS Code チームにどうするべきか尋ねることにした
https://github.com/microsoft/vscode-discussions/discussions/1664
x iOS Safari で画面外にある select 要素にフォーカスした時に、その select 要素をタップしても選択肢が表示されない問題
https://codepen.io/mizdra/pen/mdYJzPq
再現動画を撮って、bugzilla に上げたらよかろう
報告した: 280154 – The dropdown menu does not appear when a select element outside the viewport is focused
_ Firefox/Safari にて、fetch 中にページ遷移すると NetworkError が発生した状態のページが bfcache され、ブラウザバックで戻ってきた時にエラーが発生した状態からページが再開される問題
from: https://www.mizdra.net/entry/2023/12/15/012937
これが不具合かどうかは知らないが、多くの人にとって良くない挙動だと思う
bfcache の仕様を策定してる人にフィードバックして、どうすべきか意見を聞きたい
そもそも bfcache の仕様ってどこにあるの
explainer はあった: https://github.com/rakina/bfcache-explainer
https://web.dev/articles/bfcache?hl=ja#additional_resources
Chromium チームの資料を発見: Back-forward cache: web-exposed behaviour - Google ドキュメント
Tester もある: https://back-forward-cache-tester.glitch.me/?persistent_logs=1
なんか bfcache 自体の仕様はないように見えるな〜
fetch とか、Page Lifecycle の API (pageshow, pagehide) など、個々の機能の仕様側で吸収されているように見える
確かに https://github.com/rakina/bfcache-explainer?tab=readme-ov-file#spec-details を見ると、そういう感じっぽい
See meta-bug for back-forward cache spec issues (not complete, certain issues mentioned in this explainer doesn’t have issues filed yet)
それぞれの機能の仕様リポジトリに起票しつつ、https://github.com/whatwg/html/issues/5880 にリンクしたら良いらしい
今回の問題はどのリポジトリに起票しようかな
fetch だから https://github.com/whatwg/fetch かなー
どういう解決策があるのか
Chrome 方式 (ページ遷移後も fetch を裏で継続する) か、fetch 中にページ遷移したら bfcache しないようにするのが良いのではないか
そういえば https://b.hatena.ne.jp/entry/4746422063944294927/comment/efcl というコメントがあった
動画の再生でも似たようなことが起こるんだろうか
これは別問題な気がするなー。一旦置いておこう。
とりあえず再現リポジトリを整える
https://github.com/mizdra/bfcache-and-page-transitions-during-fetching-test
ふと Web Platform Test を見てみる
https://wpt.fyi/results/html/browsers/browsing-the-web/back-forward-cache/eligibility?label=master&label=experimental&aligned&q=back-forward-cache
ﾊﾊｰﾝ
これ WPT のテストケースが正で良いのか...?
ブラウザ間で合意取れてる?
https://github.com/whatwg/html/issues/6699
うーん、Chrome の挙動は仕様に沿っているという話は書いてあるけど、他のブラウザは...?
https://github.com/chromium/chromium/commit/419fccc6c3301a0d8702a860195ec2fc780505d5
Chrome: The page is BFCached and the fetch request completes successfully after restored.
Firefox: The page is not BFCached
Safari: The page is BFCached but the fetch request is canceled.
どの挙動が正解なの
いきなり WHATWG に Issue 立てに行くよりは、Webkit や Mozilla に先にお伺いを立てに行くほうが良い気がしてきた
_ FinalizationRegistryの callback が完全に同期的なコードでは呼ばれる機会がなく、FinalizationRegistryによるメモリ解放をするアプリケーションがメモリリークする問題
from: https://github.com/rustwasm/wasm-bindgen/issues/3917
JavaScript の仕様で解決する余地があるのか、諦めるしかないのか、tc39 の人に確認したい
_ Next.js で@vercel/ogの resolution 先が Pages Router + non turbo mode でおかしくなる問題
https://github.com/mizdra/repro-next-vercel-og-resolution
Pages Router 固有のマイナーな問題なので、起票したところで解決されないような気はするけど...
僕だったらこの問題は放置する
_ Remix, Next.js, conform にそれぞれ「お前が言う Progressive Enhancement という言葉の使い方間違ってない?」とお伺い Issue を立てる
文脈: https://x.com/mizdra/status/1791297585438969951