Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add "disable shadow" flag check to Element.attachShadow() #760

Merged
merged 1 commit into from
May 16, 2019

Conversation

tkent-google
Copy link
Collaborator

@tkent-google tkent-google commented May 13, 2019

This fixes a part of WICG/webcomponents#758

This and whatwg/html#4324 should be merged at the same time.

Test: web-platform-tests/wpt#16795


Preview | Diff

dom.bs Outdated
<a for=Element>local name</a>, and null as <a><code>is</code> value</a>.</p></li>

<li><p>If <var>definition</var> is not null and <var>definition</var>'s
<a lt="concept-custom-element-definition-disable-shadow">disable shadow</a> is true,
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure what's the correct way to make a link to "disable shadow" flag.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Once HTML has exported this term it should work. I wonder if we should throw InvalidStateError instead as this would allow distinguishing between it being a shadow host and it being disabled, no?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought that InvalidStateError was not suitable because the context object can't be 'valid' state again. But I found the context object was valid before calling custom element constructor. So InvalidStateError seems to make sense.

attachInternals() has the same issue.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah okay, let's change both then.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW, the previous step checks element types, and this step is also a kind of element type check. NotSupportedError is consistent with the previous step.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So we use NotSupportedError when there's already a shadow tree?

I don't think so. It's definitely an issue of context object's state. I think InvalidStateError is appropriate.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You appear to be arguing for exposing the distinction between a shadow root being forbidden and one being used. I care about removing that distinction. I don't really care about types of exceptions as it's not clear to me we've been consistent enough for the differences between them to be meaningful. What do you propose?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, I understand your intention.
Then I think NotSupportedError is ok for all of four DOMExceptions thrown by attachShadow(). IMO InvalidStateError is a specific subset of NotSupportedError.

Anyway, this PR doesn't change the DOMException type of the already-attached case. It's not in the scope of this PR.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you want to do them separately I think we'll need to first change the existing exceptions then and then land this PR. Otherwise landing this would result in a broken state.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I posted #761 and will now work on tests and browser bugs.

domenic added a commit that referenced this pull request May 15, 2019
Discussed in #760. This makes the various cases less distinguishable,
which is desirable. With this change, all three cases behave the same
between:

- A custom element with disabled-shadow
- A custom element with a shadow tree
- A built-in element on the blocklist
@domenic
Copy link
Member

domenic commented May 15, 2019

Doesn't this fail to respect the disable-shadow flag for customized built-in elements on the safelist? E.g. <h4 is="special-h4"> with

customElements.define("special-h4", class extends HTMLHeadingElement {
  disabledFeatures = ['shadow'];
}, { extends: 'h4' });

I think we need to pass the node's is value. I will add a commit to do that, but we should also update the tests.

@@ -6767,6 +6767,22 @@ invoked, must run these steps:
"<code>section</code>", or
"<code>span</code>", then <a>throw</a> a "{{NotSupportedError!!exception}}" {{DOMException}}.

<li>
<p>If <a>context object</a>'s <a for=Element>local name</a> is a
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need to change this to something like:

If context object's local name is a valid custom element name, or
context object's is value is not null, then:

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in a new commit.

@annevk
Copy link
Member

annevk commented May 16, 2019

Assuming this is rebased on top of / lands after #761 this seems fine to me.

domenic pushed a commit to whatwg/html that referenced this pull request May 16, 2019
This provides the ElementInternals interface, which can be obtained for
custom elements via the element.attachInternals() method. For now
ElementInternals is empty, but it will gain members in #4383.

This also adds the ability for custom elements to set the
disabledFeatures static property, to disable element internals and
shadow DOM. Some DOM-side infrastructure work there is necessary in
whatwg/dom#760.

Tests:
- web-platform-tests/wpt#15123
- web-platform-tests/wpt#15516
- web-platform-tests/wpt#16853

