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
After bug 1303605 we can assert this, since we make sure all children have the
same flattened tree parent, and thus insertion point.
MozReview-Commit-ID: 7AHuGGw2uJI
This method is not a virtual call, and also looks nicer.
This patch was mostly generated by a Python script, but I manually
cleaned up the code in a few places where statements didn't need to be
split across multiple lines any more.
MozReview-Commit-ID: 8JExxqSRc59
And make nsIFrame its only caller, modulo a safety assertion.
The safety assertion will be removed at the same time as the pres context
member, since the only purpose of it is to ensure we don't keep a pres context
reference for too long.
MozReview-Commit-ID: CD5zOHVO9ub
And make nsIFrame its only caller, modulo a safety assertion.
The safety assertion will be removed at the same time as the pres context
member, since the only purpose of it is to ensure we don't keep a pres context
reference for too long.
MozReview-Commit-ID: CD5zOHVO9ub
This patch basically does:
* Add descriptor setters and generation count to CounterStyleRule in
Servo. (This code is mostly based on the old code inside
nsCSSCounterStyleRule for handling mutation.)
* Use RawServoCounterStyleRule in CounterStyleManager.
* Add ServoCounterStyleRule and remove nsCSSCounterStyleRule.
Test change:
* "fixed" was parsed as and thus serialized to "fixed 1", but Servo
doesn't do so. It preserves whether the number presents. Either way
is probably fine.
MozReview-Commit-ID: EtKTeu32isi
This reworks bug 1440561 so that we only precompute loads that belong to our
user font set, avoiding messing up with fonts in the cache that belong to other
pages.
The loadability of a font is precomputed in PreTraverse in the same way as we
did, but only for the fonts that we may end up loading. This is stored in
FontFaceSet now.
Also, the principal shenanigans that this code did are reworked to be explicit
about when the document principal changes in ResetToURI, instead of having a
member around and a mutable variable. This makes the code easier to follow.
MozReview-Commit-ID: 9ofTbaLDUF7
Currently we can only have one type of WebRenderUserData on an Item. We already
have a hash table of WebRenderUserData so it's not hard to include type in the
hash to support one per type.
MozReview-Commit-ID: geJ0BeWv8b
More improvements to come. In particular, this still iterates through Shadow DOM
in each_xbl_cascade_data, but that should be changed later. That allows to
cleanup a bunch of stuff and finally fix Shadow DOM cascade order.
We still rely on the binding parent to be setup properly in the shadow tree, but
that requirement can go away later (we can walk the containing shadow chain
instead).
This mostly focuses on removing the XBL binding from the Shadow host.
It'd be nice to do EnumerateShadowRoots faster. I think that should also be a
followup, if needed.
MozReview-Commit-ID: Jf2iGvLC5de
Also, make them not rebuild the CascadeData synchronously, via the
FlushSkinSheets call, since that's broken. That fixes bug 1413119.
This is a little step in getting rid of XBL usage for Shadow DOM.
MozReview-Commit-ID: HJ7FeUZlRTW
This removes a hack, but adds slightly more complex code in inspector-only code.
I'm not excited about this code, but this fixes ServoStyleRuleMap for XBL.
MozReview-Commit-ID: 6h0dCsiIWKU
The keyframe stuff runs from animation building, which needs clean styles
already.
Same for counter styles, they run from a well-defined point in time where rules
should be up-to-date already.
The canvas stuff needs no stylist access mostly, since it's only used to compute
a couple font-related things.
MozReview-Commit-ID: 3Vh1wzeaYl3
The reason why bug 1355721 regressed this is because in non-e10s we definitely
flush before parsing the standards quirks-mode. And bug 1355721 introduced an
unconditional UpdateStylistIfNeeded, unless the counter style / font
equivalents.
That means that the stylist wouldn't remain on its initial state after the first
flush, which itself means that when the compat mode changed, the UA and user
rules were already on the stylist with the quirks mode keys. That makes
class-names be keyed in ascii lowercase.
After that no user style changed, so no rebuild happens for the cascade data in
the user origin, so we keep looking at the wrong keys indefinitely.
MozReview-Commit-ID: 25dD2bca3tN
This will make it easier to handle it properly for Shadow DOM, though this patch
doesn't do that.
This also makes some method inline and infallible for convenience, since nobody
checks the errors anyway.
MozReview-Commit-ID: Hq3erAUs5tf
This avoids resetting the computed values all the time, and paves the way to
avoid using a StyleSet on XBL bindings / Shadow DOM, which we should really
really do because it's super overkill.
There are some XBL bits that are kind of hacky, in particular the mStylistDirty,
but they'll go away soon, since I want to redo how we store styles in XBL.
The alternative, which was returning an array of indices or something was even
more hacky I think.
MozReview-Commit-ID: 6tEl5gebXVF
This will allow us to invoke it from nsAttrValueInlines.h, which can't
include ServoStyleSet.h due to circular dependencies.
MozReview-Commit-ID: BgC7ExyWRn7
The selectorText test happens to pass right now because well, we don't implement
the setter yet[1], but would fail if we implemented an specific invalidation in
the way I'd have done it yesterday.
[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=37468
MozReview-Commit-ID: DrMTgLzQcnk
