Firefoxの新しいバージョンでのXMLHttpRequestの奇妙な動作に関する1つの調査の物語

I.問題の本質。

もちろん、XMLHttpRequestは主な目的のリストにHTMLリクエストを含んでいません。このツールはより頻繁にXML、JSON、またはプレーンテキストとやり取りします。



ただし、XMLHttpRequest + HTMLバンドルは、電子メールのサブスクリプション、RSS、またはその他の低コストAPIを提供しない、またはこれらのサービスにいくつかの制限を提供しないニュースサイトをバックグラウンドでポーリングするブラウザー拡張機能を作成する場合に適切に機能します。



Firefoxのいくつかの拡張機能を作成するとき、私はそのようなニーズに出会いました。 正規表現を使用してXMLHttpRequestから受信したHTMLコードを操作することは、非常に信頼性が低く、面倒な方法です。 適切なXMLのXMLHttpRequestからDOMを取得できます。 そのため、 開発者のサイトで注意が必要なヒントに従う必要がありました 。 ただし、Firefox 11以降、 XMLHttpRequestからDOMを直接取得することが可能になり、Firefox 12でタイムアウト処理が追加されました。



2つの小さなフォーラムの新しいトピックのミニインジケーターを作成する新しい機会を経験し、非常に便利であることがわかりました （50行のコードとCustomButtons拡張-これは、タイマーポーリングと4つの状態を備えた既製のインジケーターです。ニュースなし、ニュースあり、エラー、タイムアウト、詳細についてはこちらをご覧ください ）。 すべてが時計のように機能しました。



したがって、拡張機能のコードから古い松葉杖をすべて削除し、そこに新しい便利な解析を導入しようとしました。 ただし、 rutracker.org Webサイトで作業しているときに、奇妙な問題が発生しました（Windows XPでの最後の夜間ビルドでテストが行​​われます。コードと言語のすべての間違いをおa びします。残念ながら、この分野での経験は非常に少ないです） 。）。



次の簡単なコード例は、ほとんど常にタイムアウトになります（検証のために、サイトにログインする必要があります-これが重要である理由が明らかになります）

var xhr = new XMLHttpRequest(); xhr.mozBackgroundRequest = true; xhr.open("GET", "http://rutracker.org/forum/index.php", true); xhr.timeout = 10000; xhr.channel.loadFlags |= Components.interfaces.nsIRequest.LOAD_BYPASS_CACHE; xhr.responseType = "document"; xhr.onload = function() { alert(this.responseXML.title); } xhr.onerror = function() { alert("Error!"); } xhr.ontimeout = function() { alert("Timeout!"); } xhr.send(null);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、DOMでのHTML解析には問題があります。これは、サイトが遅滞なくページを提供するためです。たとえば、解析なしの次のコードはためらうことなく機能します。

 var xhr = new XMLHttpRequest(); xhr.mozBackgroundRequest = true; xhr.open("GET", "http://rutracker.org/forum/index.php", true); xhr.timeout = 10000; xhr.channel.loadFlags |= Components.interfaces.nsIRequest.LOAD_BYPASS_CACHE; xhr.onload = function() { alert(this.responseText.match(/<title>.+?<\/title>/i)[0]); } xhr.onerror = function() { alert("Error!"); } xhr.ontimeout = function() { alert("Timeout!"); } xhr.send(null);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

XMLHttpRequest 仕様では、DOMでHTML / XMLを解析する場合、結果のドキュメントツリーのスクリプトは実行されず、参照されるリソースはロードされず、 関連するXSLTは適用されません、つまり、スクリプトは処理されず、リソースはロードされません（確認されます）記述されたリクエストのHTTPアクティビティを監視する）、これらの側で遅延が発生することはありません。 唯一の問題は、DOM自体の構造にのみ存在します。何らかの理由で、解析がフリーズし、疑似タイムアウトが作成されます。

II。 追加の観察。

