Prepare to use invalidation set for adding/removing RuleSets.

Prepare to use invalidation set for adding/removing RuleSets.

Currently, we sometimes use StyleSheetInvalidationAnalysis to be smart
about recalculating affected element when adding/removing a stylesheet.

The plan is to start using the StyleInvalidator to trigger style
recalculations When adding/removing stylesheets. We will then use the
invalidation sets from the stylesheet RuleSet and schedule them on
elements in the stylesheet's document or shadow tree.

We fall back to a full recalc for the document / shadow tree for if we
find selectors which don't have simple selectors for which we have an
invalidation set we can use. This is similar to what we do with the
universalSiblingInvalidationSet for DOM mutations.

This first implementation supports id, class, attribute, and type
selectors in the rightmost compound[1]. We could later support to use
invalidation sets for universal pseudo class rules like ":hover".

The invalidations are to be scheduled for elements in the same
TreeScope as the stylesheet, including the host element.

Rules which are boundary crossing have their features collected in
ScopedStyleResolver::addTreeBoundaryCrossingRules() and not in their
respective stylesheet's RuleSet. We fall back to full style recalc
for rules containing ::content, ::shadow, and /deep/. ::slotted rules
are currently also collected on the ScopedStyleResolver, but in order
to avoid full recalcs, we do LocalStyleChange on slot-distributed
elements for RuleSet invalidations when there are ::slotted rules in
the RuleSet.

As mentioned earlier we will schedule invalidations on the host element
as well, which means we will schedule the invalidation set for ".a" for
":host(.a)". :host-context() do also support RuleSet invalidation as
long as there are features in addition to the ones inside the
:host-context() pseudo.

As for sibling invalidations on DOM mutations, negated selectors like
":not(.a)" are considered universal.

This CL is split out of [2]. The next step is to land the invalidation
code in StyleEngine from the same CL.

[1] Even though we don't have invalidation sets for tag names, we can
check the presence of rules in the tag name hash map for the RuleSet.
This means "body *" will cause a full recalc, but "body" won't. Also
note that "div.enabled" will cause every div element to be invalidated
because the rule would end up in the class rule hashmap.

[2] https://codereview.chromium.org/1913833002/

R=ericwilligers@chromium.org
BUG=567021
Committed: https://crrev.com/9831d308f547fba256521a119b21b6f87db43e4e
Cr-Commit-Position: refs/heads/master@{#419704}

[rune, 2016-09-09 13:54:12]

The CQ bit was checked by rune@opera.com to run a CQ dry run

[commit-bot: I haz the power, 2016-09-09 13:54:26]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[rune, 2016-09-09 13:54:29]

ptal

[commit-bot: I haz the power, 2016-09-09 15:27:34]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-09 15:27:35]

Dry run: This issue passed the CQ dry run.

[rune, 2016-09-14 07:47:31]

https://codereview.chromium.org/2326033002/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/css/RuleFeatureSetTest.cpp (right):

https://codereview.chromium.org/2326033002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/css/RuleFeatureSetTest.cpp:1063:
expectFullRecalcForRuleSetInvalidation(false);
This is not going to work since we're collecting features for tree boundary
crossing rules for the m_treeBoundaryCrossingRuleSet, not the stylesheet
ruleset.

[rune, 2016-09-16 11:08:29]

Description was changed from

==========
Prepare to use invalidation set for adding/removing RuleSets.

Currently, we sometimes use StyleSheetInvalidationAnalysis to be smart
about recalculating affected element when adding/removing a stylesheet.

The plan is to start using the StyleInvalidator to trigger style
recalculations When adding/removing stylesheets. We will then use the
invalidation sets from the stylesheet RuleSet and schedule them on
elements in the stylesheet's document or shadow tree.

We fall back to a full recalc for the document / shadow tree for if we
find selectors which don't have simple selectors for which we have an
invalidation set we can use. This is similar to what we do with the
universalSiblingInvalidationSet for DOM mutations.

This first implementation supports id, class, attribute, and type
selectors in the rightmost compound[1]. We could later support to use
invalidation sets for universal pseudo class rules like ":hover".

The invalidations are to be scheduled for elements in the same
TreeScope as the stylesheet, including the host element. That means we
ignore that we have already found features as we encounter boundary
crossing combinators. E.g.:

  * ::content .c
  .a ::content .b

