This is a short-term solution to our inability to apply CSP to
chrome-privileged documents.
Ideally, we should be preventing all inline script execution in
chrome-privileged documents, since the reprecussions of XSS in chrome
documents are much worse than in content documents. Unfortunately, that's not
possible in the near term because a) we don't support CSP in system principal
documents at all, and b) we rely heavily on inline JS in our static XUL.
This stop-gap solution at least prevents some of the most common vectors of
XSS attack, by automatically sanitizing any HTML fragment created for a
chrome-privileged document.
MozReview-Commit-ID: 5w17celRFr
Most of the Shadow DOM related code are behind "dom.webcomponents.enabled" and
this pref is only used by Shadow DOM right now, so we should rename it to
"dom.webcomponents.shadowdom.enabled"
MozReview-Commit-ID: er1c7AsSSW
The whole function doesn't have much sense.
I killed its only DOM use in bug 1427511.
Now it only has two callers in nsCSSFrameConstructor, which basically only want
to know whether the children of the same node can have different flattened tree
parents.
So let's check that directly instead (checking whether the element has a binding
or a shadow root), and simplify a bit other surrounding code while at it.
Leave the XUL popup / menubar code doing the broken thing they were doing
beforehand, because it doesn't look to me like it's trivial to fix... They're
effectively assuming that the children of the menupopup end up in a single
insertion point, which is true, but doesn't need to be. Maybe they should walk
the DOM tree? Don't want to dig into that right now, since XUL insertion points
can be filtered and all that... Not fun.
Also, this removes the broken optimization that used to check
mParentFrame->GetContent()->HasChildren(), because it's pretty broken. It used
to be relevant before bug 653881, because <children> element used to not exist,
but now the insertion point at least needs to contain the <children> element all
the time.
There even used to be a XXX comment saying that the optimization didn't work,
which was removed in:
https://hg.mozilla.org/mozilla-central/rev/2d8585ec74b3
We could still check for "no insertion points", and optimize that, but it
doesn't seem worth it.
MozReview-Commit-ID: L4lspkxKENr
nsContentUtils::ExtractErrorValues converts `aSourceSpecOut` from
UTF-16 to UTF-8, which is generally not what we want. This patch
introduces a new version of ExtractErrorValues that doesn't perform
the conversion. To keep the patch short and avoid rewriting existing
clients, the existing version of the function is left in place.
MozReview-Commit-ID: J2NQb5ZCfht
nsContentUtils::ExtractErrorValues converts `aSourceSpecOut` from
UTF-16 to UTF-8, which is generally not what we want. This patch
introduces a new version of ExtractErrorValues that doesn't perform
the conversion. To keep the patch short and avoid rewriting existing
clients, the existing version of the function is left in place.
MozReview-Commit-ID: J2NQb5ZCfht
This is to fix the case where preference is restore to false when a testcase
ends, but nsDocument::DeleteShell is called afterwards. So, we make the
preference per-doc and set it when the document is created. The value does not
change for the lifetime of the document.
This is to fix the case where preference is restore to false when a
testcas ends, but nsDocument::DeleteShell is called afterwards. So, we
make the preference per-doc and once it is enabled for a document, it
stays enabled.
