For doing this, ServoComputedData is split into separate files, so that
files don't need to include ServoBindings.h just for accessing style
structs from ComputedStyles.
MozReview-Commit-ID: DPAd7PUUCl9
--HG--
extra : rebase_source : 7d6f739b7fb58a46e1624ba62e717412057ea9c1
Now that BeginUpdate is useless for the UPDATE_STYLE case, we don't need the
update mechanism at all. Just ensure that ApplicableStylesChanged is called on
the pres shell via the relevant RuleChanged, etc. notifications.
There's a big hidden gotcha here. nsIDocument::BeginUpdate does put a script
blocker on the stack for these updates. However it's not needed, since no script
can run during these notifications (only the stylesheet events we post for
devtools, but those use AsyncEventDispatcher and PostDOMEvents, so they don't
try to run immediately).
nsIDocument::BeginUpdate also does XBL binding attached queue stuff, but we
can't change bindings during these notifications anyway, so it also doesn't
matter.
MozReview-Commit-ID: HJvK6zQfloh
They're empty, and make PresShell::BeginUpdate useless. Now we don't have
document observers that listen for these anymore.
MozReview-Commit-ID: GpDDNonFUFC
UI Events declares that keypress event should be fired only when the keydown
sequence produces some characters. For conforming to UI Events and
compatibility with the other browsers, we should stop dispatching keypress
events for non-printable keys.
For getting regression reports, we should enable this new behavior only
on Nightly.
However, some web apps actually broken with the standardized behavior. For
protecting testers from known broken web apps, this patch introduces a
blacklist to take the traditional behavior under specific domain (and path in
it, optionally). Currently, docs.google.com and mail.google.com are set by
default.
MozReview-Commit-ID: HSrYX8LUB0p
--HG--
extra : rebase_source : a2677d07410af289534db051767543a25c9a957a
Much in the spirit of bug 1442207.
They're not only unneeded, and cheap to get, but also we call them
inconsistently with the light DOM and flattened tree parent (like ContentRemoved
for display: contents), so they're really confusing, and kind of a footgun.
MozReview-Commit-ID: 9u3Kp8Kpp5i
This is mostly code removal, changing GetDisplayContentsStyle(..) checks by an
FFI call to Servo.
The tricky parts are:
* MaybeCreateLazily, which I fixed to avoid setting bits under display: none
stuff. This was a pre-existing problem, which was wallpapered by the
sc->IsInDisplayNoneSubtree() check, which effectively made the whole
assertion useless (see bug 1381017 for the only crashtest that hit this
though).
* ContentRemoved, where we can no longer know for sure whether the element is
actually display: contents if we're removing it as a response to a style
change. See the comment there. That kinda sucks, but that case is relatively
weird, and it's better than adding tons of complexity to handle that.
* GetParentComputedStyle, which also has a comment there. Also, this function
has only one caller now, so we should maybe try to remove it.
The different assertions after DestroyFramesForAndRestyle are changed for a
single assertion in the function itself, and the node bit used as an
optimization to avoid hashtable lookups is taken back.
MozReview-Commit-ID: AZm822QnhF9
The dirty bit fiddling is nontrivial, but it's pretty much what we do for
invalidation and allows to keep this incrementally easily.
The only caller that we cared about for the GetFlattenedTreeParent check in
DestroyFramesForAndRestyle was the old ShadowRoot invalidation functions that
went away.
MozReview-Commit-ID: GmgPPJ6d2qX
