From 94699183f24729a32619652a4b95653a66f176a5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Emilio=20Cobos=20=C3=81lvarez?= Date: Wed, 17 Aug 2022 20:53:23 +0000 Subject: [PATCH] Bug 1782071 - Invalidate the undisplayed style cache on ContentRemoved. r=boris See comment. Not sure how easy to test this is in practice since it involves nodes getting cc'd. I tried to repro (not too hard) with a crashtest running SpecialPowers.gc() but that didn't cut it, looks like. Differential Revision: https://phabricator.services.mozilla.com/D154891 --- layout/base/RestyleManager.cpp | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/layout/base/RestyleManager.cpp b/layout/base/RestyleManager.cpp index d32b74a5f73a..f8e60dd94c61 100644 --- a/layout/base/RestyleManager.cpp +++ b/layout/base/RestyleManager.cpp @@ -376,8 +376,14 @@ void RestyleManager::ContentRemoved(nsIContent* aOldChild, // Computed style data isn't useful for detached nodes, and we'll need to // recompute it anyway if we ever insert the nodes back into a document. - if (aOldChild->IsElement()) { - RestyleManager::ClearServoDataFromSubtree(aOldChild->AsElement()); + if (auto* element = Element::FromNode(aOldChild)) { + RestyleManager::ClearServoDataFromSubtree(element); + // If this element is undisplayed or may have undisplayed descendants, we + // need to invalidate the cache, since there's the unlikely event of those + // elements getting destroyed and their addresses reused in a way that we + // look up the cache with their address for a different element before it's + // invalidated. + IncrementUndisplayedRestyleGeneration(); } // The container might be a document or a ShadowRoot.