Now that what we use to decide whether a document is styled by Servo are only
prefs and the doc principal, we don't need to inherit the style backend type,
since unless the pref has changed, the result will be the same.
MozReview-Commit-ID: KBmeBn1cRne
Poking at the frame tree has problems: If we poke in negative (using
eSkipNativeAnonymousContent), as we were doing, we mess up the case where we're
actually _not_ doc-level, and _not_ ::before or ::after. This can't happen for
content documents, but can happen for chrome (since nsDocElementBoxFrame
implements nsIAnonymousContentCreator).
If we poke in positive, as we used to, you get that right, but mess up the
root scrollbar case.
Instead, use a node property to mark doc level anon content. This is a case rare
enough that it seems worth to not steal a node bit.
To recap the failure:
* The initial value of -moz-control-character-visiblity is different on beta
and nightly.
* XUL has a global rule setting -moz-control-character-visibility on the root,
to a value so that it's the initial one on nightly, but the non-initial one
on beta.
* Changes to this property cause a reframe.
* Reframes of a nsIAnonymousContentCreator anon content reframe the container.
* We were failing to inherit correctly for the nsIAnonymousContentCreator
content for the root XUL element on the initial styling, inheriting from the
default computed values instead, since we failed to reach the root element's
primary frame from GetFlattenedTreeParentForDocumentElementNAC ->
AppendDocumentLevelNativeAnonymousContentTo, since the primary frame is set
_after_ processing children.
This seems somewhat risky to change, and inconsistent with any other stuff
the frame constructor does, see bug 973390.
* Given that, the next restyle of the root element, in this case caused due to
the customizable UI, we _found_ the actual correct parent, recomputed the
style, saw that -moz-control-character-visiblity had changed, and reframed.
But we were reframing the whole window, not just the NAC, because of the
fourth bullet point. Reframing the whole window caused us to lose the popup
state (that's bug 1440506).
Worse than that is the fact that given we reframe and reconstruct the
anonymous countent again, we go back to the initial bogus state, just
awaiting for the next restyle to reframe the whole window.
I wish there was a bullet-proof way to test it that isn't just counting reframes
and relying on which properties reframe or not, but due to the nature of
nsIAnonymousContentCreator's NAC, it's not possible in any easy way I can think
of.
MozReview-Commit-ID: IPYB5trsN8R
It would be convenient to get nsPresContext from nsIDocument.
MozReview-Commit-ID: Ei6V3UE8XGr
--HG--
extra : rebase_source : 8d2a917eb62cf341e4e1810451fd01c01dbc3bad
nsIDOMWindowUtils::sendKeyEvent() is already replaced with nsITextInputProcessor
for making callers set any attributes of KeyboardEvent and guaranteeing
consistency behavior with keyboard events caused by native key events. E.g.,
whether keypress event should be dispatched or not is automatically decided.
nsIFrameLoader::sendCrossProcessKeyEvent() is similart to
nsIDOMWindowUtils::sendKeyEvent() but it dispatches keyboard events in
child process directly. Currently, nsITextInputProcessor doesn't have this
feature but nobody wants/uses this feature. So, for removing actual
implementation of nsIDOMWindowUtils::sendKeyEvent(), i.e.,
nsContentUtils::SendKeyEvent(), which is shared by both
nsDOMWindowUtils::SendKeyEvent() and nsFrameLoader::SendCrossProcessKeyEvent(),
we should remove this unused API too. (FYI: it's implemented for old Fennec,
by bug 553149.)
MozReview-Commit-ID: 9n0UVo8Me8k
--HG--
extra : rebase_source : e9b117f5b9afec76e63d57ab8cd86dafb5873789
Since we are dealing with the element (nodeInfo->LocalName() and NameAtom() are the same value),
we could use nodeInfo->NameAtom() instead.
MozReview-Commit-ID: 4vIBDEM1Nwv
--HG--
extra : rebase_source : 150d5ea982363eb2ef4c5039fae67be1e08884ba
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
--HG--
extra : rebase_source : 1c0a1448a06d5b65e548d9f5362d06cc6d865dbe
extra : amend_source : 7184593019f238b86fd1e261941d8e8286fa4006
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
Andreea Pavel
Emilio Cobos Álvarez
Frederik Braun
Adrian Wielgosik
Jonathan Kingston
Hiroyuki Ikezoe
Tom Schuster
Yaroslav Taben
Gijs Kruitbosch
Olli Pettay
Dorel Luca
Sebastian Hengst
Boris Zbarsky
Masayuki Nakano
Brad Werth
Andrea Marchesini
Edgar Chen
Gurzau Raul
Ben Kelly
Kris Maglione
Cosmin Sabou
Edgar Chen
Jessica Jong
John Dai