Attached is a reduction of the sibling-rules-* test cases, since we skip every ShadowRoot in the loop inside needsLayoutTreeUpdateForNode we don't handle those cases right without the forced layout.

Here's an ancient patch where I fixed it:
https://codereview.chromium.org/1649983003

And here's another where I fixed it a different way by traversing the scopes separately:
https://codereview.chromium.org/2775563002

In the new patch I also had the fix the canParticipateInFlatTree() bug since there's tests for styling <slot>'s these days...

rune@ What do you think?

Deleted: sibling-invalidation-shadow-computed-style.html 658 bytes

sibling-invalidation-shadow-computed-style.html 658 bytes View Download

I think we can actually make slots part of the flat tree now without shipping display:contents entirely because Emilio landed the code for layout tree building for display:contents on real dom elements already (pseudo elements in progress).

Unless I'm ignoring some important details here, I think we can support slots in the flat tree by:

1. Allow slots in Node::canParticipateInFlatTree
2. Possibly remove some other isSlot hardcoded checks
3. Allow display:contents in UASheetMode, or hardcode additional slot check in hasDisplayContentsStyle()

Looking at it, there's quite a bit of code changes necessary in FlatTreeTraversal to include slot elements in the flat tree.

meade, can your team work on this?

> 3. Allow display:contents in UASheetMode, or hardcode additional slot check in hasDisplayContentsStyle()

Just as a heads-up, I believe the first one (allowing display: contents in UASheetMode) may not be as trivial, since it seems to me that the style could leak via inheritance (i.e., you could end up with arbitrarily deep display: contents elements using:

  <slot>
    <div style="display: inherit">
      <!-- ... -->
    </div>
  </slot>

(perhaps not a huge deal though? I recall safari having a hardcoded display: contents implementation for <slot>, don't know if you can inherit from it correctly).

Hi! We won't have time to work on it in Q2 as we've already got a lot on our plates. I can add it to our list of stuff to consider in Q3 though.

An option is landing esprehn@'s change (https://codereview.chromium.org/2775563002) which fixes this issue since all it requires is them hitting Commit :P 

And then we can raise a separate bug for adding slots to FlatTree traversal. 

Would that be preferable to folks? Or would you rather we make the larger change at the same time? 

> And then we can raise a separate bug for adding slots to FlatTree traversal. 

The bug is here:
https://bugs.chromium.org/p/chromium/issues/detail?id=660265


Re: comment #2

> I think we can actually make slots part of the flat tree now without shipping display:contents entirely because Emilio landed the code for layout tree building for display:contents on real dom elements already (pseudo elements in progress).

I think flex layout would be broken if we make slots part of the flat tree without shipping dispaly:contents. I have heard that Polymer is using flex layout with slot.

So here is the problem; when should we make slot part of the flat tree?
I thought that we should do it *after* display:contents is shipped.

If we make slot "display:contents", internally, without shipping "display:contents", I think we can make slots part of the flat tree without shipping "display:contents".

I am afraid that I won't have time to work on  bug 660265  in Q2, but if  bug 660265  is blocking someone and we can start to work on  bug 660265  without waiting for shipping "display: contents", please let me know it.

Updated code link: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/css/CSSComputedStyleDeclaration.cpp?l=346

https://chromium-review.googlesource.com/c/chromium/src/+/950042

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/913382f37e466b5e59a57445e36ff5e8ef9f6f13

commit 913382f37e466b5e59a57445e36ff5e8ef9f6f13
Author: Rune Lillesveen <futhark@chromium.org>
Date: Sat Mar 10 20:20:21 2018

Don't always force recalc for getComputedStyle in shadow trees.

We used to force clean style and layout tree getComputedStyle queries to
elements inside shadow trees. This was because the traversal in
Document::NeedsLayoutTreeUpdateForNode() skipped slots and shadow roots.
Now that slots are included in the flat tree, we can simply add checks
for shadow roots walking up the flat tree.

TEST=fast/dom/shadow/sibling-rules-under-shadow-root.html

Bug:  704421 
Change-Id: Iee46f326ea96c0a4fad3e09b7784cf86d1dcdc85
Reviewed-on: https://chromium-review.googlesource.com/950042
Commit-Queue: Rune Lillesveen <futhark@chromium.org>
Reviewed-by: Hayato Ito <hayato@chromium.org>
Cr-Commit-Position: refs/heads/master@{#542386}
[modify] https://crrev.com/913382f37e466b5e59a57445e36ff5e8ef9f6f13/third_party/WebKit/Source/core/BUILD.gn
[modify] https://crrev.com/913382f37e466b5e59a57445e36ff5e8ef9f6f13/third_party/WebKit/Source/core/css/CSSComputedStyleDeclaration.cpp
[add] https://crrev.com/913382f37e466b5e59a57445e36ff5e8ef9f6f13/third_party/WebKit/Source/core/css/CSSComputedStyleDeclarationTest.cpp
[modify] https://crrev.com/913382f37e466b5e59a57445e36ff5e8ef9f6f13/third_party/WebKit/Source/core/dom/Document.cpp