Handling of parser-created customized built-in elements with throwing constructors is undefined #5084

bzbarsky · 2019-11-14T17:16:40Z

Consider this testcase:

    <!DOCTYPE html>
    <html>
      <head>
        <script type="text/javascript">
          customElements.define("custom-p",
            class extends HTMLParagraphElement {
              constructor() {
                super();
                throw new Error("Hello");
              }
            }, {
              extends: "p",
            });
        </script>
      </head>
      <body>
        <p is="custom-p"></p>
      </body>
    </html>

What should happen per spec?

We are parsing along and land in https://html.spec.whatwg.org/multipage/parsing.html#create-an-element-for-the-token as far as I can tell. Step 7 calls into https://dom.spec.whatwg.org/#concept-create-element which lands in step 5 (because the custom element definition has "custom-p" as name and "p" as localName). This does a synchronous upgrade (since we are not in an innerHTML setter), so we land in https://html.spec.whatwg.org/multipage/custom-elements.html#concept-upgrade-an-element and call the constructor, which throws. We rethrow that at the end of step 8 of the upgrade. Step 5 of "create an element" does nothing to catch the exception, which is then rethrown out to the HTML parser.

And now what? The parser doesn't seem to have provisions for an exception here, or failure to create an element...

Implementations are not interoperable here. Firefox creates an element with localName set to "p" and proto set to the custom class proto. Chrome creates an element with localName set to "p" and proto set to HTMLUnknownElement.prototype. I suspect Chrome is actually running step 6 of "create an element", not step 5, based on some other behaviors I am seeing out of Chrome...

@domenic @annevk

The text was updated successfully, but these errors were encountered:

bzbarsky · 2019-11-14T17:28:14Z

I filed https://bugs.chromium.org/p/chromium/issues/detail?id=1024866 on what I think is the buggy Chrome behavior involved.

annevk · 2019-11-15T13:01:12Z

cc @tkent-google

domenic · 2019-11-18T19:19:58Z

My preferred fix here would be to make step 6 (autonomous custom elements) parallel step 5 (customized built-in elements). I.e., catch exceptions while running user code, and if they occur:

Report the exception
Return a new HTMLUnknownElement.

Some details still to be figured out, but does that general idea seem reasonable? If so I can work on a pull request to DOM.

bzbarsky · 2019-11-18T19:59:17Z

One drawback of doing that is that failure to apply the custom element would mean that you can't use any of the element's "normal" APIs. For example, if I have a custom element attached to a <form> via is to add some APIs to it, and the custom constructor throws, suddenly I would not be able to submit() the form either. This isn't an issue for autonomous custom elements, because HTMLUnknownElement exposes all the APIs HTMLElement does.

We'd need to do something about the thing that had escaped into script already with the "wrong" prototype, so maybe we should create a new element anyway, but the question is what sort of element to create, or at least what it's ES reflection looks like.

domenic · 2019-11-18T20:33:23Z

I guess it's a question as to whether we want failures to be loud or quiet. I was suggesting loud failures. (I.e., if something as fundamental as element creation went wrong, let's make sure that's obvious whenever you try to touch it.)

If we wanted quiet failures, I'd be comfortable using the extra information we have on hand to use the appropriate element interface.

domenic · 2019-11-19T16:28:27Z

