Bugzilla

These stacks are all looking hefty strange. As far as I can tell they all come into [`nsDocShell::DoURILoad`](https://crash-stats.mozilla.org/report/index/a5d050a7-7c45-4e15-ae0d-90f800230802), where they call [`nsDocShell::OpenInitializedChannel`](https://searchfox.org/mozilla-central/source/docshell/base/nsDocShell.cpp#10620). This is always called with a freshly created [`DocumentChannel`](https://searchfox.org/mozilla-central/source/docshell/base/nsDocShell.cpp#10563-10565). We calculate the [`nsLoadFlags`](https://searchfox.org/mozilla-central/source/docshell/base/nsDocShell.cpp#10557-10558) just before creating the channel, so we should really be able to assume that they're correct at that point. Then we don't touch the load flags of the `DocumentChannel` until we've entered [`nsURILoader::OpenURI`](https://searchfox.org/mozilla-central/source/uriloader/base/nsURILoader.cpp#705-706).

It is here, when we're calling [`DocumentChannelChild::AsyncOpen`](https://searchfox.org/mozilla-central/source/netwerk/ipc/DocumentChannelChild.cpp#64) that we'll assert when we add the `DocumentChannelChild` to the loadGroup in [`nsLoadGroup::AddRequest`](https://searchfox.org/mozilla-central/source/netwerk/ipc/DocumentChannelChild.cpp#85). Note that we're adding `DocumentChannelChild` to its own load group! That load group was set a few lines earlier as a result of calling [nsURILoader::OpenChannel](`https://searchfox.org/mozilla-central/source/uriloader/base/nsURILoader.cpp#743-746`), which in turn is extracted from the `nsDocShell` that we're calling `DoLoadURI` on.

I'm not sure if it's [`nsLoadGroup::MergeDefaultLoadFlags`](https://searchfox.org/mozilla-central/source/netwerk/base/nsLoadGroup.cpp#1035-1036) or [`nsLoadGroup::MergeLoadFlags`](https://searchfox.org/mozilla-central/source/netwerk/base/nsLoadGroup.cpp#1007-1008) that asserts. That's optimized out.

But as far as I can tell the problem is that the load group doesn't have the same load flags as the browsing context has. Is this a problem with how we compute the load flags in [`nsDocShellLoadState::CalculateChannelLoadFlags`](https://searchfox.org/mozilla-central/source/docshell/base/nsDocShellLoadState.cpp#1063-1065)? We never suspend execution by posting the the queue, this is happening linearly.

This is in line with what :kmag found in comment 10.

I'm at a bit of a loss of how to resolve this. :kmag, :nika any ideas?

These stacks are all looking hefty strange. As far as I can tell they all come into [`nsDocShell::DoURILoad`](https://crash-stats.mozilla.org/report/index/a5d050a7-7c45-4e15-ae0d-90f800230802), where they call [`nsDocShell::OpenInitializedChannel`](https://searchfox.org/mozilla-central/source/docshell/base/nsDocShell.cpp#10620). This is always called with a freshly created [`DocumentChannel`](https://searchfox.org/mozilla-central/source/docshell/base/nsDocShell.cpp#10563-10565). We calculate the [`nsLoadFlags`](https://searchfox.org/mozilla-central/source/docshell/base/nsDocShell.cpp#10557-10558) just before creating the channel, so we should really be able to assume that they're correct at that point. Then we don't touch the load flags of the `DocumentChannel` until we've entered [`nsURILoader::OpenURI`](https://searchfox.org/mozilla-central/source/uriloader/base/nsURILoader.cpp#705-706).

It is here, when we're calling [`DocumentChannelChild::AsyncOpen`](https://searchfox.org/mozilla-central/source/netwerk/ipc/DocumentChannelChild.cpp#64) that we'll assert when we add the `DocumentChannelChild` to the loadGroup in [`nsLoadGroup::AddRequest`](https://searchfox.org/mozilla-central/source/netwerk/ipc/DocumentChannelChild.cpp#85). Note that we're adding `DocumentChannelChild` to its own load group! That load group was set a few lines earlier as a result of calling [nsURILoader::OpenChannel](`https://searchfox.org/mozilla-central/source/uriloader/base/nsURILoader.cpp#743-746`), which in turn is extracted from the `nsDocShell` that we're calling `DoLoadURI` on.

I'm not sure if it's [`nsLoadGroup::MergeDefaultLoadFlags`](https://searchfox.org/mozilla-central/source/netwerk/base/nsLoadGroup.cpp#1035-1036) or [`nsLoadGroup::MergeLoadFlags`](https://searchfox.org/mozilla-central/source/netwerk/base/nsLoadGroup.cpp#1007-1008) that asserts. That's optimized out.

But as far as I can tell the problem is that the load group doesn't have the same load flags as the browsing context has. Is this a problem with how we compute the load flags in [`nsDocShellLoadState::CalculateChannelLoadFlags`](https://searchfox.org/mozilla-central/source/docshell/base/nsDocShellLoadState.cpp#1063-1065)? We never suspend execution by returning to the main loop, this is happening linearly.

This is in line with what :kmag found in comment 10.

I'm at a bit of a loss of how to resolve this. :kmag, :nika any ideas?

These stacks are all looking hefty strange. As far as I can tell they all come into [`nsDocShell::DoURILoad`](https://crash-stats.mozilla.org/report/index/a5d050a7-7c45-4e15-ae0d-90f800230802), where they call [`nsDocShell::OpenInitializedChannel`](https://searchfox.org/mozilla-central/rev/dc8348b3730c0d29dafd01c653d9151eaa9bc30f/docshell/base/nsDocShell.cpp#10627). This is always called with a freshly created [`DocumentChannel`](https://searchfox.org/mozilla-central/rev/dc8348b3730c0d29dafd01c653d9151eaa9bc30f/docshell/base/nsDocShell.cpp#10570-10572). We calculate the [`nsLoadFlags`](https://searchfox.org/mozilla-central/source/docshell/base/nsDocShell.cpp#10557-10558) just before creating the channel, so we should really be able to assume that they're correct at that point. Then we don't touch the load flags of the `DocumentChannel` until we've entered [`nsURILoader::OpenURI`](https://searchfox.org/mozilla-central/source/uriloader/base/nsURILoader.cpp#705-706).

It is here, when we're calling [`DocumentChannelChild::AsyncOpen`](https://searchfox.org/mozilla-central/source/netwerk/ipc/DocumentChannelChild.cpp#64) that we'll assert when we add the `DocumentChannelChild` to the loadGroup in [`nsLoadGroup::AddRequest`](https://searchfox.org/mozilla-central/source/netwerk/ipc/DocumentChannelChild.cpp#85). Note that we're adding `DocumentChannelChild` to its own load group! That load group was set a few lines earlier as a result of calling [nsURILoader::OpenChannel](`https://searchfox.org/mozilla-central/source/uriloader/base/nsURILoader.cpp#743-746`), which in turn is extracted from the `nsDocShell` that we're calling `DoLoadURI` on.

I'm not sure if it's [`nsLoadGroup::MergeDefaultLoadFlags`](https://searchfox.org/mozilla-central/source/netwerk/base/nsLoadGroup.cpp#1035-1036) or [`nsLoadGroup::MergeLoadFlags`](https://searchfox.org/mozilla-central/source/netwerk/base/nsLoadGroup.cpp#1007-1008) that asserts. That's optimized out.

But as far as I can tell the problem is that the load group doesn't have the same load flags as the browsing context has. Is this a problem with how we compute the load flags in [`nsDocShellLoadState::CalculateChannelLoadFlags`](https://searchfox.org/mozilla-central/source/docshell/base/nsDocShellLoadState.cpp#1063-1065)? We never suspend execution by returning to the main loop, this is happening linearly.

This is in line with what :kmag found in comment 10.

I'm at a bit of a loss of how to resolve this. :kmag, :nika any ideas?

These stacks are all looking hefty strange. As far as I can tell they all come into [`nsDocShell::DoURILoad`](https://crash-stats.mozilla.org/report/index/a5d050a7-7c45-4e15-ae0d-90f800230802), where they call [`nsDocShell::OpenInitializedChannel`](https://searchfox.org/mozilla-central/rev/dc8348b3730c0d29dafd01c653d9151eaa9bc30f/docshell/base/nsDocShell.cpp#10627). This is always called with a freshly created [`DocumentChannel`](https://searchfox.org/mozilla-central/rev/dc8348b3730c0d29dafd01c653d9151eaa9bc30f/docshell/base/nsDocShell.cpp#10570-10572). We calculate the [`nsLoadFlags`](https://searchfox.org/mozilla-central/rev/dc8348b3730c0d29dafd01c653d9151eaa9bc30f/docshell/base/nsDocShell.cpp#10564-10565) just before creating the channel, so we should really be able to assume that they're correct at that point. Then we don't touch the load flags of the `DocumentChannel` until we've entered [`nsURILoader::OpenURI`](https://searchfox.org/mozilla-central/source/uriloader/base/nsURILoader.cpp#705-706).

It is here, when we're calling [`DocumentChannelChild::AsyncOpen`](https://searchfox.org/mozilla-central/source/netwerk/ipc/DocumentChannelChild.cpp#64) that we'll assert when we add the `DocumentChannelChild` to the loadGroup in [`nsLoadGroup::AddRequest`](https://searchfox.org/mozilla-central/source/netwerk/ipc/DocumentChannelChild.cpp#85). Note that we're adding `DocumentChannelChild` to its own load group! That load group was set a few lines earlier as a result of calling [nsURILoader::OpenChannel](`https://searchfox.org/mozilla-central/source/uriloader/base/nsURILoader.cpp#743-746`), which in turn is extracted from the `nsDocShell` that we're calling `DoLoadURI` on.

I'm not sure if it's [`nsLoadGroup::MergeDefaultLoadFlags`](https://searchfox.org/mozilla-central/source/netwerk/base/nsLoadGroup.cpp#1035-1036) or [`nsLoadGroup::MergeLoadFlags`](https://searchfox.org/mozilla-central/source/netwerk/base/nsLoadGroup.cpp#1007-1008) that asserts. That's optimized out.

But as far as I can tell the problem is that the load group doesn't have the same load flags as the browsing context has. Is this a problem with how we compute the load flags in [`nsDocShellLoadState::CalculateChannelLoadFlags`](https://searchfox.org/mozilla-central/source/docshell/base/nsDocShellLoadState.cpp#1063-1065)? We never suspend execution by returning to the main loop, this is happening linearly.

This is in line with what :kmag found in comment 10.

I'm at a bit of a loss of how to resolve this. :kmag, :nika any ideas?

These stacks are all looking hefty strange. As far as I can tell they all come into [`nsDocShell::DoURILoad`](https://crash-stats.mozilla.org/report/index/a5d050a7-7c45-4e15-ae0d-90f800230802), where they call [`nsDocShell::OpenInitializedChannel`](https://searchfox.org/mozilla-central/rev/dc8348b3730c0d29dafd01c653d9151eaa9bc30f/docshell/base/nsDocShell.cpp#10627). This is always called with a freshly created [`DocumentChannel`](https://searchfox.org/mozilla-central/rev/dc8348b3730c0d29dafd01c653d9151eaa9bc30f/docshell/base/nsDocShell.cpp#10570-10572). We calculate the [`nsLoadFlags`](https://searchfox.org/mozilla-central/rev/dc8348b3730c0d29dafd01c653d9151eaa9bc30f/docshell/base/nsDocShell.cpp#10564-10565) just before creating the channel, so we should really be able to assume that they're correct at that point. Then we don't touch the load flags of the `DocumentChannel` until we've entered [`nsURILoader::OpenURI`](https://searchfox.org/mozilla-central/rev/dc8348b3730c0d29dafd01c653d9151eaa9bc30f/uriloader/base/nsURILoader.cpp#705-706).

It is here, when we're calling [`DocumentChannelChild::AsyncOpen`](https://searchfox.org/mozilla-central/source/netwerk/ipc/DocumentChannelChild.cpp#64) that we'll assert when we add the `DocumentChannelChild` to the loadGroup in [`nsLoadGroup::AddRequest`](https://searchfox.org/mozilla-central/source/netwerk/ipc/DocumentChannelChild.cpp#85). Note that we're adding `DocumentChannelChild` to its own load group! That load group was set a few lines earlier as a result of calling [nsURILoader::OpenChannel](`https://searchfox.org/mozilla-central/source/uriloader/base/nsURILoader.cpp#743-746`), which in turn is extracted from the `nsDocShell` that we're calling `DoLoadURI` on.

I'm not sure if it's [`nsLoadGroup::MergeDefaultLoadFlags`](https://searchfox.org/mozilla-central/source/netwerk/base/nsLoadGroup.cpp#1035-1036) or [`nsLoadGroup::MergeLoadFlags`](https://searchfox.org/mozilla-central/source/netwerk/base/nsLoadGroup.cpp#1007-1008) that asserts. That's optimized out.

But as far as I can tell the problem is that the load group doesn't have the same load flags as the browsing context has. Is this a problem with how we compute the load flags in [`nsDocShellLoadState::CalculateChannelLoadFlags`](https://searchfox.org/mozilla-central/source/docshell/base/nsDocShellLoadState.cpp#1063-1065)? We never suspend execution by returning to the main loop, this is happening linearly.

This is in line with what :kmag found in comment 10.

I'm at a bit of a loss of how to resolve this. :kmag, :nika any ideas?

These stacks are all looking hefty strange. As far as I can tell they all come into [`nsDocShell::DoURILoad`](https://crash-stats.mozilla.org/report/index/a5d050a7-7c45-4e15-ae0d-90f800230802), where they call [`nsDocShell::OpenInitializedChannel`](https://searchfox.org/mozilla-central/rev/dc8348b3730c0d29dafd01c653d9151eaa9bc30f/docshell/base/nsDocShell.cpp#10627). This is always called with a freshly created [`DocumentChannel`](https://searchfox.org/mozilla-central/rev/dc8348b3730c0d29dafd01c653d9151eaa9bc30f/docshell/base/nsDocShell.cpp#10570-10572). We calculate the [`nsLoadFlags`](https://searchfox.org/mozilla-central/rev/dc8348b3730c0d29dafd01c653d9151eaa9bc30f/docshell/base/nsDocShell.cpp#10564-10565) just before creating the channel, so we should really be able to assume that they're correct at that point. Then we don't touch the load flags of the `DocumentChannel` until we've entered [`nsURILoader::OpenURI`](https://searchfox.org/mozilla-central/rev/dc8348b3730c0d29dafd01c653d9151eaa9bc30f/uriloader/base/nsURILoader.cpp#705-706).

It is here, when we're calling [`DocumentChannelChild::AsyncOpen`](https://searchfox.org/mozilla-central/rev/dc8348b3730c0d29dafd01c653d9151eaa9bc30f/netwerk/ipc/DocumentChannelChild.cpp#64) that we'll assert when we add the `DocumentChannelChild` to the loadGroup in [`nsLoadGroup::AddRequest`](https://searchfox.org/mozilla-central/source/netwerk/ipc/DocumentChannelChild.cpp#85). Note that we're adding `DocumentChannelChild` to its own load group! That load group was set a few lines earlier as a result of calling [nsURILoader::OpenChannel](`https://searchfox.org/mozilla-central/source/uriloader/base/nsURILoader.cpp#743-746`), which in turn is extracted from the `nsDocShell` that we're calling `DoLoadURI` on.

I'm not sure if it's [`nsLoadGroup::MergeDefaultLoadFlags`](https://searchfox.org/mozilla-central/source/netwerk/base/nsLoadGroup.cpp#1035-1036) or [`nsLoadGroup::MergeLoadFlags`](https://searchfox.org/mozilla-central/source/netwerk/base/nsLoadGroup.cpp#1007-1008) that asserts. That's optimized out.

But as far as I can tell the problem is that the load group doesn't have the same load flags as the browsing context has. Is this a problem with how we compute the load flags in [`nsDocShellLoadState::CalculateChannelLoadFlags`](https://searchfox.org/mozilla-central/source/docshell/base/nsDocShellLoadState.cpp#1063-1065)? We never suspend execution by returning to the main loop, this is happening linearly.

This is in line with what :kmag found in comment 10.

I'm at a bit of a loss of how to resolve this. :kmag, :nika any ideas?

These stacks are all looking hefty strange. As far as I can tell they all come into [`nsDocShell::DoURILoad`](https://crash-stats.mozilla.org/report/index/a5d050a7-7c45-4e15-ae0d-90f800230802), where they call [`nsDocShell::OpenInitializedChannel`](https://searchfox.org/mozilla-central/rev/dc8348b3730c0d29dafd01c653d9151eaa9bc30f/docshell/base/nsDocShell.cpp#10627). This is always called with a freshly created [`DocumentChannel`](https://searchfox.org/mozilla-central/rev/dc8348b3730c0d29dafd01c653d9151eaa9bc30f/docshell/base/nsDocShell.cpp#10570-10572). We calculate the [`nsLoadFlags`](https://searchfox.org/mozilla-central/rev/dc8348b3730c0d29dafd01c653d9151eaa9bc30f/docshell/base/nsDocShell.cpp#10564-10565) just before creating the channel, so we should really be able to assume that they're correct at that point. Then we don't touch the load flags of the `DocumentChannel` until we've entered [`nsURILoader::OpenURI`](https://searchfox.org/mozilla-central/rev/dc8348b3730c0d29dafd01c653d9151eaa9bc30f/uriloader/base/nsURILoader.cpp#705-706).

It is here, when we're calling [`DocumentChannelChild::AsyncOpen`](https://searchfox.org/mozilla-central/rev/dc8348b3730c0d29dafd01c653d9151eaa9bc30f/netwerk/ipc/DocumentChannelChild.cpp#64) that we'll assert when we add the `DocumentChannelChild` to the loadGroup in [`nsLoadGroup::AddRequest`](https://searchfox.org/mozilla-central/rev/dc8348b3730c0d29dafd01c653d9151eaa9bc30f/netwerk/ipc/DocumentChannelChild.cpp#85). Note that we're adding `DocumentChannelChild` to its own load group! That load group was set a few lines earlier as a result of calling [nsURILoader::OpenChannel](`https://searchfox.org/mozilla-central/source/uriloader/base/nsURILoader.cpp#743-746`), which in turn is extracted from the `nsDocShell` that we're calling `DoLoadURI` on.

I'm not sure if it's [`nsLoadGroup::MergeDefaultLoadFlags`](https://searchfox.org/mozilla-central/source/netwerk/base/nsLoadGroup.cpp#1035-1036) or [`nsLoadGroup::MergeLoadFlags`](https://searchfox.org/mozilla-central/source/netwerk/base/nsLoadGroup.cpp#1007-1008) that asserts. That's optimized out.

But as far as I can tell the problem is that the load group doesn't have the same load flags as the browsing context has. Is this a problem with how we compute the load flags in [`nsDocShellLoadState::CalculateChannelLoadFlags`](https://searchfox.org/mozilla-central/source/docshell/base/nsDocShellLoadState.cpp#1063-1065)? We never suspend execution by returning to the main loop, this is happening linearly.

This is in line with what :kmag found in comment 10.

I'm at a bit of a loss of how to resolve this. :kmag, :nika any ideas?

These stacks are all looking hefty strange. As far as I can tell they all come into [`nsDocShell::DoURILoad`](https://crash-stats.mozilla.org/report/index/a5d050a7-7c45-4e15-ae0d-90f800230802), where they call [`nsDocShell::OpenInitializedChannel`](https://searchfox.org/mozilla-central/rev/dc8348b3730c0d29dafd01c653d9151eaa9bc30f/docshell/base/nsDocShell.cpp#10627). This is always called with a freshly created [`DocumentChannel`](https://searchfox.org/mozilla-central/rev/dc8348b3730c0d29dafd01c653d9151eaa9bc30f/docshell/base/nsDocShell.cpp#10570-10572). We calculate the [`nsLoadFlags`](https://searchfox.org/mozilla-central/rev/dc8348b3730c0d29dafd01c653d9151eaa9bc30f/docshell/base/nsDocShell.cpp#10564-10565) just before creating the channel, so we should really be able to assume that they're correct at that point. Then we don't touch the load flags of the `DocumentChannel` until we've entered [`nsURILoader::OpenURI`](https://searchfox.org/mozilla-central/rev/dc8348b3730c0d29dafd01c653d9151eaa9bc30f/uriloader/base/nsURILoader.cpp#705-706).

It is here, when we're calling [`DocumentChannelChild::AsyncOpen`](https://searchfox.org/mozilla-central/rev/dc8348b3730c0d29dafd01c653d9151eaa9bc30f/netwerk/ipc/DocumentChannelChild.cpp#64) that we'll assert when we add the `DocumentChannelChild` to the loadGroup in [`nsLoadGroup::AddRequest`](https://searchfox.org/mozilla-central/rev/dc8348b3730c0d29dafd01c653d9151eaa9bc30f/netwerk/ipc/DocumentChannelChild.cpp#85). Note that we're adding `DocumentChannelChild` to its own load group! That load group was set a few lines earlier as a result of calling [`nsURILoader::OpenChannel`](https://searchfox.org/mozilla-central/source/uriloader/base/nsURILoader.cpp#743-746), which in turn is extracted from the `nsDocShell` that we're calling `DoLoadURI` on.

I'm not sure if it's [`nsLoadGroup::MergeDefaultLoadFlags`](https://searchfox.org/mozilla-central/source/netwerk/base/nsLoadGroup.cpp#1035-1036) or [`nsLoadGroup::MergeLoadFlags`](https://searchfox.org/mozilla-central/source/netwerk/base/nsLoadGroup.cpp#1007-1008) that asserts. That's optimized out.

But as far as I can tell the problem is that the load group doesn't have the same load flags as the browsing context has. Is this a problem with how we compute the load flags in [`nsDocShellLoadState::CalculateChannelLoadFlags`](https://searchfox.org/mozilla-central/source/docshell/base/nsDocShellLoadState.cpp#1063-1065)? We never suspend execution by returning to the main loop, this is happening linearly.

This is in line with what :kmag found in comment 10.

I'm at a bit of a loss of how to resolve this. :kmag, :nika any ideas?

These stacks are all looking hefty strange. As far as I can tell they all come into [`nsDocShell::DoURILoad`](https://crash-stats.mozilla.org/report/index/a5d050a7-7c45-4e15-ae0d-90f800230802), where they call [`nsDocShell::OpenInitializedChannel`](https://searchfox.org/mozilla-central/rev/dc8348b3730c0d29dafd01c653d9151eaa9bc30f/docshell/base/nsDocShell.cpp#10627). This is always called with a freshly created [`DocumentChannel`](https://searchfox.org/mozilla-central/rev/dc8348b3730c0d29dafd01c653d9151eaa9bc30f/docshell/base/nsDocShell.cpp#10570-10572). We calculate the [`nsLoadFlags`](https://searchfox.org/mozilla-central/rev/dc8348b3730c0d29dafd01c653d9151eaa9bc30f/docshell/base/nsDocShell.cpp#10564-10565) just before creating the channel, so we should really be able to assume that they're correct at that point. Then we don't touch the load flags of the `DocumentChannel` until we've entered [`nsURILoader::OpenURI`](https://searchfox.org/mozilla-central/rev/dc8348b3730c0d29dafd01c653d9151eaa9bc30f/uriloader/base/nsURILoader.cpp#705-706).

It is here, when we're calling [`DocumentChannelChild::AsyncOpen`](https://searchfox.org/mozilla-central/rev/dc8348b3730c0d29dafd01c653d9151eaa9bc30f/netwerk/ipc/DocumentChannelChild.cpp#64) that we'll assert when we add the `DocumentChannelChild` to the loadGroup in [`nsLoadGroup::AddRequest`](https://searchfox.org/mozilla-central/rev/dc8348b3730c0d29dafd01c653d9151eaa9bc30f/netwerk/ipc/DocumentChannelChild.cpp#85). Note that we're adding `DocumentChannelChild` to its own load group! That load group was set a few lines earlier as a result of calling [`nsURILoader::OpenChannel`](https://searchfox.org/mozilla-central/rev/dc8348b3730c0d29dafd01c653d9151eaa9bc30f/uriloader/base/nsURILoader.cpp#743-746), which in turn is extracted from the `nsDocShell` that we're calling `DoLoadURI` on.

I'm not sure if it's [`nsLoadGroup::MergeDefaultLoadFlags`](https://searchfox.org/mozilla-central/rev/dc8348b3730c0d29dafd01c653d9151eaa9bc30f/netwerk/base/nsLoadGroup.cpp#1035-1036) or [`nsLoadGroup::MergeLoadFlags`](https://searchfox.org/mozilla-central/rev/dc8348b3730c0d29dafd01c653d9151eaa9bc30f/netwerk/base/nsLoadGroup.cpp#1007-1008) that asserts. That's optimized out.

But as far as I can tell the problem is that the load group doesn't have the same load flags as the browsing context has. Is this a problem with how we compute the load flags in [`nsDocShellLoadState::CalculateChannelLoadFlags`](https://searchfox.org/mozilla-central/rev/dc8348b3730c0d29dafd01c653d9151eaa9bc30f/docshell/base/nsDocShellLoadState.cpp#1063-1065)? We never suspend execution by returning to the main loop, this is happening linearly.

This is in line with what :kmag found in comment 10.

I'm at a bit of a loss of how to resolve this. :kmag, :nika any ideas?