New issue
Advanced search Search tips

Issue 649263 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Sep 2016
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Styles bleeding across shadow DOM

Reported by messagec...@gmail.com, Sep 22 2016

Issue description

UserAgent: 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
 
proof-of-styles-bleeding-into-shadow-dom.png
461 KB View Download
proof-of-styles-bleeding-into-shadow-dom-compare.png
438 KB View Download

Comment 1 by kojii@chromium.org, Sep 26 2016

Cc: kojii@chromium.org
Components: -Blink Blink>WebComponents
Labels: -Via-Wizard -Arch-x86_64 Needs-Feedback
I'm sorry but I'm not confident if I understand the issue correctly. Do you have sample files that describe the issue better?
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.

Comment 3 by kojii@chromium.org, 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.
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:

Comment 5 by kojii@chromium.org, Sep 26 2016

Labels: -Needs-Feedback
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.

Comment 6 by kojii@chromium.org, Sep 26 2016

Cc: -kojii@chromium.org
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.

Comment 8 by hayato@chromium.org, Sep 30 2016

Status: WontFix (was: Unconfirmed)
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