stops parsing (構文解析器)

[2] stops parsing は、構文解析が完了して文書の準備が完了した際に実行される手順 (仕様書上のアルゴリズム) です。文書を構文解析モードから通常モードへと切り替える働きがあります。 DOMContentLoaded や load のイベントは、この手順から発火されます。

仕様書

文脈

[43] 次の場面で呼び出されます。

HTML構文解析器
XML構文解析器
XSLT による変換完了(成功)時
媒体文書の読み込み
プラグイン文書の読み込み
非文書表示

[46] つまり navigate の結果閲覧文脈の文書が更新された時には必ず実行されます。

[45] navigate は、

... を (必要なら) stops parsing より前に行っておく必要があります (navigate 参照)。これらはどちらもネットワーク処理タスク源のタスクなので、 fetch が process response end-of-file で stops parsing を呼び出すことになるタスクをタスクキューに追加するよりも前の段階でこれらのタスクを追加しておく必要があることになります。

通常はそれよりもかなり前の段階で行われます。レンダリングの開始も参照。

[14] 自動補完、パスワードマネージャーへの保存

処理

[4] 構文解析器構文解析器の stops parsing は、まず次のようにしなければなりません。

[5] 構文解析器の文書の現在文書準備度を、 interactive に設定します >>1。
[72] 単純イベントを発火します。 >>69
単純イベント
イベント型
readystatechange
対象
構文解析器の文書
[6] 構文解析器の挿入点を、 null に設定します >>1。
[7] 構文解析器の開いている要素のスタックの節点をすべて pop します >>1。
[10] 構文解析器について構文解析終了後のスクリプト実行の処理 (script 参照。) を実行します。続きの処理は >>15 とします。 >>1
- [76] これは、 defer 属性(相当)が適用される script 要素の実行です。
- [12] 続きの処理が同期的に呼び出されることもあれば、別のタスクとなることもあります。

[15] 更なる処理が構文解析器について呼び出されたら、次のようにしなければなりません >>1。

[13] 新しいタスクをタスクキューに追加します。
タスク
タスク源
DOM操作タスク源
処理
[16] 単純イベントを発火します。
単純イベント
イベント型
DOMContentLoaded
対象
構文解析器の文書
[82] サービスワーカークライアントが構文解析器の文書の設定群オブジェクトであるような ServiceWorkerContainer のクライアントメッセージキューを有効化します。

[17] 現在のタスクはこれで終了します。更に、

[18] set of scripts that will execute as soon as possible が空になる
[19] the list of scripts that will execute in order as soon as possible が空になる
[20] delay the load event するものがなくなる

... のすべての条件が満たされたら、現在のタスクと同じタスク源の新たなタスクをタスクキューに追加しなければなりません >>1。

[34] つまり、残りのスクリプトの実行完了と埋め込まれた資源の読み込み完了を待ちます。

[21] 新たなタスクは、次のようにしなければなりません >>1。

[22] タスクをタスクキューに追加します。
タスク
タスク源
DOM操作タスク源
処理
[23] 現在文書準備度を、 complete に設定します。
[71] 単純イベントを発火します。 >>69
単純イベント
イベント型
readystatechange
対象
文書
[24] 文書が閲覧文脈中にあるなら、単純イベントを発火します。
単純イベント
イベント型
load
対象
文書の Window
対象上書き
文書
[25] 文書が閲覧文脈中にあるなら、タスクをタスクキューに追加します。
タスク
タスク源
DOM操作タスク源
処理
[26] 文書の page showing flag が偽なら、
[27] 文書の page showing flag を、真に設定します。
[28] イベントを発火します。
イベント
イベントインターフェイス
PageTransitionEvent
イベント型
pageshow
対象
文書の Window
対象上書き
文書
trusted
真
bubbles
偽
取消可能
偽
persisted
偽
既定動作
なし
[29] 文書の pending application cache download process tasks にタスクがあれば、そのままの順序で、ネットワーク処理タスク源でタスクキューに追加します。リストは空にします。
[30] 文書の print when loaded flag が設定されていれば、 printing steps を実行します。
[31] 文書を、 ready for post-load tasks とします。
[25] タスクをタスクキューに追加します。
タスク
タスク源
DOM操作タスク源
処理
[32] 文書の completely loaded を設定します。

[60] page showing flag が真の状態でここに到達することがあるのかどうか謎です。

[42] printing steps はイベントループの一時停止を呼び出すことがあります。イベントを同期的に発火することもあります。

[11] HTML Standard は stops parsing をイベントループのスピンを使って記述していますが、次の性質から、 stop parsing 中 (構文解析終了後のスクリプト実行の処理 >>10 を含む。) のスピンは、スピンを使わないで説明できます。

