Add declarative Shadow DOM features by mfreed7 · Pull Request #5465 · whatwg/html (original) (raw)

@sideshowbarker added the impacts documentation

Used by documentation communities, such as MDN, to track changes that impact documentation

label

Apr 18, 2020

pull Bot pushed a commit to Yannic/chromium that referenced this pull request

Apr 21, 2020

@mfreed7

This CL cleans up the variations of element::attachShadow(), refactoring the common subset back into attachShadow(). It also replaces the bool delegates_focus and manual_slotting parameters with enum versions that are common across declarative and imperative calls.

This CL should not change any functionality.

The spec text comes from my two PRs against DOM [1] and HTML [2].

[1] whatwg/dom#858 [2] whatwg/html#5465

Bug: 1042130 Change-Id: I3835b9d344d8005b6854909f287083cd984e832e Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2155144 Commit-Queue: Mason Freed masonfreed@chromium.org Auto-Submit: Mason Freed masonfreed@chromium.org Reviewed-by: Kouhei Ueno kouhei@chromium.org Cr-Commit-Position: refs/heads/master@{#760704}

This was referenced

May 4, 2020

annevk

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request

Nov 4, 2020

@mfreed7 @chromium-wpt-export-bot

This CL implements most of the suggestions from [1], which effectively block declarative Shadow DOM from being used by any fragment parser entry point, unless an explicit opt-in is toggled.

The opt-ins include:

This mitigates the potential client-side XSS sanitizer bypass detailed in the explainer and at [1]. Assuming these changes are functional, and mitigate the issue, this new behavior will be folded into the spec PRs at [2] and [3]. But given the security implications of the existing code, I'd like to get this landed first.

[1] whatwg/dom#912 (comment) [2] whatwg/html#5465 [3] whatwg/dom#892

Bug: 1042130 Change-Id: I088f28f63078a0d26e354a4442494c0132b47ffc

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request

Nov 5, 2020

@mfreed7 @chromium-wpt-export-bot

This CL implements most of the suggestions from [1], which effectively block declarative Shadow DOM from being used by any fragment parser entry point, unless an explicit opt-in is toggled.

The opt-ins include:

This mitigates the potential client-side XSS sanitizer bypass detailed in the explainer and at [1]. Assuming these changes are functional, and mitigate the issue, this new behavior will be folded into the spec PRs at [2] and [3]. But given the security implications of the existing code, I'd like to get this landed first.

[1] whatwg/dom#912 (comment) [2] whatwg/html#5465 [3] whatwg/dom#892

Bug: 1042130 Change-Id: I088f28f63078a0d26e354a4442494c0132b47ffc

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request

Nov 5, 2020

@mfreed7 @chromium-wpt-export-bot

This CL implements most of the suggestions from [1], which effectively block declarative Shadow DOM from being used by any fragment parser entry point, unless an explicit opt-in is toggled.

The opt-ins include:

This mitigates the potential client-side XSS sanitizer bypass detailed in the explainer and at [1]. Assuming these changes are functional, and mitigate the issue, this new behavior will be folded into the spec PRs at [2] and [3]. But given the security implications of the existing code, I'd like to get this landed first.

[1] whatwg/dom#912 (comment) [2] whatwg/html#5465 [3] whatwg/dom#892

Bug: 1042130 Change-Id: I088f28f63078a0d26e354a4442494c0132b47ffc

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request

Nov 5, 2020

@mfreed7 @chromium-wpt-export-bot

This CL implements most of the suggestions from [1], which effectively block declarative Shadow DOM from being used by any fragment parser entry point, unless an explicit opt-in is toggled.

The opt-ins include:

This mitigates the potential client-side XSS sanitizer bypass detailed in the explainer and at [1]. Assuming these changes are functional, and mitigate the issue, this new behavior will be folded into the spec PRs at [2] and [3]. But given the security implications of the existing code, I'd like to get this landed first.

[1] whatwg/dom#912 (comment) [2] whatwg/html#5465 [3] whatwg/dom#892

Bug: 1042130 Change-Id: I088f28f63078a0d26e354a4442494c0132b47ffc Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2513525 Commit-Queue: Mason Freed masonfreed@chromium.org Reviewed-by: Kouhei Ueno kouhei@chromium.org Reviewed-by: Kinuko Yasuda kinuko@chromium.org Cr-Commit-Position: refs/heads/master@{#824591}

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request

Nov 5, 2020

@mfreed7 @chromium-wpt-export-bot

This CL implements most of the suggestions from [1], which effectively block declarative Shadow DOM from being used by any fragment parser entry point, unless an explicit opt-in is toggled.

The opt-ins include:

This mitigates the potential client-side XSS sanitizer bypass detailed in the explainer and at [1]. Assuming these changes are functional, and mitigate the issue, this new behavior will be folded into the spec PRs at [2] and [3]. But given the security implications of the existing code, I'd like to get this landed first.

[1] whatwg/dom#912 (comment) [2] whatwg/html#5465 [3] whatwg/dom#892

Bug: 1042130 Change-Id: I088f28f63078a0d26e354a4442494c0132b47ffc Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2513525 Commit-Queue: Mason Freed masonfreed@chromium.org Reviewed-by: Kouhei Ueno kouhei@chromium.org Reviewed-by: Kinuko Yasuda kinuko@chromium.org Cr-Commit-Position: refs/heads/master@{#824591}

moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this pull request

Nov 7, 2020

@mfreed7 @moz-wptsync-bot

…arsing to be opt-in, a=testonly

Automatic update from web-platform-tests Change declarative Shadow DOM fragment parsing to be opt-in

This CL implements most of the suggestions from [1], which effectively block declarative Shadow DOM from being used by any fragment parser entry point, unless an explicit opt-in is toggled.

The opt-ins include:

This mitigates the potential client-side XSS sanitizer bypass detailed in the explainer and at [1]. Assuming these changes are functional, and mitigate the issue, this new behavior will be folded into the spec PRs at [2] and [3]. But given the security implications of the existing code, I'd like to get this landed first.

[1] whatwg/dom#912 (comment) [2] whatwg/html#5465 [3] whatwg/dom#892

Bug: 1042130 Change-Id: I088f28f63078a0d26e354a4442494c0132b47ffc Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2513525 Commit-Queue: Mason Freed masonfreed@chromium.org Reviewed-by: Kouhei Ueno kouhei@chromium.org Reviewed-by: Kinuko Yasuda kinuko@chromium.org Cr-Commit-Position: refs/heads/master@{#824591}

--

wpt-commits: b13461b9a46b46eb1b092a58bde2b10418e7a73d wpt-pr: 26398

sidvishnoi pushed a commit to sidvishnoi/gecko-webmonetization that referenced this pull request

Nov 10, 2020

@mfreed7 @moz-wptsync-bot

…arsing to be opt-in, a=testonly

Automatic update from web-platform-tests Change declarative Shadow DOM fragment parsing to be opt-in

This CL implements most of the suggestions from [1], which effectively block declarative Shadow DOM from being used by any fragment parser entry point, unless an explicit opt-in is toggled.

The opt-ins include:

This mitigates the potential client-side XSS sanitizer bypass detailed in the explainer and at [1]. Assuming these changes are functional, and mitigate the issue, this new behavior will be folded into the spec PRs at [2] and [3]. But given the security implications of the existing code, I'd like to get this landed first.

[1] whatwg/dom#912 (comment) [2] whatwg/html#5465 [3] whatwg/dom#892

Bug: 1042130 Change-Id: I088f28f63078a0d26e354a4442494c0132b47ffc Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2513525 Commit-Queue: Mason Freed masonfreed@chromium.org Reviewed-by: Kouhei Ueno kouhei@chromium.org Reviewed-by: Kinuko Yasuda kinuko@chromium.org Cr-Commit-Position: refs/heads/master@{#824591}

--

wpt-commits: b13461b9a46b46eb1b092a58bde2b10418e7a73d wpt-pr: 26398

annevk

@mfreed7

More edits

Fixup

Cleanup

Add language for content

Add shadow root serialization

Link to new "attach a shadow root" algorithm. Added exception handling.

Add early-out for topmost node

Added shadowroot to HTMLTemplateElement for feature detection

Addressed annevk's comments

Add available_to_internals = true

Add declarative shadow dom opt-in mechanics

Trying, unsuccessfully, to get rid of "parse error while closing p element"

Remove data-x for instance checks

Merge fixup

Rename include shadow roots state

Strip out serialization stuff

Lint cleanup

Fix closing tags

Fix dfn

Fix conformance error

Address all comments

Fix lint

First cut at streaming DSD definition

Address some comments

Address @rniwa comments

Capitalization

Rename shadowrootmode and add clonable

Address comments

Address comments

Line length

Fix regular document parsing

Address comments

Update to match DOM's new declarative

Clean up call to attach a shadow root

Address speculative parser comment

Replace tri-state with boolean

Allow about:blank

Address annevk comments

Address annevk comments

Report the exception

@mfreed7

@mfreed7

@mfreed7

@mfreed7

@mfreed7

@mfreed7

@mfreed7

@mfreed7

@mfreed7

@mfreed7

@mfreed7

@mfreed7

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request

Oct 11, 2023

@mfreed7 @chromium-wpt-export-bot

The spec PR [1] is about to land, so these tests should no longer be tentative.

[1] whatwg/html#5465

Bug: 1379513 Change-Id: I577abb26b3c29a04f14ddafec7400abadb4119ed

aarongable pushed a commit to chromium/chromium that referenced this pull request

Oct 11, 2023

@mfreed7

annevk

@annevk

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})