Does anyone from @whatwg/components have opinions? (Also /ccing @rakina and @tkent-google since I just added them to the components team, which they weren't on before.)

The situation is that you have a customized built-in <form is="custom-form"> element, whose custom element constructor throws. Should the result be creating a new HTMLFormElement or a new HTMLUnknownElement?

Argument for HTMLFormElement: at least you can still use it like a "normal" <form> element, e.g. calling el.submit(), despite the customized features being broken.
Argument for HTMLUnknownElement: something got messed up, so it's better if any script that tries to use the element (even in normal ways like el.submit()) fail loudly.

I could go either way. The spec is currently broken so we should pick one and fix it ASAP.

bzbarsky · 2019-11-19T17:34:30Z

One thing that concerns me is that the thing that registered the custom element is not the only script that might be touching that DOM. There are other scripts on the page, user bookmarklets, etc, etc. I would prefer not breaking those if possible. In the case of bookmarklets, there is no value in making them fail in this situation; on the contrary there is user harm.

tkent-google · 2019-11-19T23:38:03Z

I don't have a strong opinion now, but I lean to @bzbarsky's last comment.

domenic · 2019-12-02T20:25:55Z

OK, with two weak opinions in that direction and one weak opinion in the other direction, let's go for HTMLFormElement.

What remains is whether we should return the element that already escaped into the (exception-throwing) script, or create a new one. I guess reusing the existing one seems simpler and cleaner; it makes the sync case behave a bit more like the async case, I guess. I'll post a patch doing that for now, but I'm happy to go another way.

Closes whatwg/html#5084.

This CL implements two changes: 1. It fixes the implementation to better match the spec for the "create an element for the token" [1] algorithm. Prior to this CL, step 7 of that algorithm was skipping directly to step 6 of the "create an element" [2] algorithm, skipping over step 5 for customized built-in elements. This is now fixed. This case is illustrated by the issue and example at [3] and [4]. This becomes the first test in customized-built-in-constructor-exceptions.html. 2. It updates the comments to match the new behavior discussed in [3] and the [5] spec PR, which changes the return value in the case that a customized built-in element constructor throws an exception. With the change above, that is actually already the behavior. So this is just a comment change. Two new tests are added to customized-built-in-constructor-exceptions.html. [1] https://html.spec.whatwg.org/multipage/parsing.html#create-an-element-for-the-token [2] https://dom.spec.whatwg.org/#concept-create-element [3] whatwg/html#5084 [4] https://crbug.com/1024866 [5] whatwg/dom#797 Bug: 1071059, 1024866 Change-Id: I814c81991eb5e83501304bcb3d2da476743aef52 Cq-Do-Not-Cancel-Tryjobs: true

mfreed7 · 2020-04-20T22:29:54Z

I added a rough test for this here.

Closes whatwg/html#5084. Tests: web-platform-tests/wpt#23072

This CL implements two changes: 1. It fixes the implementation to better match the spec for the "create an element for the token" [1] algorithm. Prior to this CL, step 7 of that algorithm was skipping directly to step 6 of the "create an element" [2] algorithm, skipping over step 5 for customized built-in elements. This is now fixed. This case is illustrated by the issue and example at [3] and [4]. This becomes the first test in customized-built-in-constructor-exceptions.html. 2. It updates the comments to match the new behavior discussed in [3] and the [5] spec PR, which changes the return value in the case that a customized built-in element constructor throws an exception. With the change above, that is actually already the behavior. So this is just a comment change. Two new tests are added to customized-built-in-constructor-exceptions.html. [1] https://html.spec.whatwg.org/multipage/parsing.html#create-an-element-for-the-token [2] https://dom.spec.whatwg.org/#concept-create-element [3] whatwg/html#5084 [4] https://crbug.com/1024866 [5] whatwg/dom#797 Bug: 1071059, 1024866 Change-Id: I814c81991eb5e83501304bcb3d2da476743aef52 Cq-Do-Not-Cancel-Tryjobs: true Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2152986 Commit-Queue: Mason Freed <[email protected]> Auto-Submit: Mason Freed <[email protected]> Reviewed-by: Kent Tamura <[email protected]> Cr-Commit-Position: refs/heads/master@{#760705}

This CL implements two changes: 1. It fixes the implementation to better match the spec for the "create an element for the token" [1] algorithm. Prior to this CL, step 7 of that algorithm was skipping directly to step 6 of the "create an element" [2] algorithm, skipping over step 5 for customized built-in elements. This is now fixed. This case is illustrated by the issue and example at [3] and [4]. This becomes the first test in customized-built-in-constructor-exceptions.html. 2. It updates the comments to match the new behavior discussed in [3] and the [5] spec PR, which changes the return value in the case that a customized built-in element constructor throws an exception. With the change above, that is actually already the behavior. So this is just a comment change. Two new tests are added to customized-built-in-constructor-exceptions.html. [1] https://html.spec.whatwg.org/multipage/parsing.html#create-an-element-for-the-token [2] https://dom.spec.whatwg.org/#concept-create-element [3] whatwg/html#5084 [4] https://crbug.com/1024866 [5] whatwg/dom#797 Bug: 1071059, 1024866 Change-Id: I814c81991eb5e83501304bcb3d2da476743aef52 Cq-Do-Not-Cancel-Tryjobs: true Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2152986 Commit-Queue: Mason Freed <[email protected]> Auto-Submit: Mason Freed <[email protected]> Reviewed-by: Kent Tamura <[email protected]> Cr-Commit-Position: refs/heads/master@{#760705}

Closes whatwg/html#5084. Tests: web-platform-tests/wpt#23072

…tor behavior, a=testonly Automatic update from web-platform-tests Fix customized built-in element constructor behavior This CL implements two changes: 1. It fixes the implementation to better match the spec for the "create an element for the token" [1] algorithm. Prior to this CL, step 7 of that algorithm was skipping directly to step 6 of the "create an element" [2] algorithm, skipping over step 5 for customized built-in elements. This is now fixed. This case is illustrated by the issue and example at [3] and [4]. This becomes the first test in customized-built-in-constructor-exceptions.html. 2. It updates the comments to match the new behavior discussed in [3] and the [5] spec PR, which changes the return value in the case that a customized built-in element constructor throws an exception. With the change above, that is actually already the behavior. So this is just a comment change. Two new tests are added to customized-built-in-constructor-exceptions.html. [1] https://html.spec.whatwg.org/multipage/parsing.html#create-an-element-for-the-token [2] https://dom.spec.whatwg.org/#concept-create-element [3] whatwg/html#5084 [4] https://crbug.com/1024866 [5] whatwg/dom#797 Bug: 1071059, 1024866 Change-Id: I814c81991eb5e83501304bcb3d2da476743aef52 Cq-Do-Not-Cancel-Tryjobs: true Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2152986 Commit-Queue: Mason Freed <[email protected]> Auto-Submit: Mason Freed <[email protected]> Reviewed-by: Kent Tamura <[email protected]> Cr-Commit-Position: refs/heads/master@{#760705} -- wpt-commits: 8086723599f2bcdcbf54bcecff8cc50038cf939a wpt-pr: 23072

This CL implements two changes: 1. It fixes the implementation to better match the spec for the "create an element for the token" [1] algorithm. Prior to this CL, step 7 of that algorithm was skipping directly to step 6 of the "create an element" [2] algorithm, skipping over step 5 for customized built-in elements. This is now fixed. This case is illustrated by the issue and example at [3] and [4]. This becomes the first test in customized-built-in-constructor-exceptions.html. 2. It updates the comments to match the new behavior discussed in [3] and the [5] spec PR, which changes the return value in the case that a customized built-in element constructor throws an exception. With the change above, that is actually already the behavior. So this is just a comment change. Two new tests are added to customized-built-in-constructor-exceptions.html. [1] https://html.spec.whatwg.org/multipage/parsing.html#create-an-element-for-the-token [2] https://dom.spec.whatwg.org/#concept-create-element [3] whatwg/html#5084 [4] https://crbug.com/1024866 [5] whatwg/dom#797 [email protected] (cherry picked from commit 7101418) Bug: 1071059, 1024866 Change-Id: I814c81991eb5e83501304bcb3d2da476743aef52 Cq-Do-Not-Cancel-Tryjobs: true Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2152986 Commit-Queue: Mason Freed <[email protected]> Auto-Submit: Mason Freed <[email protected]> Reviewed-by: Kent Tamura <[email protected]> Cr-Original-Commit-Position: refs/heads/master@{#760705} Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2168800 Reviewed-by: Mason Freed <[email protected]> Cr-Commit-Position: refs/branch-heads/4044@{#985} Cr-Branched-From: a6d9daf-refs/heads/master@{#737173}

…tor behavior, a=testonly Automatic update from web-platform-tests Fix customized built-in element constructor behavior This CL implements two changes: 1. It fixes the implementation to better match the spec for the "create an element for the token" [1] algorithm. Prior to this CL, step 7 of that algorithm was skipping directly to step 6 of the "create an element" [2] algorithm, skipping over step 5 for customized built-in elements. This is now fixed. This case is illustrated by the issue and example at [3] and [4]. This becomes the first test in customized-built-in-constructor-exceptions.html. 2. It updates the comments to match the new behavior discussed in [3] and the [5] spec PR, which changes the return value in the case that a customized built-in element constructor throws an exception. With the change above, that is actually already the behavior. So this is just a comment change. Two new tests are added to customized-built-in-constructor-exceptions.html. [1] https://html.spec.whatwg.org/multipage/parsing.html#create-an-element-for-the-token [2] https://dom.spec.whatwg.org/#concept-create-element [3] whatwg/html#5084 [4] https://crbug.com/1024866 [5] whatwg/dom#797 Bug: 1071059, 1024866 Change-Id: I814c81991eb5e83501304bcb3d2da476743aef52 Cq-Do-Not-Cancel-Tryjobs: true Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2152986 Commit-Queue: Mason Freed <masonfreedchromium.org> Auto-Submit: Mason Freed <masonfreedchromium.org> Reviewed-by: Kent Tamura <tkentchromium.org> Cr-Commit-Position: refs/heads/master{#760705} -- wpt-commits: 8086723599f2bcdcbf54bcecff8cc50038cf939a wpt-pr: 23072 UltraBlame original commit: b4489b28cd64543c78ab8aed7788fe827c346a1d

…tor behavior, a=testonly Automatic update from web-platform-tests Fix customized built-in element constructor behavior This CL implements two changes: 1. It fixes the implementation to better match the spec for the "create an element for the token" [1] algorithm. Prior to this CL, step 7 of that algorithm was skipping directly to step 6 of the "create an element" [2] algorithm, skipping over step 5 for customized built-in elements. This is now fixed. This case is illustrated by the issue and example at [3] and [4]. This becomes the first test in customized-built-in-constructor-exceptions.html. 2. It updates the comments to match the new behavior discussed in [3] and the [5] spec PR, which changes the return value in the case that a customized built-in element constructor throws an exception. With the change above, that is actually already the behavior. So this is just a comment change. Two new tests are added to customized-built-in-constructor-exceptions.html. [1] https://html.spec.whatwg.org/multipage/parsing.html#create-an-element-for-the-token [2] https://dom.spec.whatwg.org/#concept-create-element [3] whatwg/html#5084 [4] https://crbug.com/1024866 [5] whatwg/dom#797 Bug: 1071059, 1024866 Change-Id: I814c81991eb5e83501304bcb3d2da476743aef52 Cq-Do-Not-Cancel-Tryjobs: true Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2152986 Commit-Queue: Mason Freed <masonfreedchromium.org> Auto-Submit: Mason Freed <masonfreedchromium.org> Reviewed-by: Kent Tamura <tkentchromium.org> Cr-Commit-Position: refs/heads/master{#760705} -- wpt-commits: 8086723599f2bcdcbf54bcecff8cc50038cf939a wpt-pr: 23072 UltraBlame original commit: f016ab30013b235661e8aa9f4f86e09cb98ff522

…tor behavior, a=testonly Automatic update from web-platform-tests Fix customized built-in element constructor behavior This CL implements two changes: 1. It fixes the implementation to better match the spec for the "create an element for the token" [1] algorithm. Prior to this CL, step 7 of that algorithm was skipping directly to step 6 of the "create an element" [2] algorithm, skipping over step 5 for customized built-in elements. This is now fixed. This case is illustrated by the issue and example at [3] and [4]. This becomes the first test in customized-built-in-constructor-exceptions.html. 2. It updates the comments to match the new behavior discussed in [3] and the [5] spec PR, which changes the return value in the case that a customized built-in element constructor throws an exception. With the change above, that is actually already the behavior. So this is just a comment change. Two new tests are added to customized-built-in-constructor-exceptions.html. [1] https://html.spec.whatwg.org/multipage/parsing.html#create-an-element-for-the-token [2] https://dom.spec.whatwg.org/#concept-create-element [3] whatwg/html#5084 [4] https://crbug.com/1024866 [5] whatwg/dom#797 Bug: 1071059, 1024866 Change-Id: I814c81991eb5e83501304bcb3d2da476743aef52 Cq-Do-Not-Cancel-Tryjobs: true Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2152986 Commit-Queue: Mason Freed <masonfreedchromium.org> Auto-Submit: Mason Freed <masonfreedchromium.org> Reviewed-by: Kent Tamura <tkentchromium.org> Cr-Commit-Position: refs/heads/master{#760705} -- wpt-commits: 8086723599f2bcdcbf54bcecff8cc50038cf939a wpt-pr: 23072 UltraBlame original commit: b4489b28cd64543c78ab8aed7788fe827c346a1d

…tor behavior, a=testonly Automatic update from web-platform-tests Fix customized built-in element constructor behavior This CL implements two changes: 1. It fixes the implementation to better match the spec for the "create an element for the token" [1] algorithm. Prior to this CL, step 7 of that algorithm was skipping directly to step 6 of the "create an element" [2] algorithm, skipping over step 5 for customized built-in elements. This is now fixed. This case is illustrated by the issue and example at [3] and [4]. This becomes the first test in customized-built-in-constructor-exceptions.html. 2. It updates the comments to match the new behavior discussed in [3] and the [5] spec PR, which changes the return value in the case that a customized built-in element constructor throws an exception. With the change above, that is actually already the behavior. So this is just a comment change. Two new tests are added to customized-built-in-constructor-exceptions.html. [1] https://html.spec.whatwg.org/multipage/parsing.html#create-an-element-for-the-token [2] https://dom.spec.whatwg.org/#concept-create-element [3] whatwg/html#5084 [4] https://crbug.com/1024866 [5] whatwg/dom#797 Bug: 1071059, 1024866 Change-Id: I814c81991eb5e83501304bcb3d2da476743aef52 Cq-Do-Not-Cancel-Tryjobs: true Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2152986 Commit-Queue: Mason Freed <masonfreedchromium.org> Auto-Submit: Mason Freed <masonfreedchromium.org> Reviewed-by: Kent Tamura <tkentchromium.org> Cr-Commit-Position: refs/heads/master{#760705} -- wpt-commits: 8086723599f2bcdcbf54bcecff8cc50038cf939a wpt-pr: 23072 UltraBlame original commit: f016ab30013b235661e8aa9f4f86e09cb98ff522

…tor behavior, a=testonly Automatic update from web-platform-tests Fix customized built-in element constructor behavior This CL implements two changes: 1. It fixes the implementation to better match the spec for the "create an element for the token" [1] algorithm. Prior to this CL, step 7 of that algorithm was skipping directly to step 6 of the "create an element" [2] algorithm, skipping over step 5 for customized built-in elements. This is now fixed. This case is illustrated by the issue and example at [3] and [4]. This becomes the first test in customized-built-in-constructor-exceptions.html. 2. It updates the comments to match the new behavior discussed in [3] and the [5] spec PR, which changes the return value in the case that a customized built-in element constructor throws an exception. With the change above, that is actually already the behavior. So this is just a comment change. Two new tests are added to customized-built-in-constructor-exceptions.html. [1] https://html.spec.whatwg.org/multipage/parsing.html#create-an-element-for-the-token [2] https://dom.spec.whatwg.org/#concept-create-element [3] whatwg/html#5084 [4] https://crbug.com/1024866 [5] whatwg/dom#797 Bug: 1071059, 1024866 Change-Id: I814c81991eb5e83501304bcb3d2da476743aef52 Cq-Do-Not-Cancel-Tryjobs: true Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2152986 Commit-Queue: Mason Freed <masonfreedchromium.org> Auto-Submit: Mason Freed <masonfreedchromium.org> Reviewed-by: Kent Tamura <tkentchromium.org> Cr-Commit-Position: refs/heads/master{#760705} -- wpt-commits: 8086723599f2bcdcbf54bcecff8cc50038cf939a wpt-pr: 23072 UltraBlame original commit: b4489b28cd64543c78ab8aed7788fe827c346a1d

…tor behavior, a=testonly Automatic update from web-platform-tests Fix customized built-in element constructor behavior This CL implements two changes: 1. It fixes the implementation to better match the spec for the "create an element for the token" [1] algorithm. Prior to this CL, step 7 of that algorithm was skipping directly to step 6 of the "create an element" [2] algorithm, skipping over step 5 for customized built-in elements. This is now fixed. This case is illustrated by the issue and example at [3] and [4]. This becomes the first test in customized-built-in-constructor-exceptions.html. 2. It updates the comments to match the new behavior discussed in [3] and the [5] spec PR, which changes the return value in the case that a customized built-in element constructor throws an exception. With the change above, that is actually already the behavior. So this is just a comment change. Two new tests are added to customized-built-in-constructor-exceptions.html. [1] https://html.spec.whatwg.org/multipage/parsing.html#create-an-element-for-the-token [2] https://dom.spec.whatwg.org/#concept-create-element [3] whatwg/html#5084 [4] https://crbug.com/1024866 [5] whatwg/dom#797 Bug: 1071059, 1024866 Change-Id: I814c81991eb5e83501304bcb3d2da476743aef52 Cq-Do-Not-Cancel-Tryjobs: true Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2152986 Commit-Queue: Mason Freed <masonfreedchromium.org> Auto-Submit: Mason Freed <masonfreedchromium.org> Reviewed-by: Kent Tamura <tkentchromium.org> Cr-Commit-Position: refs/heads/master{#760705} -- wpt-commits: 8086723599f2bcdcbf54bcecff8cc50038cf939a wpt-pr: 23072 UltraBlame original commit: f016ab30013b235661e8aa9f4f86e09cb98ff522

Fix customized built-in element constructor behavior This CL implements two changes: 1. It fixes the implementation to better match the spec for the "create an element for the token" [1] algorithm. Prior to this CL, step 7 of that algorithm was skipping directly to step 6 of the "create an element" [2] algorithm, skipping over step 5 for customized built-in elements. This is now fixed. This case is illustrated by the issue and example at [3] and [4]. This becomes the first test in customized-built-in-constructor-exceptions.html. 2. It updates the comments to match the new behavior discussed in [3] and the [5] spec PR, which changes the return value in the case that a customized built-in element constructor throws an exception. With the change above, that is actually already the behavior. So this is just a comment change. Two new tests are added to customized-built-in-constructor-exceptions.html. [1] https://html.spec.whatwg.org/multipage/parsing.html#create-an-element-for-the-token [2] https://dom.spec.whatwg.org/#concept-create-element [3] whatwg/html#5084 [4] https://crbug.com/1024866 [5] whatwg/dom#797 [email protected] (cherry picked from commit 7101418f85a0f17e4f9a35dfe3a9acff76340a93) Bug: 1071059, 1024866 Change-Id: I814c81991eb5e83501304bcb3d2da476743aef52 Cq-Do-Not-Cancel-Tryjobs: true Commit-Queue: Mason Freed <[email protected]> Auto-Submit: Mason Freed <[email protected]> Reviewed-by: Kent Tamura <[email protected]> Cr-Original-Commit-Position: refs/heads/master@{#760705} Reviewed-by: Mason Freed <[email protected]> Cr-Commit-Position: refs/branch-heads/4044@{#985} Cr-Branched-From: a6d9daf149a473ceea37f629c41d4527bf2055bd-refs/heads/master@{#737173} Reviewed-by: Michal Klocek <[email protected]>

Fix customized built-in element constructor behavior This CL implements two changes: 1. It fixes the implementation to better match the spec for the "create an element for the token" [1] algorithm. Prior to this CL, step 7 of that algorithm was skipping directly to step 6 of the "create an element" [2] algorithm, skipping over step 5 for customized built-in elements. This is now fixed. This case is illustrated by the issue and example at [3] and [4]. This becomes the first test in customized-built-in-constructor-exceptions.html. 2. It updates the comments to match the new behavior discussed in [3] and the [5] spec PR, which changes the return value in the case that a customized built-in element constructor throws an exception. With the change above, that is actually already the behavior. So this is just a comment change. Two new tests are added to customized-built-in-constructor-exceptions.html. [1] https://html.spec.whatwg.org/multipage/parsing.html#create-an-element-for-the-token [2] https://dom.spec.whatwg.org/#concept-create-element [3] whatwg/html#5084 [4] https://crbug.com/1024866 [5] whatwg/dom#797 [email protected] (cherry picked from commit 7101418f85a0f17e4f9a35dfe3a9acff76340a93) Bug: 1071059, 1024866 Change-Id: I814c81991eb5e83501304bcb3d2da476743aef52 Reviewed-by: Allan Sandfeld Jensen <[email protected]>

annevk added topic: custom elements Relates to custom elements (as defined in DOM and HTML) topic: parser interop Implementations are not interoperable with each other needs tests Moving the issue forward requires someone to write tests labels Nov 15, 2019

domenic added a commit to whatwg/dom that referenced this issue Dec 2, 2019

Catch errors while upgrading customized built-in elements

c1b5bd4

Closes whatwg/html#5084.

domenic mentioned this issue Dec 2, 2019

Catch errors while upgrading customized built-in elements whatwg/dom#797

Merged

chromium-wpt-export-bot mentioned this issue Apr 17, 2020

Fix customized built-in element constructor behavior web-platform-tests/wpt#23072

Merged

domenic closed this as completed in whatwg/dom#797 Apr 20, 2020

domenic added a commit to whatwg/dom that referenced this issue Apr 20, 2020

Catch errors while upgrading customized built-in elements

543b7e3

Closes whatwg/html#5084. Tests: web-platform-tests/wpt#23072

mfreed7 pushed a commit to mfreed7/dom that referenced this issue Apr 27, 2020

Catch errors while upgrading customized built-in elements

898ce6f

Closes whatwg/html#5084. Tests: web-platform-tests/wpt#23072

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Handling of parser-created customized built-in elements with throwing constructors is undefined #5084

Handling of parser-created customized built-in elements with throwing constructors is undefined #5084

bzbarsky commented Nov 14, 2019

bzbarsky commented Nov 14, 2019

annevk commented Nov 15, 2019

domenic commented Nov 18, 2019

bzbarsky commented Nov 18, 2019

domenic commented Nov 18, 2019

domenic commented Nov 19, 2019

bzbarsky commented Nov 19, 2019

tkent-google commented Nov 19, 2019

domenic commented Dec 2, 2019

mfreed7 commented Apr 20, 2020

Handling of parser-created customized built-in elements with throwing constructors is undefined #5084

Handling of parser-created customized built-in elements with throwing constructors is undefined #5084

Comments

bzbarsky commented Nov 14, 2019

bzbarsky commented Nov 14, 2019

annevk commented Nov 15, 2019

domenic commented Nov 18, 2019

bzbarsky commented Nov 18, 2019

domenic commented Nov 18, 2019

domenic commented Nov 19, 2019

bzbarsky commented Nov 19, 2019

tkent-google commented Nov 19, 2019

domenic commented Dec 2, 2019

mfreed7 commented Apr 20, 2020