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:
@@ -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,
|
||||
|
||||
Reference in New Issue
Block a user