Chromeのリンクにカーソルを合わせるとどうなりますか？

このリンク（http://a//%%30%30）がGoogle Chromeでクリックされると、Chromeはすべてのタブとインスタンスを中断して閉じます。

しかし、場合によっては、リンクの上にカーソルを合わせるだけで、タブがクラッシュします。

このリンクにカーソルを合わせるとどうなりますか？リンクがホバーされたとき、Chromeは何をしますか？

クラッシュは、最近発見されたChromeおよび他のWebKitブラウザ（！）*のバグによるものです。具体的には、いずれか%%30%30、%0%30または%%300URLの一部として関連し、内部ではすべて同じ記号nullを表します。バグの詳細については、こちらをご覧ください。

ほとんどのリンクに影響するのはバグではないため、通常、リンクの上にマウスを移動することを心配する必要はありません。

注：
*その他のWebKitブラウザーには、Safari、Opera、Steamブラウザー、Midori、S60（Symbian）、Blackberryブラウザー、Playstation 3のブラウザーが含まれますが、 Firefox、Internet Explorer、Edge は含まれません。

編集：Deltikが指摘するように、このバグはChrome 45.0.2454.101で修正されました。

何が起こるかについての詳細

この問題は、リンクにカーソルを合わせるとすぐに実行されるURL canonicalizerに関連しています。ブラウザのステータスバーにリンクを表示したり、クリックすると読み込みが速くなるようにWebページをプリフェッチしたりするためです。

URL canonicalizerの役割に関して：
URLが書き込まれるとHTML、/homeまたはなどの形式で書き込まれる場合../../homeがありますが、ブラウザはこのURLをプロトコルとドメインを含むものに変換する必要がありますhttp://superuser.com/home。さらに、URLは翻訳される必要があるURL Escapesを含むかもしれません、そして、これらのエスケープはのようにパーセントコード化されます。（URLエスケープのより包括的なリストはこちら）。 このURL変換を処理する機能 は、開発者が期待/処理しなかった入力を受信するため、最終的にクラッシュします。%%30%30

ここだ問題を修正コードの変更の概要は：

URLパス内の問題のあるネストされたエスケープを正しく処理します。

具体的には、入力のエスケープを解除して新しいエスケープシーケンスを含む出力URLが生成される場合（たとえば、入力 "%% 30％30"を "％00"に変換する場合）シーケンスは、新しい有効なエスケープシーケンスとして扱われません。

これにより、同じURLを2回正規化しても変更されなくなります。これは、デバッグビルドとリリースビルドのさまざまな場所でクラッシュやその他のバグを回避するために重要です。

ファビオ・トゥラティが言うように、

リンクにカーソルを合わせると、Chromeの左下隅にリンクが表示されます。これには、特別にエンコードされた文字の「翻訳」を含むいくつかの処理が必要です。

しかし、あなたの投稿とコメントから、Chromeがバックグラウンドでリンクに接続するかどうかにより関心があると思います。それはないので、他の最近のブラウザ（やるのFirefox、オペラ）。Chromeの設定でプリフェッチを無効にするか、uBlock Originをインストールしてプライバシー設定を強化することができます。

ここで正確に何が起こるかについて、さらに明確にしたかったのです。

基本的に、％30はURLエンコードされた0であり、％00はURLエンコードされたNULL（バイナリで0000 0000として表示されます）です。そのため、NULLにデコードされるエンコードされた文字がネストされたURLがある場合、バグが発生します。

ChromeはURLを正規化するときに次のことを行います（ソース：https : //code.google.com/p/chromium/issues/detail?id=533361#c13）：

• 入力文字列「http：//a.com/%%30%30」は「http://a.com/%00」にエスケープ解除され、有効なGURLと見なされます。
• このGURLは最終的にGURLToDatabaseURL（）に送信され、GURLToDatabaseURL（）でReplaceComponents（）を呼び出してユーザー名とパスワードを削除します。
• ReplaceComponents（）は、URLを再正規化します。
• パスの正規化は「％00」シーケンスにヒットし、エスケープされず、これはURLで無効な0文字であると見なされ、エスケープされたままになりますが、結果のURLは無効としてマークされます。
• GURLToDatabaseURL（）に戻ると、入力URLが有効であることが保証され、ユーザー名とパスワードを削除しただけなので、新しいURLで.spec（）を呼び出して、有効であることを期待します。これはDCHECKsです。

そのため、URLは最初は有効と見なされますが、特定のプライベートデータを削除すると無効になります。ただし、そのデータが削除された後、その特定のコードを呼び出した関数は有効なURLを予期します。

このURLが無効とみなされる理由の一部は、文字列の終わりを示すために多くの古いソフトウェアと言語でNULLが使用されているためです（基本的には1行に8個のゼロがあるため、コンピューターでは簡単に検出できます）。