Styles bleeding across shadow DOM
Reported by
messagec...@gmail.com,
Sep 22 2016
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2867.0 Safari/537.36 Example URL: https://amazon.com Steps to reproduce the problem: 1. Create some shadow DOM nodes ( not distributed slots' light DOM, real nodes descendent of the shadow tree ) and observe page styles like line-height, font-size and so on bleed incorrectly into them. 2. Observe the two screen shots of this behaviour. The table td elements text bear different line heights owing to the page styles bleeding incorrectly across the shadow boundary. What is the expected behavior? Style encapsulation. What went wrong? Styles bled across shadow boundary. Does it occur on multiple sites: Yes Is it a problem with a plugin? N/A Did this work before? N/A Does this work in other browsers? N/A Chrome version: 55.0.2867.0 Channel: canary OS Version: 10.0 Flash Version: Shockwave Flash 23.0 r0
,
Sep 26 2016
I wonder why you don't understand it? Let me draw your attention to the images ( are they displaying for you ? ). What are you seeing when you look at the image files? Look at the computed styles. The image clearly shows that page styles are being included in the style computation for shadow descendent nodes, and if a style has not been set in the shadow then the page style is applied. Because I would like to make this bug report clear, if anyone has any further questions please let it be known specifically the part of this issue that is unclear to you now.
,
Sep 26 2016
It'd help our investigation if we can reproduce the issue in our environment. The <table-overlay> tag is probably from an extension you have installed to your browser, not in the amazon.com. I can see line-height is applied to <td> in the screenshot, but I can't see the source code.
,
Sep 26 2016
Okay so you can see the issue. If you want to reproduce in your environment, it helps if you know how to create shadow DOM elements, and can look at them in dev tools, just as reported. I don't know why that step hasn't been possible for you. Did you try? Obviously, you will need to be able to do that to investigate further yourself. It's worth it to try as it's important to know if this reported spec violation is happening, and incorrect to assume it's not or assume some cause, without trying, especially when the report is so clearly opposite the spec. Maybe you commented this issue without really knowing shadow DOM, you can always cc someone who knows shadow DOM and dev tools if you don't know how, so they can try instead. On Sep 26, 2016 14:16, "ko… via monorail" <monorail+v2.1636536379@ chromium.org> wrote:
,
Sep 26 2016
I just need a source to be sure relevant rules are not defined in the shadow tree, but if you can't produce one, we could try our best. In general, if you can provide easier method to reproduce, you have better chance for the issue to be addressed. If you can't for whatever reasons, we'll try our best. Removed "Needs-Feedback" label.
,
Sep 26 2016
,
Sep 26 2016
Okay, and you can also see additional rules that may be defined in the style computation, in the images. Unless you are referencing second order affects like, if style x is defined then style y will be given default value unless defined, I don't currently see how seeing rules not obvious in the image helps. Even in the second order case, it doesn't seem spec correct if such values come from the page. The report is somehow rules from the page are influencing rules in the shadow. Specifically my impression is that Some rules are immune to page styles. Other rules are infected by page styles in the computation, and will take on page values if no rule exists in the shadow. As reported, this is a very easy reproduction. I think I know why you couldn't reproduce it. Because you didn't try yet. So I think your options are open up console on some sites and do the easy reproduction reported here and state your findings, or give to someone who will. I don't see this as my issue, because issues like this, if it reproduces, affect us all, so our efforts are for everyone's benefit. I reported it, now you can reproduce it. There is nothing blocking you from reproducing this except not trying to. And I can't help you with your motivation, that's up to you. In general, in terms of providing code, what if code is proprietary, are you asking to see it then? Luckily in this case because the reproduction is easy providing code instructions needn't apply here. There's everything someone needs to reproduce and test page style cascade into shadow. If you don't find it possible for whatever reasons I'm very very sure pretty much anyone else can. In fact all you really need to say is page styles styles infect Shadow Dom Styles. And someone can test out if that happens. So I think my more lengthy and graphical description has been very generous. And I hope that you or anyone else will be able to reproduce it for everyone's benefit. I get if you don't feel it's possible for you to reproduce and it is also true that there are more people in the project than just you. So if you're having difficulty reproducing it don't necessarily take it as an indication that it can't be reproduced or that the instructions are insufficient, only that someone else is more capable to reproduce it, which isn't a problem for the project because there are so many people and everyone has different skill. For me I just felt scared about giving out proprietary code and scared the issue would be unnecessarily delayed because someone couldn't reproduce it, and felt scared that delay would then be my fault. So I wanted to make it clear that it's not my responsibility to bear, because the issue is easy to reproduce. I hope this is clear now, I appreciate you giving your time on this.
,
Sep 30 2016
WONTFIX. See https://drafts.csswg.org/css-scoping/#flattening to know how style inheritance should work for Shadow DOM. It *inherits*. |
||||
►
Sign in to add a comment |
||||
Comment 1 by kojii@chromium.org
, Sep 26 2016Components: -Blink Blink>WebComponents
Labels: -Via-Wizard -Arch-x86_64 Needs-Feedback