IE_javascript スキルの下で ul li が互いにネストされている場合のバグ、トラブルシューティング、解決プロセス、および経験に基づく

バグをチェックする手順

1. バグの場所

js スクリプトでは、スクリプトの実行順序に従って、コンソールまたはアラートを使用してバグが発生するコード間隔を特定し、その間隔内でバグが発生する特定のコード セグメントをさらに検索できます。

2. バグ修正

除外により、ノードのコンテンツを挿入するときにバグが発生しました。kissy の DOM.html() メソッドを使用しました。このメソッドの機能は DOM 要素ノードの innerHTML メソッドと似ていましたが、このメソッドが IE67 のレンダリングを引き起こすのではないかと考えました。 、次に innerHTML メソッドに変更しましたが、結果は依然として間違っていました。

このとき、メモリ リークについて考え、文字列のループ スプライシング中にメモリ リークを引き起こす循環参照やその他の理由があるかどうかを確認したかったのです。次に、いくつかのメソッドの最後に、いくつかの変数に null を割り当てました。メモリリークを防止します（機能するかどうかはわかりませんが、少なくとも私はこれを試しました）が、結果はまだ機能しません。

データが多すぎるため、レンダリング時にクラッシュするのでしょうか?そこで、スプライシングのデータ長を減らしたところ、うまくいきました。データが 1 ～ 3 個の場合はレンダリングできます。つまり、この方法は正しいのですが、データが 3 個を超えると、IE67 は依然として応答できません。そこで、1 つずつ連続してデータを挿入しようとしました。一度に 1 つずつデータを挿入しても問題なければ、さらに数回挿入してもよいのですが、IE では依然として問題が発生しました。実はこの時点で私の思考回路はすでにずれていました。

後で同僚に会いに来たところ、以前にもこの問題に遭遇したことがあり、IE67 でラベルが正しく閉じられなかったことが原因だと言っていました。はい、これがこのバグの本当の原因です。その後、結合した文字列を印刷し、書式設定ツールを使用して文字列を結合したときに発生する問題をすぐに発見したので、すぐにバグを修正しました。私が使用するオンライン書式設定ツール: http://tool.chinaz.com/Tools/JsFormat.aspx

3. テスト

テスト中、IE が Chrome とどのように比較されるかを確認するために、HTML コードの文字列を記述し、いくつかのタグを閉じないままにしました。

2 番目の li タグでは、ul タグ内の タグの 1 つを閉じています。

コードをコピーします。 コードは次のとおりです:

;


ul>

• inner li


• inner li

closedエラーが発生しました












• 内 li li>
  
• 内 li







上に示すように、IE と chrome では正常に表示されます。

次に、開発ツールを使用してデバッグしてみましょう。

IE7～9では、閉じられていないノードの内容が内に送信エラーが発生します。 。

Chrome での状況を見てみましょう。3 番目の li は通常どおり DOM ツリーにレンダリングされ、エラーが発生したspanタグにspan終了タグが自動的に追加されます。

4. 概要

各ブラウザ、特に IE やその他のブラウザでは、HTML をレンダリングする際のパフォーマンスが異なります。 chrome や FF のフォールトトレランス性能は非常に優れており、正常に閉じられていないページ内に html タグがあっても、それを賢く識別してブラウザ上で正常に表示され、問題は発生しません。ただし、悪い点は、コードに問題があることに気づかず、すべてが正常であると考えることです。 IE89 ではこの方法で処理できるようになりましたが、開発ツールを通じて、間違った HTML コードが正常な DOM 構造を持っていないことがわかります。しかし、IE67 ではそのような機会は与えられず、さもなければ直接クラッシュします。

Chrome では間違いが許されますが、IE は私たちにとってより厳格です。IE は頭の痛い問題ですが、コードにはより高い要件が課せられます。ふと、IEがあればいいなと思いました。 。 。

ある日、IE で DOM 構造をレンダリングできないことに気付いた場合は、コード内に閉じられていないタグがないかどうかを思い出してください。