Bugzilla

After spending too long trying to find out why test [testing/web-platform/tests/html/browsers/browsing-the-web/navigating-across-documents/010.html](https://searchfox.org/mozilla-central/rev/50cb0892948fb4291b9a6b1b30122100ec7d4ef2/testing/web-platform/tests/html/browsers/browsing-the-web/navigating-across-documents/010.html) has been timing out (and with the help of my teammates), I figured I'd type up an explanation here, for posterity.

Roughly, the test is supposed to do the following:
- click on the `<a>` element (targetting iframe `test`), which has an `onclick` handler that will submit a form causing (a) to execute, and an `href` attribute, set to load `href.html`, where the JS code will do (b).
- (a) Note that form's action is `javascript:` URI and the form is targetting iframe `test`. The JS code opens an XHR request for `blank.html?pipe=trickle(d2)`, and [is expecting a delay of 2 seconds](https://searchfox.org/mozilla-central/rev/50cb0892948fb4291b9a6b1b30122100ec7d4ef2/testing/web-platform/tests/html/browsers/browsing-the-web/navigating-across-documents/010.html) from the server before the response is sent back. If the XHR completes before the test has ended (fail case scenario), post a message to the parent with the value `write` and do other things.
- (b) `href.html` will post a message to the parent with value "href"

The expected scenario is that the XHR will be so slow that `href.html` will have a chance to be loaded in the iframe before the XHR completes, and thus the message that will be posted to the parent will be sent by script code in `href.html`.

However, now that non-initial (explicit) about:blank loads are taking place via DocumentChannel, it might take longer for about:blank to load. This results in the following scenario as explained to me by Kris: 
- When the code inside of the form's action URI starts executing, it is being executed inside of the document that has the initial `about:blank` loaded. Shortly before that, we started loading the explicit `about:blank` page (happens whenever we have an iframe without a `<src>` element). The XHR starts, [suppress event handling and ends up spinning an event loop](https://searchfox.org/mozilla-central/rev/50cb0892948fb4291b9a6b1b30122100ec7d4ef2/dom/xhr/XMLHttpRequestMainThread.cpp#3012,3031).
- Then we start loading `href.html` which causes the explicit about:blank load to be cancelled.
- We end up reusing about:blank's DocumentViewer for `href.html` load, and because the XHR is associated with the initial about:blank, we don't end up removing it and so it keeps spinning the event loop. If the no-src `about:blank` load happened faster, the XHR request would have loaded inside of it and when the load for `href.html` began, we wouldn't have reused the document (because it's not an initial one) thus destroying the document and XHR with it. Removing the XHR would cause the event loop to unblock and to unsupress event handling.

After spending too long trying to find out why test [testing/web-platform/tests/html/browsers/browsing-the-web/navigating-across-documents/010.html](https://searchfox.org/mozilla-central/rev/50cb0892948fb4291b9a6b1b30122100ec7d4ef2/testing/web-platform/tests/html/browsers/browsing-the-web/navigating-across-documents/010.html) has been timing out (and with the help of my teammates), I figured I'd type up an explanation here, for posterity.

Roughly, the test is supposed to do the following:
- click on the `<a>` element (targetting iframe `test`), which has an `onclick` handler that will submit a form causing (a) to execute, and an `href` attribute, set to load `href.html`, where the JS code will do (b).
- (a) Note that form's action is `javascript:` URI and the form is targetting iframe `test`. The JS code opens an XHR request for `blank.html?pipe=trickle(d2)`, and [is expecting a delay of 2 seconds](https://searchfox.org/mozilla-central/rev/50cb0892948fb4291b9a6b1b30122100ec7d4ef2/testing/web-platform/tests/html/browsers/browsing-the-web/navigating-across-documents/010.html) from the server before the response is sent back. If the XHR completes before the test has ended (fail case scenario), post a message to the parent with the value `write` and do other things.
- (b) `href.html` will post a message to the parent with value "href"

The expected scenario is that the XHR will be so slow that `href.html` will have a chance to be loaded in the iframe before the XHR completes, and thus the message that will be posted to the parent will be sent by script code in `href.html`.

However, now that non-initial (explicit) about:blank loads are taking place via DocumentChannel, it might take longer for about:blank to load. This results in the following scenario as explained to me by Kris: 
- When the code inside of the form's action URI starts executing, it is being executed inside of the document that has the initial `about:blank` loaded. Shortly before that, we started loading the explicit `about:blank` page (happens whenever we have an iframe without a `<src>` element). The XHR starts, [suppress event handling and ends up spinning an event loop](https://searchfox.org/mozilla-central/rev/50cb0892948fb4291b9a6b1b30122100ec7d4ef2/dom/xhr/XMLHttpRequestMainThread.cpp#3012,3031).
- Then we start loading `href.html` which causes the explicit about:blank load to be cancelled.
- We end up reusing about:blank's DocumentViewer for `href.html` load, and because the XHR is associated with the initial about:blank, we don't end up removing it and so it keeps spinning the event loop. If the no-src `about:blank` load happened faster, the XHR request would have loaded inside of it and when the load for `href.html` began, we wouldn't have reused the document (because it's not an initial one) thus destroying the document and XHR with it. Removing the XHR would cause the event loop to unblock and to unsupress event handling.


The solution is to make sure we wait for onload event before we execute test steps (i.e. clicking on `<a>`).