The first rule will cause a subtree recalc in the stylesheet's
TreeScope because the element with class "c" will be in a different
TreeScope. The second rule won't, because we can schedule the
invalidation set for ".a" in the sheet's TreeScope which will cause an
invalidation of ".b" in a different TreeScope in StyleInvalidator.

As mentioned earlier we will schedule invalidations on the host element
as well, which means we will schedule the invalidation set for ".a" for
":host(.a)".

As for sibling invalidations on DOM mutations, negated selectors like
":not(.a)" are considered universal.

This CL is split out of [2]. The next step is to land the invalidation
code in StyleEngine from the same CL.

[1] Even though we don't have invalidation sets for tag names, we can
check the presence of rules in the tag name hash map for the RuleSet.
This means "body *" will cause a full recalc, but "body" won't. Also
note that "div.enabled" will cause every div element to be invalidated
because the rule would end up in the class rule hashmap.

[2] https://codereview.chromium.org/1913833002/

R=ericwilligers@chromium.org
BUG=567021
==========

to

==========
Prepare to use invalidation set for adding/removing RuleSets.

Currently, we sometimes use StyleSheetInvalidationAnalysis to be smart
about recalculating affected element when adding/removing a stylesheet.

The plan is to start using the StyleInvalidator to trigger style
recalculations When adding/removing stylesheets. We will then use the
invalidation sets from the stylesheet RuleSet and schedule them on
elements in the stylesheet's document or shadow tree.

We fall back to a full recalc for the document / shadow tree for if we
find selectors which don't have simple selectors for which we have an
invalidation set we can use. This is similar to what we do with the
universalSiblingInvalidationSet for DOM mutations.

This first implementation supports id, class, attribute, and type
selectors in the rightmost compound[1]. We could later support to use
invalidation sets for universal pseudo class rules like ":hover".

The invalidations are to be scheduled for elements in the same
TreeScope as the stylesheet, including the host element.

Rules which are boundary crossing have their features collected in
ScopedStyleResolver::addTreeBoundaryCrossingRules() and not in their
respective stylesheet's RuleSet. We fall back to full style recalc
for rules containing ::content, ::shadow, and /deep/. ::slotted rules
are currently also collected on the ScopedStyleResolver, but in order
to avoid full recalcs, we do LocalStyleChange on slot-distributed
elements for RuleSet invalidations when there are ::slotted rules in
the RuleSet.

As mentioned earlier we will schedule invalidations on the host element
as well, which means we will schedule the invalidation set for ".a" for
":host(.a)". :host-context() do also support RuleSet invalidation as
long as there are features in addition to the ones inside the
:host-context() pseudo.

As for sibling invalidations on DOM mutations, negated selectors like
":not(.a)" are considered universal.

This CL is split out of [2]. The next step is to land the invalidation
code in StyleEngine from the same CL.

[1] Even though we don't have invalidation sets for tag names, we can
check the presence of rules in the tag name hash map for the RuleSet.
This means "body *" will cause a full recalc, but "body" won't. Also
note that "div.enabled" will cause every div element to be invalidated
because the rule would end up in the class rule hashmap.

[2] https://codereview.chromium.org/1913833002/

R=ericwilligers@chromium.org
BUG=567021
==========

[rune, 2016-09-16 11:08:40]

The CQ bit was checked by rune@opera.com to run a CQ dry run

[commit-bot: I haz the power, 2016-09-16 11:08:47]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-16 11:11:02]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-16 11:11:03]

Dry run: Try jobs failed on following builders:
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[rune, 2016-09-16 19:03:13]

The CQ bit was checked by rune@opera.com to run a CQ dry run

[commit-bot: I haz the power, 2016-09-16 19:03:50]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-16 22:24:42]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-16 22:24:43]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[rune, 2016-09-18 20:21:53]

Ready for review.

[Eric Willigers, 2016-09-20 01:41:00]

lgtm

[rune, 2016-09-20 06:42:00]

The CQ bit was checked by rune@opera.com

[commit-bot: I haz the power, 2016-09-20 06:42:15]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-20 09:21:18]

Description was changed from

==========
Prepare to use invalidation set for adding/removing RuleSets.

Currently, we sometimes use StyleSheetInvalidationAnalysis to be smart
about recalculating affected element when adding/removing a stylesheet.

The plan is to start using the StyleInvalidator to trigger style
recalculations When adding/removing stylesheets. We will then use the
invalidation sets from the stylesheet RuleSet and schedule them on
elements in the stylesheet's document or shadow tree.

