Bug 1876702 - Remove unnecessary distinction between TYPE_FALLBACK and TYPE_NULL. r=smaug

The frame constructor always treats them the same nowadays
(TYPE_FALLBACK used to mean "show the pluginproblem code").

Differential Revision: https://phabricator.services.mozilla.com/D199719
This commit is contained in:
Emilio Cobos Álvarez
2024-01-29 16:14:09 +00:00
parent 9fca7ce713
commit 679a43f9a1
13 changed files with 126 additions and 198 deletions

View File

@@ -3670,19 +3670,14 @@ nsCSSFrameConstructor::FindObjectData(const Element& aElement,
"nsIObjectLoadingContent!");
objContent->GetDisplayedType(&type);
if (type == nsIObjectLoadingContent::TYPE_FALLBACK &&
!StaticPrefs::layout_use_plugin_fallback()) {
type = nsIObjectLoadingContent::TYPE_NULL;
}
static constexpr FrameConstructionDataByInt sObjectData[] = {
// TODO(emilio): Can we remove the NS_NewEmptyFrame case and just use a
// subdocument frame here?
SIMPLE_INT_CREATE(nsIObjectLoadingContent::TYPE_LOADING,
NS_NewEmptyFrame),
SIMPLE_INT_CREATE(nsIObjectLoadingContent::TYPE_FALLBACK,
ToCreationFunc(NS_NewBlockFrame)),
SIMPLE_INT_CREATE(nsIObjectLoadingContent::TYPE_DOCUMENT,
NS_NewSubDocumentFrame),
// Nothing for TYPE_NULL so we'll construct frames by display there
// Nothing for TYPE_FALLBACK so we'll construct frames by display there
};
return FindDataByInt((int32_t)type, aElement, aStyle, sObjectData,