Fixes WICG/webcomponents#758.
domenic added a commit that referenced this pull request May 16, 2019
Discussed in #760. This makes the various cases less distinguishable,
which is desirable. With this change, all three cases behave the same
between:

- A custom element with disabled-shadow
- A custom element with a shadow tree
- A built-in element on the blocklist
domenic pushed a commit to web-platform-tests/wpt that referenced this pull request May 16, 2019
@domenic domenic merged commit daa525d into whatwg:master May 16, 2019
@emilio
Copy link
Contributor

emilio commented May 27, 2019

This is a bit racy isn't it? As in, if you attach the shadow before the custom element definition then it works, otherwise it doesn't...

@annevk
Copy link
Member

annevk commented May 27, 2019

Yeah, not sure what can be done about that though. I suppose we could let "upgrade an element" fail, because the "preconditions" were broken.

@annevk
Copy link
Member

annevk commented May 29, 2019

@tkent-google @domenic thoughts on @emilio's comment? If we want to make "upgrade an element" fail we should probably decide sooner rather than later.

@domenic
Copy link
Member

domenic commented May 29, 2019

I don't have strong feelings on disable-shadow in general.

@tkent-google
Copy link
Collaborator Author

attachInternals() has the same issue.

If we want to make "upgrade an element" fail

It sounds a reasonable fix.

@tkent-google tkent-google deleted the tkent-attachShadow branch May 30, 2019 06:15
@annevk
Copy link
Member

annevk commented Jun 4, 2019

Follow-up at whatwg/html#4673.

moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this pull request Jun 19, 2019
…ow() with disabledFeatures=['shadow'], a=testonly

Automatic update from web-platform-tests
Test attachShadow() with disabledFeatures=['shadow']

Follows whatwg/dom#760.
--

wp5At-commits: 7e939f6d8eac12d0830d8a47eb72e38097b12f9e
wpt-pr: 16795
xeonchen pushed a commit to xeonchen/gecko that referenced this pull request Jun 19, 2019
…ow() with disabledFeatures=['shadow'], a=testonly

Automatic update from web-platform-tests
Test attachShadow() with disabledFeatures=['shadow']

Follows whatwg/dom#760.
--

wp5At-commits: 7e939f6d8eac12d0830d8a47eb72e38097b12f9e
wpt-pr: 16795
marcoscaceres pushed a commit to web-platform-tests/wpt that referenced this pull request Jul 23, 2019
gecko-dev-updater pushed a commit to marco-c/gecko-dev-comments-removed that referenced this pull request Oct 4, 2019
…ow() with disabledFeatures=['shadow'], a=testonly

Automatic update from web-platform-tests
Test attachShadow() with disabledFeatures=['shadow']

Follows whatwg/dom#760.
--

wp5At-commits: 7e939f6d8eac12d0830d8a47eb72e38097b12f9e
wpt-pr: 16795

UltraBlame original commit: cd6ef5f5cfc4319d357c0162f28b62f3531a14b3
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified that referenced this pull request Oct 4, 2019
…ow() with disabledFeatures=['shadow'], a=testonly

Automatic update from web-platform-tests
Test attachShadow() with disabledFeatures=['shadow']

Follows whatwg/dom#760.
--

wp5At-commits: 7e939f6d8eac12d0830d8a47eb72e38097b12f9e
wpt-pr: 16795

UltraBlame original commit: cd6ef5f5cfc4319d357c0162f28b62f3531a14b3
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified-and-comments-removed that referenced this pull request Oct 4, 2019
…ow() with disabledFeatures=['shadow'], a=testonly

Automatic update from web-platform-tests
Test attachShadow() with disabledFeatures=['shadow']

Follows whatwg/dom#760.
--

wp5At-commits: 7e939f6d8eac12d0830d8a47eb72e38097b12f9e
wpt-pr: 16795

UltraBlame original commit: cd6ef5f5cfc4319d357c0162f28b62f3531a14b3
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

4 participants