We fall back to a full recalc for the document / shadow tree for if we
find selectors which don't have simple selectors for which we have an
invalidation set we can use. This is similar to what we do with the
universalSiblingInvalidationSet for DOM mutations.

This first implementation supports id, class, attribute, and type
selectors in the rightmost compound[1]. We could later support to use
invalidation sets for universal pseudo class rules like ":hover".

The invalidations are to be scheduled for elements in the same
TreeScope as the stylesheet, including the host element.

Rules which are boundary crossing have their features collected in
ScopedStyleResolver::addTreeBoundaryCrossingRules() and not in their
respective stylesheet's RuleSet. We fall back to full style recalc
for rules containing ::content, ::shadow, and /deep/. ::slotted rules
are currently also collected on the ScopedStyleResolver, but in order
to avoid full recalcs, we do LocalStyleChange on slot-distributed
elements for RuleSet invalidations when there are ::slotted rules in
the RuleSet.

As mentioned earlier we will schedule invalidations on the host element
as well, which means we will schedule the invalidation set for ".a" for
":host(.a)". :host-context() do also support RuleSet invalidation as
long as there are features in addition to the ones inside the
:host-context() pseudo.

As for sibling invalidations on DOM mutations, negated selectors like
":not(.a)" are considered universal.

This CL is split out of [2]. The next step is to land the invalidation
code in StyleEngine from the same CL.

[1] Even though we don't have invalidation sets for tag names, we can
check the presence of rules in the tag name hash map for the RuleSet.
This means "body *" will cause a full recalc, but "body" won't. Also
note that "div.enabled" will cause every div element to be invalidated
because the rule would end up in the class rule hashmap.

[2] https://codereview.chromium.org/1913833002/

R=ericwilligers@chromium.org
BUG=567021
==========

to

==========
Prepare to use invalidation set for adding/removing RuleSets.

Currently, we sometimes use StyleSheetInvalidationAnalysis to be smart
about recalculating affected element when adding/removing a stylesheet.

The plan is to start using the StyleInvalidator to trigger style
recalculations When adding/removing stylesheets. We will then use the
invalidation sets from the stylesheet RuleSet and schedule them on
elements in the stylesheet's document or shadow tree.

We fall back to a full recalc for the document / shadow tree for if we
find selectors which don't have simple selectors for which we have an
invalidation set we can use. This is similar to what we do with the
universalSiblingInvalidationSet for DOM mutations.

This first implementation supports id, class, attribute, and type
selectors in the rightmost compound[1]. We could later support to use
invalidation sets for universal pseudo class rules like ":hover".

The invalidations are to be scheduled for elements in the same
TreeScope as the stylesheet, including the host element.

Rules which are boundary crossing have their features collected in
ScopedStyleResolver::addTreeBoundaryCrossingRules() and not in their
respective stylesheet's RuleSet. We fall back to full style recalc
for rules containing ::content, ::shadow, and /deep/. ::slotted rules
are currently also collected on the ScopedStyleResolver, but in order
to avoid full recalcs, we do LocalStyleChange on slot-distributed
elements for RuleSet invalidations when there are ::slotted rules in
the RuleSet.

As mentioned earlier we will schedule invalidations on the host element
as well, which means we will schedule the invalidation set for ".a" for
":host(.a)". :host-context() do also support RuleSet invalidation as
long as there are features in addition to the ones inside the
:host-context() pseudo.

As for sibling invalidations on DOM mutations, negated selectors like
":not(.a)" are considered universal.

This CL is split out of [2]. The next step is to land the invalidation
code in StyleEngine from the same CL.

[1] Even though we don't have invalidation sets for tag names, we can
check the presence of rules in the tag name hash map for the RuleSet.
This means "body *" will cause a full recalc, but "body" won't. Also
note that "div.enabled" will cause every div element to be invalidated
because the rule would end up in the class rule hashmap.

[2] https://codereview.chromium.org/1913833002/

R=ericwilligers@chromium.org
BUG=567021
==========

[commit-bot: I haz the power, 2016-09-20 09:21:19]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2016-09-20 09:23:23]

Description was changed from

==========
Prepare to use invalidation set for adding/removing RuleSets.

Currently, we sometimes use StyleSheetInvalidationAnalysis to be smart
about recalculating affected element when adding/removing a stylesheet.

The plan is to start using the StyleInvalidator to trigger style
recalculations When adding/removing stylesheets. We will then use the
invalidation sets from the stylesheet RuleSet and schedule them on
elements in the stylesheet's document or shadow tree.

