Thanks for filing this bug.

Here's something I can't work out. I've made this variant of your repro which just uses shadow DOM:

https://embed.plnkr.co/eE0MYnP22zGPgascHwvy/

The key difference is this works--the host element's scroll height is non-zero all along.

OK, I think I have worked out what's happening here. This looks like a shadow DOM issue, here's a repro:

https://embed.plnkr.co/DG32MUv1JC4vAuVlJr1t/

What's happening here is if you load a stylesheet with a <link rel> in shadow DOM in M54, styles apply to the shadow DOM but :host rules do not apply.

Because the 'link rel' host has height: auto from the UA stylesheet, scrollHeight is 0.

If you populate it with inline styles, the :host rules work and the host gets display: block and scrollHeight starts returning a number.

Hi dominicc. Thanks for your investigation. 
Just want to add or clarify that adding even an empty style tag to the shadow dom fixes the problem.
See updated example (customComponentWorking.js look for //HACK comment):
https://embed.plnkr.co/xFISoDytfNit2Rb9aOEI/

That's interesting; there's an element of dynamism to it. Let me flip this back to untriaged so hayato can retriage it. Every indication is that this is a shadow DOM issue.

Removing the Blink>CSS component for now so that we have one owner. Feel free to reassign if this turns out not to be related to shadow DOM.

Component != Owner, and I don't see how :host is not related to shadow DOM,
but CSS is your label so apply it as you see fit :)

With https://embed.plnkr.co/xFISoDytfNit2Rb9aOEI/ , none of the cases are working for me on master content_shell. I get white background and 0, 0 on both.

https://codereview.chromium.org/2472613004/

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

commit 4215d863dcedd407dc69d31addc731a7bc80a7e8
Author: rune <rune@opera.com>
Date: Fri Nov 04 07:25:27 2016

Remove ShadowRoot::numberOfStyles().

This probably used to be an optimization which made sense when we had
<style scoped> implemented. Now, it should be equally cheap to just
check the ScopedStyleResolver member. The ScopedStyleResolver is null
when there are no active stylesheets in the tree-scope.

This also caused  issue 659596  because we only registered style elements
and not link elements, which lead the code to believe there were no
rules to match from the scope when there were only link stylesheets
present.

R=kochi@chromium.org,hayato@chromium.org
BUG= 659596 