スピンを使った場合と使わないここで示した説明の違いは、大域スクリプト片付けジョブとマイクロタスクの実行のタイミング~~と、ストレージミューテックスの解放~~のタイミングです。
構文解析器以外のタスク等がこれらを追加していた場合には、イベントループ等により stops parsing のタスクより前に実行されているはずです。
スクリプトがこれらを追加していた場合には、コールバックを走らせた後の片付けによりスクリプト実行直後に実行されているはずです。~~イベントループがストレージミューテックスを取得していた場合も、ここで解放されているはずです。~~
構文解析器が <meta http-equiv=Set-Cookie> を処理する場合、ストレージミューテックスを取得した状態になります。スピンの場合とスピンを使わない説明とでは、解放のタイミングが変わってきます。ただし実際の Webブラウザーはストレージミューテックスを使っていません。使っていたとしても、ストレージミューテックスをイベントループが所有していることにより動作が違うことを観測するのは著者にとっても利用者にとっても困難と思われます。
残るのは、構文解析器の DOM 操作によりマイクロタスクが追加されていた場合のみです。
スピンを使わない説明の場合、現在のタスクが停止されイベントループに戻ると、次にイベントループによってマイクロタスクが実行されることになります。これは結局スピンの場合と同じです。

[35] 閲覧文脈外にある文書 (XHR などの文書や、 Webブラウザー以外の構文解析器の文書) の場合は、 (ブラウザー拡張等独自の機能で特別な扱いがなければ、) スクリプトや埋め込み資源がなく、 stop parsing の完了後までイベントリスナーを登録することもできませんから、次の通り簡略化できます。

[36] 開いている要素のスタックを空にします。
[37] (本タスクを終えて新しいタスクで続きを実行します。)
[38] 現在文書準備度を complete に設定します。

[39] 仕様通り解釈すると >>37 のスピンは必ず発生することになりますが、実際には必要ないはずです。

副作用

[48] stops parsing は構文解析器の処理を終える作業であり、構文解析器の動作中と動作後で異なる動きをする処理の分岐フラグが立てられるタイミングです。

[47] stops parsing 開始 (= readyState が interactive となった) 段階:

[49] document.write/document.writeln は以後 document.open を伴うようになります。
[9] 開いている要素のスタックから節点を pop すると、副作用で何らかの動作が行われることがあります。開いている要素のスタックを参照。
[85] WebDriver で読み込み完了とみなされる場合があります。

[8] DOMContentLoaded 段階:

[70] webNavigation API の onDOMContentLoaded を、現在時刻と共に呼び出します。
[33] この時点またはその後の都合の良い時点で、ブラウザー拡張の内容スクリプトを実行します。

[83] readyState が complete となった段階:

[84] WebDriver で読み込み完了とみなされる場合があります。

[57] load 段階:

[58] ブラウザー拡張の内容スクリプトを実行します。

[50] ready for post-load tasks (stops parsing 自体の実行完了):

[52] 閲覧文脈包含子たる iframe/object/embed/frame の delay the load event が終わります。
[40] queue a post-load task (AppCache の処理の実行) が遅延されていたのが解除されます。
[53] window.print が遅延されていたのが解除されます。
[41] 以後の document.open が新しいソースコードを使うものだとみなされるようになります。

[51] completely loaded (stops parsing により追加されたDOM操作タスク源のタスクの実行完了):

[54] 文書のcompletely loaded から起算するタイマー群の各タイマーの計測開始
- Refresh
[55] 以後 iframe/frame、フォームの提出、Location の navigate で暗黙裡に置換有効とされなくなります。
[56] 閲覧文脈包含子たる iframe/frame 要素で load イベントが発火されることがあります。
[73] 共有ワーカーを permissible worker とみなすかどうかの条件に影響します。

[77] embed 要素が SVG を埋め込む場合の処理で「資源を完全に読み込んだ」タイミングを参照しており、 completely loaded の意味と思われます。

[44] 更に「活性構文解析器」が stops parsing されていないこと(など)を定義としています。 stops parsing のどの段階まで完了したことを指すのかは不明瞭です。活性構文解析器が参照されるのは document.open と abort a document で、前者はどの段階と解釈しても結果は変わりません。後者は bfcache に影響します。 completely loaded と解釈するのが自然でしょうか。

[80] webNavigation API の onCompleted は完了後とされており、 completely loaded のタイミングでしょうか。現在時刻と共に呼び出します。ただし非文書表示でネットワークエラー等を表示している場合は、かわりに onErrorOccurred をエラーの説明の文字列と現在時刻と共に実行します。

[75] busy indicator も参照。

`load` イベントの遅延

[61] load イベントは、埋め込み資源などの読み込みが終わってから発火されます。

[62] 仕様書上はこれは delays the load event >>1 として記述されています。各操作がいつからいつまで delay the load event するかが規定されており、 delay the load event するものがなくなった時、 load が発火できるようになります。 delay the load event は文書ごとの状態です。

[63] 次のものがあります。