次に、DOM統計用の小さなスクリプトを作成し、その助けを借りて問題ページの分析を開始しました。

 var doc = content.document; var root = doc.documentElement; var text_char = root.textContent.length; var elm_nodes = doc.evaluate(".//*", root, null, XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null).snapshotLength; var txt_nodes = doc.evaluate(".//text()", root, null, XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null).snapshotLength; var com_nodes = doc.evaluate(".//comment()", root, null, XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null).snapshotLength; var all_nodes = doc.evaluate(".//node()", root, null, XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null).snapshotLength; var max_nst_lv = 0; var max_nst_lv_nodes = 0; for (var level = 1, pattern = "./node()"; level <= 50; level++, pattern += "/node()") { var elm_num = doc.evaluate(pattern,root,null,XPathResult.ORDERED_NODE_SNAPSHOT_TYPE,null).snapshotLength; if (elm_num) { max_nst_lv = level; max_nst_lv_nodes = elm_num; } } alert( text_char + "\ttext characters\n\n" + elm_nodes + "\telement nodes\n" + txt_nodes + "\ttext nodes\n" + com_nodes + "\tcomment nodes\n" + all_nodes + "\tall nodes\n\n" + max_nst_lv_nodes + " nodes in the " + max_nst_lv + " maximum nesting level\n" );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

以下に、さらに複雑なデータを示します。



1. JavaScriptをオフにしたフォーラムのメインページには、テキストノードの49677文字、4192のHTML要素、4285のテキストノード、77のコメント、合計8554のノードがあります。 ノードの最大25番目のネストレベルにある577ノード。



2.フォーラムを終了して権限のないユーザーのページをダウンロードすると、次の統計が得られます。テキストノードの47831文字、3336 HTML要素、4094テキストノード、73コメント、合計7503ノード。 ノードの最大24番目のネストレベルにある1136ノード。 構造は明らかに単純であり、フォーラムを離れることで問題のあるコードを試しても（つまり、このページで許可されていないユーザーのために）、タイムアウトは発生しません。



3.問題ページをテストサイトにアップロードして、その構造を徐々に簡素化しようとしました。 たとえば、クラスrow1 （ヘッダーページのテーブルのフォーラムとサブフォーラムの見出し）を持つすべてのtd



要素を削除し、他に何も変更しない場合、次の統計が得られます：テキストノードの20,450文字、1355 HTML要素、1726テキストノード、77コメント、合計3158ノード; ノードの最大25番目のネストレベルにある8つのノード。 繰り返しますが、例外がほとんどないこのページではタイムアウトは発生しません。



4. script



要素には非常に奇妙な意味があります。 タイトルページには19個あります（頭と体の組み合わせ、ロード、埋め込み）。 これらの要素のみを削除すると、ページのタイムアウトが停止します。 さらに、最後から最初まで削除する場合は、すべてを削除する必要があります（最初にロードされたスクリプトを先頭に置いても、タイムアウトは続きます）。 また、最初から最後まで削除すると、「ルール、基本的な手順、FAQ」セクションのforum_desc隠しクラスのp



要素に組み込まれたスクリプトを削除した後にタイムアウトが停止します。その後、さらに6つのスクリプトを残すことができ、タイムアウトは停止します（さらに、削除このスクリプトのみが問題を解決しません）。 さらに、19個のスクリプトすべてが、コードもsrc属性もない空のscript



要素に置き換えられた場合、タイムアウトが残ります。 ただし、これらの空の要素を同じ量の同じ空のstyle



要素に置き換えると、タイムアウトはすぐに消えます。



5. PERLでスクリプトを使用して、多少複雑な構造（ただし、 script



要素なし）でテストHTMLを作成しようとしました。 結果は、次の統計を備えたサイズがほぼ10メガバイトのファイルでした。テキストノードの9732505文字、25004 HTML要素、2500 2テキストノード、1000コメント、合計51006ノード。 最大27レベルのネストで1000ノット。 構造は問題ページよりも大きく複雑であるように見えますが、タイムアウトは発生しません。 問題は、要素の量/複雑さ/特異性のあいまいな組み合わせにあることが明らかになりました。



6.このシミュレートされたページにscript



要素を追加するだけで、タイムアウトが返されました（この難しいケースではタイムアウトしきい値を1分に増やしましたが）。

III。 簡単に再現可能なユースケースを作成します。

