Two more tests ## [iframe-blank-inherit.meta/upgrade/iframe-tag](https://searchfox.org/mozilla-central/source/testing/web-platform/tests/upgrade-insecure-requests/gen/iframe-blank-inherit.meta/upgrade/iframe-tag.https.html) I didn't get into the details of what the test does, as it uses several utility functions making it difficult to isolate a single, short testcase. The test is for the `upgrade-insecure-requests` CSP. With the `about:blank` patch, we no longer call `loadInfo->SetUpgradeInsecureRequests` nor `Document::ApplySettingsFromCSP` via `InitCSP`, as :tschuster noted. Before `ApplySettingsFromCSP` would be called, there is also `mUpgradeInsecureRequests = loadInfo->GetUpgradeInsecureRequests()` in `StartDocumentLoad`. I see that this patch introduces `ApplyCspFromLoadInfo`, which does `mUpgradeInsecureRequests = loadInfo->GetUpgradeInsecureRequests()` for `about:blank` where `StartDocumentLoad` doesn't happen. But that `loadInfo` is created a few lines before without ever invoking `SetUpgradeInsecureRequests`. So it doesn't help. I tried replicating `loadInfo->SetUpgradeInsecureRequests` from [here](https://searchfox.org/mozilla-central/rev/ead020d3989d3e9477b353d3d117f9c0f4b16f53/docshell/base/nsDocShell.cpp#10023) in `DoURILoad`, but that didn't help either. What **would fix** the test is doing `doc->ApplySettingsFromCSP(false)` in `DoURILoad` within the `isAboutBlankLoadOntoInitialAboutBlank` branch. ## [document-base-url-window-initiator-is-not-opener](https://searchfox.org/mozilla-central/source/testing/web-platform/tests/html/infrastructure/urls/base-url/document-base-url-window-initiator-is-not-opener.https.window.js) The **problem** is that when setting `location.href=about:blank` on an `about:blank` page, we don't fire `pagehide` nor change the `baseURI`. Secondary to fixing the test, there might be web interop problems here, as we fire a second sync load event, unlike Blink. In the test, we have some document with baseURI A that opens an `about:blank` popup. It also contains an iframe with a different baseURI B. When the iframe is loaded, it initiates a navigation via `location.href = about:blank` on the popup. The test expects that the popup changes to baseURI B and fires a `pagehide`. The test allows for this to happen async and doesn't consider whether there should be a second load event. Blink changes `baseURI` sync, fires `pagehide` async and fires no `load`. We can also consider two similar cases: the iframe has the same baseURI as the parent or the parent itself does `location.href=about:blank`. In both cases, Blink will fire `pagehide` and change the `baseURI` from `about:blank` to the parent document's URI. For Gecko with the `about:blank` patch, nothing happens in the latter case while the former case only triggers a sync load event. Regarding the cause for this test failure. Without this patch, the `baseURI` is set in `Document::Reset`, reached via `Document::StartDocumentLoad` from the async channel load. `pagehide` is fired from `FirePageHideNotification` during `nsDocShell:CreateDocumentViewer`, also caused by the channel load. I tried to reconstruct what the spec says. [Navigate a navigable](https://html.spec.whatwg.org/#navigate) step 22.5.2 sets 'about base URL' in parallel and fires the `pagehide` much later in [unloading-documents](https://html.spec.whatwg.org/#unloading-documents:event-pagehide-3) via [applying the history step](https://html.spec.whatwg.org/#apply-the-history-step). I understand this so that the `baseURI` should be changed async. I didn't find under which conditions `navigate a navigable` causes a `load` event. I don't really know how to fix the test. Always firing `pagehide` for `about:blank` from `DoURILoad` causes the browser to become blank. Calling `Document::Reset(aboutBlankChannel)` causes a crash and wouldn't fix the test anyway, as `baseURI` was null [here](https://searchfox.org/mozilla-central/rev/ead020d3989d3e9477b353d3d117f9c0f4b16f53/dom/base/Document.cpp#2933-2938) for the `aboutBlankChannel`. Both `nsIURI` and `nsINestedURI` don't support getting the `baseURI` so I wouldn't really know how to obtain it any other way without directly depending on `nsNestedAboutURI`. Perhaps interesting, but less relevant are how browsers differ if we were to have a second iframe with `baseURI` C causing a second navigation of the popup. Blink will then block access to the popup due to cross-origin.
Bug 543435 Comment 183 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Two more tests ## [iframe-blank-inherit.meta/upgrade/iframe-tag](https://searchfox.org/mozilla-central/source/testing/web-platform/tests/upgrade-insecure-requests/gen/iframe-blank-inherit.meta/upgrade/iframe-tag.https.html) I didn't get into the details of what the test does, as it uses several utility functions making it difficult to isolate a single, short testcase. The test is for the `upgrade-insecure-requests` CSP. With the `about:blank` patch, we no longer call `loadInfo->SetUpgradeInsecureRequests` nor `Document::ApplySettingsFromCSP` via `InitCSP`, as :tschuster noted. Before `ApplySettingsFromCSP` would be called, there is also `mUpgradeInsecureRequests = loadInfo->GetUpgradeInsecureRequests()` in `StartDocumentLoad`. I see that this patch introduces `ApplyCspFromLoadInfo`, which does `mUpgradeInsecureRequests = loadInfo->GetUpgradeInsecureRequests()` for `about:blank` where `StartDocumentLoad` doesn't happen. But that `loadInfo` is created a few lines before without ever invoking `SetUpgradeInsecureRequests`. So it doesn't help. I tried replicating `loadInfo->SetUpgradeInsecureRequests` from [here](https://searchfox.org/mozilla-central/rev/ead020d3989d3e9477b353d3d117f9c0f4b16f53/docshell/base/nsDocShell.cpp#10023) in `DoURILoad`, but that didn't help either. What **would fix** the test is doing `doc->ApplySettingsFromCSP(false)` in `DoURILoad` within the `isAboutBlankLoadOntoInitialAboutBlank` branch. I'm concerned that I'm cherry picking lines from `StartDocumentLoad` till tests work, but other things might still be missing. ## [document-base-url-window-initiator-is-not-opener](https://searchfox.org/mozilla-central/source/testing/web-platform/tests/html/infrastructure/urls/base-url/document-base-url-window-initiator-is-not-opener.https.window.js) The **problem** is that when setting `location.href=about:blank` on an `about:blank` page, we don't fire `pagehide` nor change the `baseURI`. Secondary to fixing the test, there might be web interop problems here, as we fire a second sync load event, unlike Blink. In the test, we have some document with baseURI A that opens an `about:blank` popup. It also contains an iframe with a different baseURI B. When the iframe is loaded, it initiates a navigation via `location.href = about:blank` on the popup. The test expects that the popup changes to baseURI B and fires a `pagehide`. The test allows for this to happen async and doesn't consider whether there should be a second load event. Blink changes `baseURI` sync, fires `pagehide` async and fires no `load`. We can also consider two similar cases: the iframe has the same baseURI as the parent or the parent itself does `location.href=about:blank`. In both cases, Blink will fire `pagehide` and change the `baseURI` from `about:blank` to the parent document's URI. For Gecko with the `about:blank` patch, nothing happens in the latter case while the former case only triggers a sync load event. Regarding the cause for this test failure. Without this patch, the `baseURI` is set in `Document::Reset`, reached via `Document::StartDocumentLoad` from the async channel load. `pagehide` is fired from `FirePageHideNotification` during `nsDocShell:CreateDocumentViewer`, also caused by the channel load. I tried to reconstruct what the spec says. [Navigate a navigable](https://html.spec.whatwg.org/#navigate) step 22.5.2 sets 'about base URL' in parallel and fires the `pagehide` much later in [unloading-documents](https://html.spec.whatwg.org/#unloading-documents:event-pagehide-3) via [applying the history step](https://html.spec.whatwg.org/#apply-the-history-step). I understand this so that the `baseURI` should be changed async. I didn't find under which conditions `navigate a navigable` causes a `load` event. I don't really know how to fix the test. Always firing `pagehide` for `about:blank` from `DoURILoad` causes the browser to become blank. Calling `Document::Reset(aboutBlankChannel)` causes a crash and wouldn't fix the test anyway, as `baseURI` was null [here](https://searchfox.org/mozilla-central/rev/ead020d3989d3e9477b353d3d117f9c0f4b16f53/dom/base/Document.cpp#2933-2938) for the `aboutBlankChannel`. Both `nsIURI` and `nsINestedURI` don't support getting the `baseURI` so I wouldn't really know how to obtain it any other way without directly depending on `nsNestedAboutURI`. Perhaps interesting, but less relevant are how browsers differ if we were to have a second iframe with `baseURI` C causing a second navigation of the popup. Blink will then block access to the popup due to cross-origin.
Two more tests ## [iframe-blank-inherit.meta/upgrade/iframe-tag](https://searchfox.org/mozilla-central/source/testing/web-platform/tests/upgrade-insecure-requests/gen/iframe-blank-inherit.meta/upgrade/iframe-tag.https.html) I didn't get into the details of what the test does, as it uses several utility functions making it difficult to isolate a single, short testcase. The test is for the `upgrade-insecure-requests` CSP. With the `about:blank` patch, we no longer call `loadInfo->SetUpgradeInsecureRequests` nor `Document::ApplySettingsFromCSP` via `InitCSP`, as :tschuster noted. Before `ApplySettingsFromCSP` would be called, there is also `mUpgradeInsecureRequests = loadInfo->GetUpgradeInsecureRequests()` in `StartDocumentLoad`. I see that this patch introduces `ApplyCspFromLoadInfo`, which does `mUpgradeInsecureRequests = loadInfo->GetUpgradeInsecureRequests()` for `about:blank` where `StartDocumentLoad` doesn't happen. But that `loadInfo` is created a few lines before without ever invoking `SetUpgradeInsecureRequests`. So it doesn't help. I tried replicating `loadInfo->SetUpgradeInsecureRequests` from [here](https://searchfox.org/mozilla-central/rev/ead020d3989d3e9477b353d3d117f9c0f4b16f53/docshell/base/nsDocShell.cpp#10023) in `DoURILoad`, but that didn't help either. What **would fix** the test is doing `doc->ApplySettingsFromCSP(false)` in `DoURILoad` within the `isAboutBlankLoadOntoInitialAboutBlank` branch. I'm concerned that I'm cherry picking lines from `StartDocumentLoad` till tests work, but other things might still be missing. ## [document-base-url-window-initiator-is-not-opener](https://searchfox.org/mozilla-central/source/testing/web-platform/tests/html/infrastructure/urls/base-url/document-base-url-window-initiator-is-not-opener.https.window.js) The **problem** is that when setting `location.href=about:blank` on an `about:blank` page, we don't fire `pagehide` nor change the `baseURI`. Secondary to fixing the test, there might be web interop problems here, as we fire a second sync load event, unlike Blink. In the test, we have some document with baseURI A that opens an `about:blank` popup. It also contains an iframe with a different baseURI B. When the iframe is loaded, it initiates a navigation via `location.href = about:blank` on the popup. The test expects that the popup changes to baseURI B and fires a `pagehide`. The test allows for this to happen async and doesn't consider whether there should be a second load event. Blink ~~changes baseURI sync,~~ fires `pagehide` async, then changes `baseURI` and fires no `load`. We can also consider two similar cases: the iframe has the same baseURI as the parent or the parent itself does `location.href=about:blank`. In both cases, Blink will fire `pagehide` and change the `baseURI` from `about:blank` to the parent document's URI. For Gecko with the `about:blank` patch, nothing happens in the latter case while the former case only triggers a sync load event. Regarding the cause for this test failure. Without this patch, the `baseURI` is set in `Document::Reset`, reached via `Document::StartDocumentLoad` from the async channel load. `pagehide` is fired from `FirePageHideNotification` during `nsDocShell:CreateDocumentViewer`, also caused by the channel load. I tried to reconstruct what the spec says. [Navigate a navigable](https://html.spec.whatwg.org/#navigate) step 22.5.2 sets 'about base URL' in parallel and fires the `pagehide` much later in [unloading-documents](https://html.spec.whatwg.org/#unloading-documents:event-pagehide-3) via [applying the history step](https://html.spec.whatwg.org/#apply-the-history-step). I understand this so that the `baseURI` should be changed async. I didn't find under which conditions `navigate a navigable` causes a `load` event. I don't really know how to fix the test. Always firing `pagehide` for `about:blank` from `DoURILoad` causes the browser to become blank. Calling `Document::Reset(aboutBlankChannel)` causes a crash and wouldn't fix the test anyway, as `baseURI` was null [here](https://searchfox.org/mozilla-central/rev/ead020d3989d3e9477b353d3d117f9c0f4b16f53/dom/base/Document.cpp#2933-2938) for the `aboutBlankChannel`. Both `nsIURI` and `nsINestedURI` don't support getting the `baseURI` so I wouldn't really know how to obtain it any other way without directly depending on `nsNestedAboutURI`. Perhaps interesting, but less relevant are how browsers differ if we were to have a second iframe with `baseURI` C causing a second navigation of the popup. Blink will then block access to the popup due to cross-origin.
Two more tests ## [iframe-blank-inherit.meta/upgrade/iframe-tag](https://searchfox.org/mozilla-central/source/testing/web-platform/tests/upgrade-insecure-requests/gen/iframe-blank-inherit.meta/upgrade/iframe-tag.https.html) I didn't get into the details of what the test does, as it uses several utility functions making it difficult to isolate a single, short testcase. The test is for the `upgrade-insecure-requests` CSP. With the `about:blank` patch, we no longer call `loadInfo->SetUpgradeInsecureRequests` nor `Document::ApplySettingsFromCSP` via `InitCSP`, as :tschuster noted. Before `ApplySettingsFromCSP` would be called, there is also `mUpgradeInsecureRequests = loadInfo->GetUpgradeInsecureRequests()` in `StartDocumentLoad`. I see that this patch introduces `ApplyCspFromLoadInfo`, which does `mUpgradeInsecureRequests = loadInfo->GetUpgradeInsecureRequests()` for `about:blank` where `StartDocumentLoad` doesn't happen. But that `loadInfo` is created a few lines before without ever invoking `SetUpgradeInsecureRequests`. So it doesn't help. I tried replicating `loadInfo->SetUpgradeInsecureRequests` from [here](https://searchfox.org/mozilla-central/rev/ead020d3989d3e9477b353d3d117f9c0f4b16f53/docshell/base/nsDocShell.cpp#10023) in `DoURILoad`, but that didn't help either. What **would fix** the test is doing `doc->ApplySettingsFromCSP(false)` in `DoURILoad` within the `isAboutBlankLoadOntoInitialAboutBlank` branch. I'm concerned that I'm cherry picking lines from `StartDocumentLoad` till tests work, but other things might still be missing. ## [document-base-url-window-initiator-is-not-opener](https://searchfox.org/mozilla-central/source/testing/web-platform/tests/html/infrastructure/urls/base-url/document-base-url-window-initiator-is-not-opener.https.window.js) The **problem** is that when setting `location.href=about:blank` on an `about:blank` page, we don't fire `pagehide` nor change the `baseURI`. Secondary to fixing the test, there might be web interop problems here, as we fire a second sync load event, unlike Blink. In the test, we have some document with baseURI A that opens an `about:blank` popup. It also contains an iframe with a different baseURI B. When the iframe is loaded, it initiates a navigation via `location.href = about:blank` on the popup. The test expects that the popup changes to baseURI B and fires a `pagehide`. The test allows for this to happen async and doesn't consider whether there should be a second load event. Blink ~~changes baseURI sync,~~ fires `pagehide` async, then changes `baseURI` and fires no `load` (or clears the load listener beforehand?). We can also consider two similar cases: the iframe has the same baseURI as the parent or the parent itself does `location.href=about:blank`. In both cases, Blink will fire `pagehide` and change the `baseURI` from `about:blank` to the parent document's URI. For Gecko with the `about:blank` patch, nothing happens in the latter case while the former case only triggers a sync load event. Regarding the cause for this test failure. Without this patch, the `baseURI` is set in `Document::Reset`, reached via `Document::StartDocumentLoad` from the async channel load. `pagehide` is fired from `FirePageHideNotification` during `nsDocShell:CreateDocumentViewer`, also caused by the channel load. I tried to reconstruct what the spec says. [Navigate a navigable](https://html.spec.whatwg.org/#navigate) step 22.5.2 sets 'about base URL' in parallel and fires the `pagehide` much later in [unloading-documents](https://html.spec.whatwg.org/#unloading-documents:event-pagehide-3) via [applying the history step](https://html.spec.whatwg.org/#apply-the-history-step). I understand this so that the `baseURI` should be changed async. I didn't find under which conditions `navigate a navigable` causes a `load` event. I don't really know how to fix the test. Always firing `pagehide` for `about:blank` from `DoURILoad` causes the browser to become blank. Calling `Document::Reset(aboutBlankChannel)` causes a crash and wouldn't fix the test anyway, as `baseURI` was null [here](https://searchfox.org/mozilla-central/rev/ead020d3989d3e9477b353d3d117f9c0f4b16f53/dom/base/Document.cpp#2933-2938) for the `aboutBlankChannel`. Both `nsIURI` and `nsINestedURI` don't support getting the `baseURI` so I wouldn't really know how to obtain it any other way without directly depending on `nsNestedAboutURI`. Perhaps interesting, but less relevant are how browsers differ if we were to have a second iframe with `baseURI` C causing a second navigation of the popup. Blink will then block access to the popup due to cross-origin.
Two more tests ## [iframe-blank-inherit.meta/upgrade/iframe-tag](https://searchfox.org/mozilla-central/source/testing/web-platform/tests/upgrade-insecure-requests/gen/iframe-blank-inherit.meta/upgrade/iframe-tag.https.html) I didn't get into the details of what the test does, as it uses several utility functions making it difficult to isolate a single, short testcase. The test is for the `upgrade-insecure-requests` CSP. With the `about:blank` patch, we no longer call `loadInfo->SetUpgradeInsecureRequests` nor `Document::ApplySettingsFromCSP` via `InitCSP`, as :tschuster noted. Before `ApplySettingsFromCSP` would be called, there is also `mUpgradeInsecureRequests = loadInfo->GetUpgradeInsecureRequests()` in `StartDocumentLoad`. I see that this patch introduces `ApplyCspFromLoadInfo`, which does `mUpgradeInsecureRequests = loadInfo->GetUpgradeInsecureRequests()` for `about:blank` where `StartDocumentLoad` doesn't happen. But that `loadInfo` is created a few lines before without ever invoking `SetUpgradeInsecureRequests`. So it doesn't help. I tried replicating `loadInfo->SetUpgradeInsecureRequests` from [here](https://searchfox.org/mozilla-central/rev/ead020d3989d3e9477b353d3d117f9c0f4b16f53/docshell/base/nsDocShell.cpp#10023) in `DoURILoad`, but that didn't help either. What **would fix** the test is doing `doc->ApplySettingsFromCSP(false)` in `DoURILoad` within the `isAboutBlankLoadOntoInitialAboutBlank` branch. I'm concerned that I'm cherry picking lines from `StartDocumentLoad` till tests work, but other things might still be missing. ## [document-base-url-window-initiator-is-not-opener](https://searchfox.org/mozilla-central/source/testing/web-platform/tests/html/infrastructure/urls/base-url/document-base-url-window-initiator-is-not-opener.https.window.js) Edit: this test uses `window.open()` without specifying `about:blank` which appears to be broken. Fixing this first might change how this test behaves. I'm thinking that the navigation to a different base url shouldn't actually lead to the sync `about:blank` handling. The **problem** is that when setting `location.href=about:blank` on an `about:blank` page, we don't fire `pagehide` nor change the `baseURI`. Secondary to fixing the test, there might be web interop problems here, as we fire a second sync load event, unlike Blink. In the test, we have some document with baseURI A that opens an `about:blank` popup. It also contains an iframe with a different baseURI B. When the iframe is loaded, it initiates a navigation via `location.href = about:blank` on the popup. The test expects that the popup changes to baseURI B and fires a `pagehide`. The test allows for this to happen async and doesn't consider whether there should be a second load event. Blink ~~changes baseURI sync,~~ fires `pagehide` async, then changes `baseURI` and fires no `load` (or clears the load listener beforehand?). We can also consider two similar cases: the iframe has the same baseURI as the parent or the parent itself does `location.href=about:blank`. In both cases, Blink will fire `pagehide` and change the `baseURI` from `about:blank` to the parent document's URI. For Gecko with the `about:blank` patch, nothing happens in the latter case while the former case only triggers a sync load event. Regarding the cause for this test failure. Without this patch, the `baseURI` is set in `Document::Reset`, reached via `Document::StartDocumentLoad` from the async channel load. `pagehide` is fired from `FirePageHideNotification` during `nsDocShell:CreateDocumentViewer`, also caused by the channel load. I tried to reconstruct what the spec says. [Navigate a navigable](https://html.spec.whatwg.org/#navigate) step 22.5.2 sets 'about base URL' in parallel and fires the `pagehide` much later in [unloading-documents](https://html.spec.whatwg.org/#unloading-documents:event-pagehide-3) via [applying the history step](https://html.spec.whatwg.org/#apply-the-history-step). I understand this so that the `baseURI` should be changed async. I didn't find under which conditions `navigate a navigable` causes a `load` event. I don't really know how to fix the test. Always firing `pagehide` for `about:blank` from `DoURILoad` causes the browser to become blank. Calling `Document::Reset(aboutBlankChannel)` causes a crash and wouldn't fix the test anyway, as `baseURI` was null [here](https://searchfox.org/mozilla-central/rev/ead020d3989d3e9477b353d3d117f9c0f4b16f53/dom/base/Document.cpp#2933-2938) for the `aboutBlankChannel`. Both `nsIURI` and `nsINestedURI` don't support getting the `baseURI` so I wouldn't really know how to obtain it any other way without directly depending on `nsNestedAboutURI`. Perhaps interesting, but less relevant are how browsers differ if we were to have a second iframe with `baseURI` C causing a second navigation of the popup. Blink will then block access to the popup due to cross-origin.
Two more tests ## [iframe-blank-inherit.meta/upgrade/iframe-tag](https://searchfox.org/mozilla-central/source/testing/web-platform/tests/upgrade-insecure-requests/gen/iframe-blank-inherit.meta/upgrade/iframe-tag.https.html) I didn't get into the details of what the test does, as it uses several utility functions making it difficult to isolate a single, short testcase. The test is for the `upgrade-insecure-requests` CSP. With the `about:blank` patch, we no longer call `loadInfo->SetUpgradeInsecureRequests` nor `Document::ApplySettingsFromCSP` via `InitCSP`, as :tschuster noted. Before `ApplySettingsFromCSP` would be called, there is also `mUpgradeInsecureRequests = loadInfo->GetUpgradeInsecureRequests()` in `StartDocumentLoad`. I see that this patch introduces `ApplyCspFromLoadInfo`, which does `mUpgradeInsecureRequests = loadInfo->GetUpgradeInsecureRequests()` for `about:blank` where `StartDocumentLoad` doesn't happen. But that `loadInfo` is created a few lines before without ever invoking `SetUpgradeInsecureRequests`. So it doesn't help. I tried replicating `loadInfo->SetUpgradeInsecureRequests` from [here](https://searchfox.org/mozilla-central/rev/ead020d3989d3e9477b353d3d117f9c0f4b16f53/docshell/base/nsDocShell.cpp#10023) in `DoURILoad`, but that didn't help either. What **would fix** the test is doing `doc->ApplySettingsFromCSP(false)` in `DoURILoad` within the `isAboutBlankLoadOntoInitialAboutBlank` branch. I'm concerned that I'm cherry picking lines from `StartDocumentLoad` till tests work, but other things might still be missing. ## [document-base-url-window-initiator-is-not-opener](https://searchfox.org/mozilla-central/source/testing/web-platform/tests/html/infrastructure/urls/base-url/document-base-url-window-initiator-is-not-opener.https.window.js) **Edit**: this test uses `window.open()` without specifying `about:blank` which appears to be broken. Fixing this first might change how this test behaves. I'm thinking that the navigation to a different base url shouldn't actually lead to the sync `about:blank` handling. The **problem** is that when setting `location.href=about:blank` on an `about:blank` page, we don't fire `pagehide` nor change the `baseURI`. Secondary to fixing the test, there might be web interop problems here, as we fire a second sync load event, unlike Blink. In the test, we have some document with baseURI A that opens an `about:blank` popup. It also contains an iframe with a different baseURI B. When the iframe is loaded, it initiates a navigation via `location.href = about:blank` on the popup. The test expects that the popup changes to baseURI B and fires a `pagehide`. The test allows for this to happen async and doesn't consider whether there should be a second load event. Blink ~~changes baseURI sync,~~ fires `pagehide` async, then changes `baseURI` and fires no `load` (or clears the load listener beforehand?). We can also consider two similar cases: the iframe has the same baseURI as the parent or the parent itself does `location.href=about:blank`. In both cases, Blink will fire `pagehide` and change the `baseURI` from `about:blank` to the parent document's URI. For Gecko with the `about:blank` patch, nothing happens in the latter case while the former case only triggers a sync load event. Regarding the cause for this test failure. Without this patch, the `baseURI` is set in `Document::Reset`, reached via `Document::StartDocumentLoad` from the async channel load. `pagehide` is fired from `FirePageHideNotification` during `nsDocShell:CreateDocumentViewer`, also caused by the channel load. I tried to reconstruct what the spec says. [Navigate a navigable](https://html.spec.whatwg.org/#navigate) step 22.5.2 sets 'about base URL' in parallel and fires the `pagehide` much later in [unloading-documents](https://html.spec.whatwg.org/#unloading-documents:event-pagehide-3) via [applying the history step](https://html.spec.whatwg.org/#apply-the-history-step). I understand this so that the `baseURI` should be changed async. I didn't find under which conditions `navigate a navigable` causes a `load` event. I don't really know how to fix the test. Always firing `pagehide` for `about:blank` from `DoURILoad` causes the browser to become blank. Calling `Document::Reset(aboutBlankChannel)` causes a crash and wouldn't fix the test anyway, as `baseURI` was null [here](https://searchfox.org/mozilla-central/rev/ead020d3989d3e9477b353d3d117f9c0f4b16f53/dom/base/Document.cpp#2933-2938) for the `aboutBlankChannel`. Both `nsIURI` and `nsINestedURI` don't support getting the `baseURI` so I wouldn't really know how to obtain it any other way without directly depending on `nsNestedAboutURI`. Perhaps interesting, but less relevant are how browsers differ if we were to have a second iframe with `baseURI` C causing a second navigation of the popup. Blink will then block access to the popup due to cross-origin.