Bug 1825623 - Restore nsFileControlFrame fragmentation behavior. r=TYLin

nsCSSFrameConstructor::CreateContinuingFrame creates a frame based on the
result of nsIFrame::Type(). The regressing bug changed the nsFileControlFrame
type from Block to its own FileControlType type, which meant that we stopped
creating nsBlockFrame continuations for it.

Fix it by restoring the previous behavior: changing the Type() back to return
Block, and using QueryFrame instead to check for the specific
nsFileControlFrame where we need to.

This is all rather messy, see bug 1555477 for related discussion.

Differential Revision: https://phabricator.services.mozilla.com/D175062

layout/base/nsCSSFrameConstructor.cpp

@@ -52,6 +52,7 @@
 #include "nsTableColFrame.h"
 #include "nsTableRowFrame.h"
 #include "nsTableCellFrame.h"
+#include "nsFileControlFrame.h"
 #include "nsHTMLParts.h"
 #include "nsUnicharUtils.h"
 #include "nsViewManager.h"
@@ -3476,7 +3477,7 @@ nsCSSFrameConstructor::FindHTMLData(const Element& aElement,
 
   if (aElement.IsInNativeAnonymousSubtree() &&
       aElement.NodeInfo()->NameAtom() == nsGkAtoms::label &&
-      aParentFrame->IsFileControlFrame()) {
+      static_cast<nsFileControlFrame*>(do_QueryFrame(aParentFrame))) {
     static constexpr FrameConstructionData sFileLabelData(
         NS_NewFileControlLabelFrame);
     return &sFileLabelData;