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

x 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 に先にお伺いを立てに行くほうが良い気がしてきた

それぞれ報告した

https://bugzilla.mozilla.org/show_bug.cgi?id=1928385

https://bugs.webkit.org/show_bug.cgi?id=282506

_ 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