Bug 1803317 - Assert that mOpQueue is empty in ~nsHtml5TreeOpExecutor. r=edgar

The purpose is to be alerted of cases when ops were supposed to execute
but did not.

Differential Revision: https://phabricator.services.mozilla.com/D163425
This commit is contained in:
Henri Sivonen 2022-11-30 16:57:02 +00:00
parent 45f7cb5695
commit 8ea599da16

View File

@ -141,16 +141,8 @@ nsHtml5TreeOpExecutor::~nsHtml5TreeOpExecutor() {
}
}
}
// We used to have an `NS_ASSERTION` here that asserted
// that either `mBroken` is true or `mOpQueue` is empty.
// Sometimes a tree op executor ended up being cycle collected
// with the assertion firing. It is not understood what
// code path abandons an instance of the tree op executor
// without terminating it so that the cycle collector sees
// it with stuff still in the queue. The assertion was removed
// to avoid sheriffing the assertion failure without a path
// to understanding how the object gets abandoned to cycle
// collection.
MOZ_ASSERT(NS_FAILED(mBroken) || mOpQueue.IsEmpty(),
"Somehow there's stuff in the op queue.");
}
// nsIContentSink
@ -181,6 +173,13 @@ nsHtml5TreeOpExecutor::DidBuildModel(bool aTerminated) {
MOZ_RELEASE_ASSERT(!IsInDocUpdate(),
"DidBuildModel from inside a doc update.");
RefPtr<nsHtml5TreeOpExecutor> pin(this);
auto queueClearer = MakeScopeExit([&] {
if (aTerminated && (mFlushState == eNotFlushing)) {
ClearOpQueue(); // clear in order to be able to assert in destructor
}
});
// This comes from nsXMLContentSink and nsHTMLContentSink
// If this parser has been marked as broken, treat the end of parse as
// forced termination.