Bug 1402366: Mark datetimebox as not needing xul.css. r?bholley,jessica
We create a datetimebox in content documents that gets an XBL binding on
nsDateTimeControlFrame::CreateAnonymousContent.
This is done during frame construction, and loading a datetimebox insert xul.css
in the document, which causes invalidation to run.
datetimebox styles are in html.css, and there's no rule in xul.css that styles
it, so we don't need to load the stylesheet at all.
MozReview-Commit-ID: 2SbIOoER2uB
--- a/dom/xul/nsXULElement.cpp
+++ b/dom/xul/nsXULElement.cpp
@@ -691,16 +691,17 @@ static inline bool XULElementsRulesInMin
return // scrollbar parts:
aTag == nsGkAtoms::scrollbar ||
aTag == nsGkAtoms::scrollbarbutton ||
aTag == nsGkAtoms::scrollcorner ||
aTag == nsGkAtoms::slider ||
aTag == nsGkAtoms::thumb ||
aTag == nsGkAtoms::scale ||
// other
+ aTag == nsGkAtoms::datetimebox ||
aTag == nsGkAtoms::resizer ||
aTag == nsGkAtoms::label ||
aTag == nsGkAtoms::videocontrols;
}
#ifdef DEBUG
/**
* Returns true if aElement is a XUL element created by the video controls
@@ -805,19 +806,17 @@ nsXULElement::BindToTree(nsIDocument* aD
// for HTML we currently should only pull it in if the document contains
// an <audio> or <video> element. This assertion is here to make sure
// that we don't fail to notice if a change to bindings causes us to
// start pulling in xul.css much more frequently. If this assertion
// fails then we need to figure out why, and how we can continue to avoid
// pulling in xul.css.
// Note that add-ons may introduce bindings that cause this assertion to
// fire.
- NS_ASSERTION(IsInVideoControls(this) ||
- IsInFeedSubscribeLine(this) ||
- IsXULElement(nsGkAtoms::datetimebox),
+ NS_ASSERTION(IsInVideoControls(this) || IsInFeedSubscribeLine(this),
"Unexpected XUL element in non-XUL doc");
}
}
if (aDocument) {
NS_ASSERTION(!nsContentUtils::IsSafeToRunScript(),
"Missing a script blocker!");
// We're in a document now. Kick off the frame load.