Chrome をクラッシュさせる CSS コードの行

一般的な CSS コードでは、UI レイアウトや互換性に関して軽微な問題が発生するだけです。しかし、ここでは Chrome ページを直接クラッシュさせる可能性のある興味深い CSS 行を共有したいと思います :)

再生

ZhihuやNuggetsなど、もう少し複雑なページをChromeで開く
開発者ツールを開き、ページにスタイルを追加します <body>: style: "width:1px; height:1px; transform:scale(10000)"
クラッシュする前にタスクマネージャーでChromeのメモリ使用量を確認する

実際、このマシンには 8GB のメモリしかありませんが、それは問題ではありません。 JS がクラッシュする 4GB の赤い線と比較すると、CSS はまだ強力です :)

話

このコード行の発見は、キャンバスサイズの調整を実装する際にエディタープロジェクトで発生した奇妙な現象に起因しています。ユーザーがキャンバスサイズを調整すると、新しいサイズと古いサイズの比率が特定の範囲を超えると、Chrome がフリーズします。

この問題は一般ユーザーの操作パスによって引き起こされる可能性は低いですが、それが引き起こす結果は実に深刻です。トラブルシューティングを行う際、まず JS のブロックや過剰な DOM の再描画などの可能性を検討しましたが、どちらも問題ではありませんでした。画期的な点の 1 つは、デバッガーのレンダリングツールの FPS メーターの出力でした。

ここで GPU メモリがいっぱいです。このプロンプトメッセージがハードウェアアクセラレーションに関連していることは明らかですが、関連する経験がなければ、それが特定のコードとどのように関連しているかを判断することはできません。 Chrome のデザインドキュメントで Compositing の紹介を偶然見たとき、Blink が DOM ノードを LayoutObject のレンダリングツリーにマッピングするという動作を発見しました。理論上は、このツリーの各ノードはレンダリングバックエンドのコンテキストを持つことができますが、リソースを節約するために、Chrome はレンダリング前にそれらをマージします。現時点では、CSS 配置 (絶対配置や変換など) を持つ要素は結合できないため、ビデオメモリに追加のオーバーヘッドが発生します。

この情報に基づいて、当時のページをデバッグするためにレイアウトツールを使用して、実際に特別な場所を見つけました。

画像内の最も大きな長方形のレイヤーは通常の DOM デバッグでは表示されないため、その過剰なサイズとそれに伴う RAM オーバーヘッドが原因であると推測されます。この情報に基づいて、ようやく適切な幅と高さを持つ DOM ノードを見つけましたが、変換のスケール値がロジック内で大幅に変更されている可能性があります。スケールの上限を制限すると、この問題を解決できます。スケール値と最終的な対応するピクセル数の間に O(N^2) 関係があることは簡単にわかります。1 ピクセルは 100 倍に拡大されるだけで、10,000 ピクセルになります。そのため、規模が非常に大きい場合には、メモリ/ビデオメモリを過剰に使用する可能性があります（もちろん、通常時はブラウザがタイリングなどを行うため、これは実情に即したものではなく、Safari/Firefoxでは現時点では問題はありません）。最後に、Chromeにバグを報告しました。#894115を参照してください。

要約する

ブラウザカーネルに関する深い理解が不足しているため、上記のデバッグのアイデアは不正確である可能性があることに注意してください。簡単な要約: