Increment style version for all style changes.

Increment style version for all style changes.

markAncestorsWithChildNeedsStyleRecalc incremented styleVersion on
Document, while markAncestorsWithChildNeedsStyleInvalidation did not.
That made us detect style changes differently depending on the type of
selectors which would be affected by a change - if we would schedule an
invalidation set, or set SubtreeStyleChange directly.

Instead increment style version on scheduleLayoutTreeUpdate.

R=ericwilligers@chromium.org,esprehn@chromium.org

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=202419

[rune, 2015-09-14 23:07:08]

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

[commit-bot: I haz the power, 2015-09-14 23:07:54]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1333193004/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1333193004/1

[rune, 2015-09-14 23:09:48]

Change necessary to avoid a test regression in
https://codereview.chromium.org/1317533002/

[Eric Willigers, 2015-09-14 23:49:27]

lgtm

Lots of thanks.

[esprehn, 2015-09-15 00:00:55]

Hmm, adding/removing sheets will also change style and schedule recalcs but
doesn't increment this. Why is this correct in the markAncestor functions?

[commit-bot: I haz the power, 2015-09-15 00:37:56]

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

[commit-bot: I haz the power, 2015-09-15 00:37:56]

Dry run: This issue passed the CQ dry run.

[rune, 2015-09-15 14:52:17]

On 2015/09/15 00:00:55, esprehn wrote:
> Hmm, adding/removing sheets will also change style and schedule recalcs but
> doesn't increment this. Why is this correct in the markAncestor functions?

You mean dirty tree-scopes and m_documentScopeDirty?

So, currently we do synchronous updateActiveStyleSheets() immediately after
those, which will cause setNeedsStyleRecalc and corresponding markAncestor if
necessary.

Perhaps style version increment could be more centralized, like for
Document::scheduleLayoutTreeUpdate()?

[rune, 2015-09-16 09:18:39]

On 2015/09/15 14:52:17, rune wrote:
> On 2015/09/15 00:00:55, esprehn wrote:
> > Hmm, adding/removing sheets will also change style and schedule recalcs but
> > doesn't increment this. Why is this correct in the markAncestor functions?
> 
> You mean dirty tree-scopes and m_documentScopeDirty?
> 
> So, currently we do synchronous updateActiveStyleSheets() immediately after
> those, which will cause setNeedsStyleRecalc and corresponding markAncestor if
> necessary.
> 
> Perhaps style version increment could be more centralized, like for
> Document::scheduleLayoutTreeUpdate()?

esprehn: any comments?

[esprehn, 2015-09-16 09:26:12]

On 2015/09/16 at 09:18:39, rune wrote:
> On 2015/09/15 14:52:17, rune wrote:
> > On 2015/09/15 00:00:55, esprehn wrote:
> > > ...
> > 
> > Perhaps style version increment could be more centralized, like for
> > Document::scheduleLayoutTreeUpdate()?
> 
> esprehn: any comments?

Yeah that seems right to me.

[rune, 2015-09-16 10:54:27]

On 2015/09/16 09:26:12, esprehn wrote:
> On 2015/09/16 at 09:18:39, rune wrote:
> > On 2015/09/15 14:52:17, rune wrote:
> > > On 2015/09/15 00:00:55, esprehn wrote:
> > > > ...
> > > 
> > > Perhaps style version increment could be more centralized, like for
> > > Document::scheduleLayoutTreeUpdate()?
> > 
> > esprehn: any comments?
> 
> Yeah that seems right to me.

Done.

[rune, 2015-09-16 22:55:24]

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

[commit-bot: I haz the power, 2015-09-16 22:55:53]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1333193004/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1333193004/20001

[rune, 2015-09-16 22:58:09]

On 2015/09/16 10:54:27, rune wrote:
> On 2015/09/16 09:26:12, esprehn wrote:
> > On 2015/09/16 at 09:18:39, rune wrote:
> > > On 2015/09/15 14:52:17, rune wrote:
> > > > On 2015/09/15 00:00:55, esprehn wrote:
> > > > > ...
> > > > 
> > > > Perhaps style version increment could be more centralized, like for
> > > > Document::scheduleLayoutTreeUpdate()?
> > > 
> > > esprehn: any comments?
> > 
> > Yeah that seems right to me.
> 
> Done.

@esprehn: ptal?

[esprehn, 2015-09-16 23:00:03]

lgtm

[commit-bot: I haz the power, 2015-09-17 01:17:33]

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

[commit-bot: I haz the power, 2015-09-17 01:17:34]

Dry run: This issue passed the CQ dry run.

[Eric Willigers, 2015-09-17 02:51:24]

The CQ bit was checked by ericwilligers@chromium.org

[Eric Willigers, 2015-09-17 02:51:24]

The patchset sent to the CQ was uploaded after l-g-t-m from
ericwilligers@chromium.org
Link to the patchset: https://codereview.chromium.org/1333193004/#ps20001
(title: "Increment style version in scheduleLayoutTreeUpdate")

[commit-bot: I haz the power, 2015-09-17 02:51:55]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1333193004/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1333193004/20001

[commit-bot: I haz the power, 2015-09-17 02:57:34]

Committed patchset #2 (id:20001) as
https://src.chromium.org/viewvc/blink?view=rev&revision=202419