Review-Url: https://codereview.chromium.org/2472613004
Cr-Commit-Position: refs/heads/master@{#429824}

[add] https://crrev.com/4215d863dcedd407dc69d31addc731a7bc80a7e8/third_party/WebKit/LayoutTests/shadow-dom/host-link-style.html
[modify] https://crrev.com/4215d863dcedd407dc69d31addc731a7bc80a7e8/third_party/WebKit/Source/core/css/resolver/StyleResolver.cpp
[modify] https://crrev.com/4215d863dcedd407dc69d31addc731a7bc80a7e8/third_party/WebKit/Source/core/dom/StyleElement.cpp
[modify] https://crrev.com/4215d863dcedd407dc69d31addc731a7bc80a7e8/third_party/WebKit/Source/core/dom/StyleElement.h
[modify] https://crrev.com/4215d863dcedd407dc69d31addc731a7bc80a7e8/third_party/WebKit/Source/core/dom/shadow/ShadowRoot.cpp
[modify] https://crrev.com/4215d863dcedd407dc69d31addc731a7bc80a7e8/third_party/WebKit/Source/core/dom/shadow/ShadowRoot.h
[modify] https://crrev.com/4215d863dcedd407dc69d31addc731a7bc80a7e8/third_party/WebKit/Source/core/html/HTMLStyleElement.cpp
[modify] https://crrev.com/4215d863dcedd407dc69d31addc731a7bc80a7e8/third_party/WebKit/Source/core/svg/SVGStyleElement.cpp

What version of Chrome will have this fix?

It will be in 56 if not merged to 55. hayato@, should I request a merge to 55?

Yeah, I think it is okay to merge this to 55. Thank you for the quick fix.

Your change meets the bar and is auto-approved for M55 (branch: 2883)

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

commit 0d29461d46ced2af6740e0a9255a35f0bb8e48d2
Author: Rune Lillesveen <rune@opera.com>
Date: Tue Nov 08 08:47:48 2016

Remove ShadowRoot::numberOfStyles().

This probably used to be an optimization which made sense when we had
<style scoped> implemented. Now, it should be equally cheap to just
check the ScopedStyleResolver member. The ScopedStyleResolver is null
when there are no active stylesheets in the tree-scope.

This also caused  issue 659596  because we only registered style elements
and not link elements, which lead the code to believe there were no
rules to match from the scope when there were only link stylesheets
present.

R=kochi@chromium.org,hayato@chromium.org
BUG= 659596 

Review-Url: https://codereview.chromium.org/2472613004
Cr-Commit-Position: refs/heads/master@{#429824}
(cherry picked from commit 4215d863dcedd407dc69d31addc731a7bc80a7e8)

Review URL: https://codereview.chromium.org/2488633002 .

Cr-Commit-Position: refs/branch-heads/2883@{#491}
Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768}

[add] https://crrev.com/0d29461d46ced2af6740e0a9255a35f0bb8e48d2/third_party/WebKit/LayoutTests/shadow-dom/host-link-style.html
[modify] https://crrev.com/0d29461d46ced2af6740e0a9255a35f0bb8e48d2/third_party/WebKit/Source/core/css/resolver/StyleResolver.cpp
[modify] https://crrev.com/0d29461d46ced2af6740e0a9255a35f0bb8e48d2/third_party/WebKit/Source/core/dom/StyleElement.cpp
[modify] https://crrev.com/0d29461d46ced2af6740e0a9255a35f0bb8e48d2/third_party/WebKit/Source/core/dom/StyleElement.h
[modify] https://crrev.com/0d29461d46ced2af6740e0a9255a35f0bb8e48d2/third_party/WebKit/Source/core/dom/shadow/ShadowRoot.cpp
[modify] https://crrev.com/0d29461d46ced2af6740e0a9255a35f0bb8e48d2/third_party/WebKit/Source/core/dom/shadow/ShadowRoot.h
[modify] https://crrev.com/0d29461d46ced2af6740e0a9255a35f0bb8e48d2/third_party/WebKit/Source/core/html/HTMLStyleElement.cpp
[modify] https://crrev.com/0d29461d46ced2af6740e0a9255a35f0bb8e48d2/third_party/WebKit/Source/core/svg/SVGStyleElement.cpp

Thank you all guys!

Tested the issue on windows-7, Mac-10.11.6 and Linux Ubuntu-14.04 using chrome Beta-55.0.2883.44 with the below steps
1.opened chrome
2.Navigated to the urls  https://embed.plnkr.co/xFISoDytfNit2Rb9aOEI/
                         https://plnkr.co/edit/xFISoDytfNit2Rb9aOEI?p=preview and reload the page
Observed the output as per the screen-cast(55.0.2883.44.mp4).
Please find the attached screen-cast and please confirm is it the expected behavior?
Note: Please find the reported version screen-cast(54.0.2840.71)


Thanks..

Deleted: 55.0.2883.44.mp4 878 KB

	55.0.2883.44.mp4 878 KB View Download

Deleted: 54.0.2840.71.mp4 683 KB

	54.0.2840.71.mp4 683 KB View Download

The unstyled content on reload does not happen for me on ToT content_shell.

As stated in Comment#25 and I checked this on Chrome version 55.0.2883.44, I still see similar behavior as shown in comment#25 video.

hence relabeling the status back to assigned.

Have you tested a 56 build? If this works in 56 and for some reason not in 55, we could just revert from 55.

Yes I have checked this on M56 and it works fine, But consistently reproducible on M55(55.0.2883.44).

Building from M55 branch or tags gives me a completely white browser. I'm leaning towards reverting from M55.

I built 55.0.2883.47 which was apparently broken. I got 55.0.2883.44 to build and run. Looking ...

We need to cherry-pick the fix for  issue 661914  as well.

Setting back to fixed since blocking issue has been merged.