PERLのこのようなスクリプトの助けを借りて、トラッカーホームページの構造に匹敵する構造上の問題の特定の重要な最小値を達成することができました。

 use strict; use warnings; open(OUTPUT, '>:raw:encoding(UTF-8)', "test.html") or die "Cannot write to test.html: $!\n"; print OUTPUT "<!DOCTYPE html PUBLIC '-//W3C//DTD HTML 4.01 Transitional//EN' 'http://www.w3.org/TR/html4/loose.dtd'>\n" . "<html><head><meta http-equiv='Content-Type' content='text/html; charset=UTF-8'><title>Test</title></head><body>" . (("<div class='abcd'>abcd" x 25 . "</div>" x 25 ) x 10 . "<script type='text/javascript'>var a = 1234;</script>") x 20 . "</body></html>\n"; close(OUTPUT);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ページ統計：テキストノードに20,265文字、5024 HTML要素、5022テキストノード、0コメント、合計10046ノード。 ネストノードの最大27レベルで200ノード。 20個の基本script



要素を含む。 10回の試行で10回のタイムアウトが発生します。



構造を単純化するか、ボリュームを減らすさまざまな試みにより、タイムアウトの確率は低下しますが、予測不可能な方法で（これらの単純化のいずれも、各スクリプトが元のコードに戻る前に重複しませんでした）：



-すべてのscript



要素をコードの最後に移動します（他に何も変化せず、統計が同じままであるにもかかわらず）：10回の試行で0回のタイムアウト。

- script



要素を、1つの属性と同じテキストコンテンツを持つspan



要素で置き換えscript



（最後に移動せずに）：10回の試行で0回のタイムアウト。

-3文字のスクリプトテキストの略語：10のうち7つのタイムアウト。

-スクリプトの内容全体を削除する（空のタグのみが残る）：10回の試行のうち6回のタイムアウト。

div



要素のテキストを1文字に削減：10回の試行から5回のタイムアウト。

div



要素のテキストの完全な削除（空白ページが表示されます）：10回の試行のうち7回のタイムアウト。

div



要素のclass属性を1文字に削減：10回の試行から8回のタイムアウト。

div



要素のclass属性の削除：10回の試行から1回のタイムアウト。

- script



要素の数を2に減らしscript



（コードの途中と最後）：もう一度10回の試行から10回のタイムアウト。

- script



要素の数を1に減らしscript



（コードの先頭）：10回の試行で同じ10個のタイムアウトがあります（ただし、この要素をコードの最後に移動すると、タイムアウトは完全に消えます）。

-ネストの最大レベルを維持しながら、 div



要素（およびテキストノード）の数を半分にします：10回の試行のうち3回のタイムアウト。

-ネストの最大レベルを半分に減らします（要素とテキストノードの合計数はほぼ同じままですが、ネストの最大レベルの要素数は2倍になります）：10回の試行のうち7回のタイムアウト。

-エレメントの合計数を維持しながら、ネストの最大レベルを3（ body/div/



テキストまたはbody/script/



テキスト）に削減：10回の試行で8回のタイムアウト。

IV。 予備調査結果。

記載されているすべてのケースで、プロセッサの過負荷は観察されなかったため、ハードウェアをハングのせいにする理由はありません（ネットワーク遅延と同様に、コードは一瞬で取得され、ページははるかに短いタイムアウトでブラウザにレンダリングされます）。 明らかに、XMLHttpRequestでは、いくつかの限られたリソースがDOMのHTML解析に割り当てられますが、これは異なるパラメーターの組み合わせによって使い果たされます。 さらに、 script



要素（実行されることすらありません）と、特にコード内での順序は、不可解な役割を果たします。 これが当てはまる場合、リソースを増やし、要素のタイプと順序への奇妙な依存を減らす価値があります。問題は決して遠いものではなく、拡張機能の通常の開発の過程で生じるからです。

V.次は何ですか。

問題の分析を始めたばかりで、いくつかのサイトでアドバイスを求めたとき、forums.mozilla.orgの管理者はパフォーマンスバグを提案し、Core：DOMセクションで、再現された状況を説明するメッセージをbugzilla.mozilla.orgに送信するよう勧めました。 それから私は非常に少ないデータを持っていました、そして今、それらは非常に不明瞭です。 したがって、問題を特定して明確に説明できるようにする考慮事項に感謝します。 それ以外の場合は、このシートをすべて英語に翻訳する必要があり（言語と資料に関する私の知識レベルでは私にとっては非常に困難です）、そのままbugzilla.mozilla.orgに投稿する必要があります。もちろん、これは他の人の時間に対する軽reの表れです。