We fall back to a full recalc for the document / shadow tree for if we
find selectors which don't have simple selectors for which we have an
invalidation set we can use. This is similar to what we do with the
universalSiblingInvalidationSet for DOM mutations.

This first implementation supports id, class, attribute, and type
selectors in the rightmost compound[1]. We could later support to use
invalidation sets for universal pseudo class rules like ":hover".

The invalidations are to be scheduled for elements in the same
TreeScope as the stylesheet, including the host element.

Rules which are boundary crossing have their features collected in
ScopedStyleResolver::addTreeBoundaryCrossingRules() and not in their
respective stylesheet's RuleSet. We fall back to full style recalc
for rules containing ::content, ::shadow, and /deep/. ::slotted rules
are currently also collected on the ScopedStyleResolver, but in order
to avoid full recalcs, we do LocalStyleChange on slot-distributed
elements for RuleSet invalidations when there are ::slotted rules in
the RuleSet.

As mentioned earlier we will schedule invalidations on the host element
as well, which means we will schedule the invalidation set for ".a" for
":host(.a)". :host-context() do also support RuleSet invalidation as
long as there are features in addition to the ones inside the
:host-context() pseudo.

As for sibling invalidations on DOM mutations, negated selectors like
":not(.a)" are considered universal.

This CL is split out of [2]. The next step is to land the invalidation
code in StyleEngine from the same CL.

[1] Even though we don't have invalidation sets for tag names, we can
check the presence of rules in the tag name hash map for the RuleSet.
This means "body *" will cause a full recalc, but "body" won't. Also
note that "div.enabled" will cause every div element to be invalidated
because the rule would end up in the class rule hashmap.

[2] https://codereview.chromium.org/1913833002/

R=ericwilligers@chromium.org
BUG=567021
==========

to

==========
Prepare to use invalidation set for adding/removing RuleSets.

Currently, we sometimes use StyleSheetInvalidationAnalysis to be smart
about recalculating affected element when adding/removing a stylesheet.

The plan is to start using the StyleInvalidator to trigger style
recalculations When adding/removing stylesheets. We will then use the
invalidation sets from the stylesheet RuleSet and schedule them on
elements in the stylesheet's document or shadow tree.

We fall back to a full recalc for the document / shadow tree for if we
find selectors which don't have simple selectors for which we have an
invalidation set we can use. This is similar to what we do with the
universalSiblingInvalidationSet for DOM mutations.

This first implementation supports id, class, attribute, and type
selectors in the rightmost compound[1]. We could later support to use
invalidation sets for universal pseudo class rules like ":hover".

The invalidations are to be scheduled for elements in the same
TreeScope as the stylesheet, including the host element.

Rules which are boundary crossing have their features collected in
ScopedStyleResolver::addTreeBoundaryCrossingRules() and not in their
respective stylesheet's RuleSet. We fall back to full style recalc
for rules containing ::content, ::shadow, and /deep/. ::slotted rules
are currently also collected on the ScopedStyleResolver, but in order
to avoid full recalcs, we do LocalStyleChange on slot-distributed
elements for RuleSet invalidations when there are ::slotted rules in
the RuleSet.

As mentioned earlier we will schedule invalidations on the host element
as well, which means we will schedule the invalidation set for ".a" for
":host(.a)". :host-context() do also support RuleSet invalidation as
long as there are features in addition to the ones inside the
:host-context() pseudo.

As for sibling invalidations on DOM mutations, negated selectors like
":not(.a)" are considered universal.

This CL is split out of [2]. The next step is to land the invalidation
code in StyleEngine from the same CL.

[1] Even though we don't have invalidation sets for tag names, we can
check the presence of rules in the tag name hash map for the RuleSet.
This means "body *" will cause a full recalc, but "body" won't. Also
note that "div.enabled" will cause every div element to be invalidated
because the rule would end up in the class rule hashmap.

[2] https://codereview.chromium.org/1913833002/

R=ericwilligers@chromium.org
BUG=567021

Committed: https://crrev.com/9831d308f547fba256521a119b21b6f87db43e4e
Cr-Commit-Position: refs/heads/master@{#419704}
==========

[commit-bot: I haz the power, 2016-09-20 09:23:26]

Patchset 3 (id:??) landed as
https://crrev.com/9831d308f547fba256521a119b21b6f87db43e4e
Cr-Commit-Position: refs/heads/master@{#419704}