|
|
Created:
4 years, 1 month ago by yurak Modified:
4 years, 1 month ago CC:
blink-reviews, blink-reviews-dom_chromium.org, chromium-reviews, dglazkov+blink, dominicc+watchlist_chromium.org, eae+blinkwatch, rwlbuis, sof, webcomponents-bugzilla_chromium.org Target Ref:
refs/pending/heads/master Project:
chromium Visibility:
Public. |
Descriptionhttps://dom.spec.whatwg.org/#dom-document-createelement
Definition is checked for HTML namespace elements in document.createElement
Customized built-in elements can now be created with the document.createElement
NOTE: This is behind runtime enabled flag "CustomElementsBuiltin".
Syntax:
https://html.spec.whatwg.org/multipage/scripting.html#custom-elements-customized-builtin-example
Implemented create element algorithm
https://dom.spec.whatwg.org/#concept-create-element
Steps 5-7:
/core/dom/custom/CustomElement.cpp
Added some tests.
(Sorry this patch is big)
BUG=648828, 657583
Committed: https://crrev.com/fe200cd217b99368dbded68a0350d33c552c6a5b
Cr-Commit-Position: refs/heads/master@{#433146}
Patch Set 1 #Patch Set 2 : createElement - sync #
Total comments: 8
Patch Set 3 : Made changes #
Total comments: 2
Patch Set 4 : New tests #Patch Set 5 : New tests #
Total comments: 4
Patch Set 6 : V1 definition check in document::createElement #Patch Set 7 : V1 definition check in document::createElement #
Total comments: 8
Patch Set 8 : More tests, fix case conversion of 'is' attribute #Patch Set 9 : More tests, fix case conversion of 'is' attribute #
Total comments: 3
Patch Set 10 : V0-V1 interoperability #
Total comments: 1
Patch Set 11 : V0-V1 interoperability #Patch Set 12 : patch fix #Messages
Total messages: 28 (14 generated)
Description was changed from ========== createElement - sync BUG= ========== to ========== NOTE: Set behind runtime enabled flag "CustomElementsBuiltin". Customized built-in elements can now be created with the document.createElement syntax. Will add additional tests. BUG=648828,657583 ==========
yurak@google.com changed reviewers: + dominicc@chromium.org, tkent@chromium.org
Description was changed from ========== NOTE: Set behind runtime enabled flag "CustomElementsBuiltin". Customized built-in elements can now be created with the document.createElement syntax. Will add additional tests. BUG=648828,657583 ========== to ========== NOTE: This is behind runtime enabled flag "CustomElementsBuiltin". This patch depends on CR#2446903008 Customized built-in elements can now be created with the document.createElement https://dom.spec.whatwg.org/#dom-document-createelement Syntax: https://html.spec.whatwg.org/multipage/scripting.html#custom-elements-customi... Implemented create element algorithm https://dom.spec.whatwg.org/#concept-create-element Steps 5-7: /core/dom/custom/CustomElement.cpp Will add tests. BUG=648828,657583 ==========
Feedback inline. https://codereview.chromium.org/2477713003/diff/20001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/dom/Document.cpp (right): https://codereview.chromium.org/2477713003/diff/20001/third_party/WebKit/Sour... third_party/WebKit/Source/core/dom/Document.cpp:731: int builtin = 0; Use bool, not int, for true/false values. C++ 'helpfully' does a lot of implicit conversion to bool, because C did not have bool, but just using bool is clearer (if slightly more verbose) in cases like this. https://codereview.chromium.org/2477713003/diff/20001/third_party/WebKit/Sour... third_party/WebKit/Source/core/dom/Document.cpp:737: if (CustomElement::shouldCreateCustomElement(convertLocalName(localName)) || The createElement spec case-converts names sometimes (this convertLocalName thing.) Are there similar conversions for "is"? https://codereview.chromium.org/2477713003/diff/20001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/dom/custom/CustomElement.cpp (right): https://codereview.chromium.org/2477713003/diff/20001/third_party/WebKit/Sour... third_party/WebKit/Source/core/dom/custom/CustomElement.cpp:97: const CustomElementDescriptor& desc = I think you could just make this const CustomElementDescriptor desc(name, tagName.localName()); Hmm, do you think it is awkward to have createElement take tag name/is, but have CustomElementDescriptor take custom element name/tag name? Maybe we should swap the parameters to CustomElementDescriptor. Don't worry about it in this changelist though. https://codereview.chromium.org/2477713003/diff/20001/third_party/WebKit/Sour... third_party/WebKit/Source/core/dom/custom/CustomElement.cpp:103: // 6. If definition is non-null and we have an autonomous custom element Add a link to the spec this is implementing to give these comments context. https://codereview.chromium.org/2477713003/diff/20001/third_party/WebKit/Sour... third_party/WebKit/Source/core/dom/custom/CustomElement.cpp:105: element->setAttribute(HTMLNames::isAttr, is); Hmm, this branch doesn't upgrade. When do these get upgraded? https://codereview.chromium.org/2477713003/diff/20001/third_party/WebKit/Sour... third_party/WebKit/Source/core/dom/custom/CustomElement.cpp:139: int builtin = htmlElementTypeForTag(tagName.localName()) != int -> bool Maybe add a word or two to give this a slightly more descriptive name? Because it checks the runtime flag as well as the tag name, maybe shouldCreateBuiltin or something? https://codereview.chromium.org/2477713003/diff/20001/third_party/WebKit/Sour... third_party/WebKit/Source/core/dom/custom/CustomElement.cpp:153: tagName.localName(), document, 0, CreatedByCreateElement); There's lots of code running around passing 0 for null, but IIRC we write nullptr now for null pointers. See https://www.chromium.org/blink/coding-style#TOC-Null-false-and-0 https://codereview.chromium.org/2477713003/diff/20001/third_party/WebKit/Sour... third_party/WebKit/Source/core/dom/custom/CustomElement.cpp:155: element = HTMLElement::create(tagName, document); We're going to end up in a situation where some people are using document.register and customElements.define in the same page for a while, and we need them to interact cleanly until we can remove document.registerEntirely. Does this affect the tests in LayoutTests/fast/dom/custom? I'm not sure how these code paths interact at this point.
This is very close. Just needs a few tweaks and some tests. https://codereview.chromium.org/2477713003/diff/40001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/dom/Document.cpp (right): https://codereview.chromium.org/2477713003/diff/40001/third_party/WebKit/Sour... third_party/WebKit/Source/core/dom/Document.cpp:718: getTypeExtension(this, stringOrOptions, exceptionState).isEmpty() There should be a cheaper way to do this where you just call getTypeExtension once and use the result. IIRC given a String you can construct an AtomicString which will be empty (like AtomicString()) if the string was empty. https://codereview.chromium.org/2477713003/diff/40001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/dom/custom/CustomElement.cpp (right): https://codereview.chromium.org/2477713003/diff/40001/third_party/WebKit/Sour... third_party/WebKit/Source/core/dom/custom/CustomElement.cpp:97: DCHECK(shouldCreateCustomElement(name)); Could you do a debug build and try something like createElement('div', {is: 'bar'})? I think this 'bar' will fail the DCHECK but evade your other checks, since shouldCreateBuiltin just checks for the presence of the dictionary. createElement('div', {}) is another interesting test. Try to think like an attacker--if you wanted to stress this code and make it crash, how would you do it? Then write unit tests or layout tests (you can put layout tests in LayoutTests/custom-elements as opposed to LayoutTests/custom-elements/spec if they're exercising implementation details) and make it crash. Then fix the crashes. Running out of memory, it's OK to crash; in theory a page should never be able to make us trigger a CHECK or DCHECK though. Failures should be defined in some way. If the spec is deficient or unclear file spec bugs and put TODOs with links to the spec bugs.
Good, more comments inline, more tests indicating how v0 and v1 will interact are needed. Could you "publish" a comment when you've got a new patch ready to review? It makes it easier to see in the review dashboard there's something to respond to. https://codereview.chromium.org/2477713003/diff/80001/third_party/WebKit/Layo... File third_party/WebKit/LayoutTests/custom-elements/spec/create-element-defined-synchronous.html (right): https://codereview.chromium.org/2477713003/diff/80001/third_party/WebKit/Layo... third_party/WebKit/LayoutTests/custom-elements/spec/create-element-defined-synchronous.html:21: (w, constructor, type) => { Maybe name this opt_type indicating it is optional? And maybe it should be called opt_tag? https://codereview.chromium.org/2477713003/diff/80001/third_party/WebKit/Layo... third_party/WebKit/LayoutTests/custom-elements/spec/create-element-defined-synchronous.html:23: w.customElements.define('a-a', constructor); a-a appears four times here now; might be time to introduce a variable for it--use let. https://codereview.chromium.org/2477713003/diff/80001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/dom/Document.cpp (right): https://codereview.chromium.org/2477713003/diff/80001/third_party/WebKit/Sour... third_party/WebKit/Source/core/dom/Document.cpp:815: bool shouldCreateBuiltin = Maybe *may* create builtin is better? If the options are specified but empty/no is, shouldCreateBuiltin is true. But in practice it may turn around and create an autonomous custom element, or (what happens if "is" is missing and the name isn't a valid custom element name? It looks like we'll call createUndefinedElement which does not sound right.) https://codereview.chromium.org/2477713003/diff/80001/third_party/WebKit/Sour... third_party/WebKit/Source/core/dom/Document.cpp:829: if (element->getCustomElementState() != CustomElementState::Custom) { I'm not sure about this part. Doesn't v0-ish stuff often prevail over V1 at this point?
Description was changed from ========== NOTE: This is behind runtime enabled flag "CustomElementsBuiltin". This patch depends on CR#2446903008 Customized built-in elements can now be created with the document.createElement https://dom.spec.whatwg.org/#dom-document-createelement Syntax: https://html.spec.whatwg.org/multipage/scripting.html#custom-elements-customi... Implemented create element algorithm https://dom.spec.whatwg.org/#concept-create-element Steps 5-7: /core/dom/custom/CustomElement.cpp Will add tests. BUG=648828,657583 ========== to ========== NOTE: This is behind runtime enabled flag "CustomElementsBuiltin". Definition is checked for HTML namespace elements in document.createElement Customized built-in elements can now be created with the document.createElement https://dom.spec.whatwg.org/#dom-document-createelement Syntax: https://html.spec.whatwg.org/multipage/scripting.html#custom-elements-customi... Implemented create element algorithm https://dom.spec.whatwg.org/#concept-create-element Steps 5-7: /core/dom/custom/CustomElement.cpp Will add tests. BUG=648828,657583 ==========
Description was changed from ========== NOTE: This is behind runtime enabled flag "CustomElementsBuiltin". Definition is checked for HTML namespace elements in document.createElement Customized built-in elements can now be created with the document.createElement https://dom.spec.whatwg.org/#dom-document-createelement Syntax: https://html.spec.whatwg.org/multipage/scripting.html#custom-elements-customi... Implemented create element algorithm https://dom.spec.whatwg.org/#concept-create-element Steps 5-7: /core/dom/custom/CustomElement.cpp Will add tests. BUG=648828,657583 ========== to ========== NOTE: This is behind runtime enabled flag "CustomElementsBuiltin". Definition is checked for HTML namespace elements in document.createElement Customized built-in elements can now be created with the document.createElement https://dom.spec.whatwg.org/#dom-document-createelement Syntax: https://html.spec.whatwg.org/multipage/scripting.html#custom-elements-customi... Implemented create element algorithm https://dom.spec.whatwg.org/#concept-create-element Steps 5-7: /core/dom/custom/CustomElement.cpp Added some tests. (Sorry this patch is so big) BUG=648828,657583 ==========
Description was changed from ========== NOTE: This is behind runtime enabled flag "CustomElementsBuiltin". Definition is checked for HTML namespace elements in document.createElement Customized built-in elements can now be created with the document.createElement https://dom.spec.whatwg.org/#dom-document-createelement Syntax: https://html.spec.whatwg.org/multipage/scripting.html#custom-elements-customi... Implemented create element algorithm https://dom.spec.whatwg.org/#concept-create-element Steps 5-7: /core/dom/custom/CustomElement.cpp Added some tests. (Sorry this patch is so big) BUG=648828,657583 ========== to ========== https://dom.spec.whatwg.org/#dom-document-createelement Definition is checked for HTML namespace elements in document.createElement Customized built-in elements can now be created with the document.createElement NOTE: This is behind runtime enabled flag "CustomElementsBuiltin". Syntax: https://html.spec.whatwg.org/multipage/scripting.html#custom-elements-customi... Implemented create element algorithm https://dom.spec.whatwg.org/#concept-create-element Steps 5-7: /core/dom/custom/CustomElement.cpp Added some tests. (Sorry this patch is big) BUG=648828,657583 ==========
On 2016/11/10 at 03:43:09, dominicc wrote: > Good, more comments inline, more tests indicating how v0 and v1 will interact are needed. > > Could you "publish" a comment when you've got a new patch ready to review? It makes it easier to see in the review dashboard there's something to respond to. > > https://codereview.chromium.org/2477713003/diff/80001/third_party/WebKit/Layo... > File third_party/WebKit/LayoutTests/custom-elements/spec/create-element-defined-synchronous.html (right): > > https://codereview.chromium.org/2477713003/diff/80001/third_party/WebKit/Layo... > third_party/WebKit/LayoutTests/custom-elements/spec/create-element-defined-synchronous.html:21: (w, constructor, type) => { > Maybe name this opt_type indicating it is optional? And maybe it should be called opt_tag? > > https://codereview.chromium.org/2477713003/diff/80001/third_party/WebKit/Layo... > third_party/WebKit/LayoutTests/custom-elements/spec/create-element-defined-synchronous.html:23: w.customElements.define('a-a', constructor); > a-a appears four times here now; might be time to introduce a variable for it--use let. > > https://codereview.chromium.org/2477713003/diff/80001/third_party/WebKit/Sour... > File third_party/WebKit/Source/core/dom/Document.cpp (right): > > https://codereview.chromium.org/2477713003/diff/80001/third_party/WebKit/Sour... > third_party/WebKit/Source/core/dom/Document.cpp:815: bool shouldCreateBuiltin = > Maybe *may* create builtin is better? If the options are specified but empty/no is, shouldCreateBuiltin is true. But in practice it may turn around and create an autonomous custom element, or (what happens if "is" is missing and the name isn't a valid custom element name? It looks like we'll call createUndefinedElement which does not sound right.) > > https://codereview.chromium.org/2477713003/diff/80001/third_party/WebKit/Sour... > third_party/WebKit/Source/core/dom/Document.cpp:829: if (element->getCustomElementState() != CustomElementState::Custom) { > I'm not sure about this part. Doesn't v0-ish stuff often prevail over V1 at this point? Thank you, I haven't published a comment yet because I wasn't done with writing tests. I added a definition look-up in Document::createElement. I also changed the order so V1 comes first here, so if we find a definition for V1 we'll use that, but if we don't we'll move onto looking at V0. I'm not sure what happens in defining an element though. I'll change CustomElement::createCustomElementSync to accept a definition tomorrow.
Comments inline. https://codereview.chromium.org/2477713003/diff/120001/third_party/WebKit/Lay... File third_party/WebKit/LayoutTests/custom-elements/spec/create-element.html (right): https://codereview.chromium.org/2477713003/diff/120001/third_party/WebKit/Lay... third_party/WebKit/LayoutTests/custom-elements/spec/create-element.html:18: constructor() { There's no need to write super-only constructors like this, ES provides one if it's not written. https://codereview.chromium.org/2477713003/diff/120001/third_party/WebKit/Lay... third_party/WebKit/LayoutTests/custom-elements/spec/create-element.html:33: setup(w); Why do you need any custom elements for this test? https://codereview.chromium.org/2477713003/diff/120001/third_party/WebKit/Lay... third_party/WebKit/LayoutTests/custom-elements/spec/create-element.html:52: w.customElements.define('b-b', B, {extends: 'div'}); Why not use setup? https://codereview.chromium.org/2477713003/diff/120001/third_party/WebKit/Lay... third_party/WebKit/LayoutTests/custom-elements/spec/create-element.html:56: }, '2. If context object is an HTML document, let localName be converted to ASCII lowercase'); I don't think "is" is a local name. Consider splitting this into two tests. https://codereview.chromium.org/2477713003/diff/120001/third_party/WebKit/Lay... third_party/WebKit/LayoutTests/custom-elements/spec/create-element.html:62: }); These are good test cases. Add a third parameter briefly describing what's happening in each of these. https://codereview.chromium.org/2477713003/diff/120001/third_party/WebKit/Sou... File third_party/WebKit/Source/core/dom/Document.cpp (right): https://codereview.chromium.org/2477713003/diff/120001/third_party/WebKit/Sou... third_party/WebKit/Source/core/dom/Document.cpp:720: bool isV1 = stringOrOptions.isDictionary() || !registrationContext(); This v0, v1 split thing is very tricky. The way you have it here makes sense--for v0, use createElement(string, string); for v1, use createElement(string, dictionary). The downside with that is that authors have to switch from document.register and createElement(string,string) to customElements.define and createElement(string, dictionary) in one go, which will be hard. On the other hand it has many benefits. You can implement the synchronous exception for missing definitions accurately, for example. I think you have made the right decision. I've updated a slide deck describing custom elements stuff to allude to this and when it lands I'll send mail to devrel and some users. In hindsight I'm a bit sad with how the spec for customized built-in elements has turned out; throwing an exception instead of doing upgrade will make them difficult to use. https://codereview.chromium.org/2477713003/diff/120001/third_party/WebKit/Sou... third_party/WebKit/Source/core/dom/Document.cpp:823: // 1. Validate and extract These comments seem incomplete? https://codereview.chromium.org/2477713003/diff/120001/third_party/WebKit/Sou... third_party/WebKit/Source/core/dom/Document.cpp:842: // 3. Let definition be result of lookup up custom element definition Transcribe these carefully.
On 2016/11/15 at 07:39:54, dominicc wrote: > Comments inline. > > https://codereview.chromium.org/2477713003/diff/120001/third_party/WebKit/Lay... > File third_party/WebKit/LayoutTests/custom-elements/spec/create-element.html (right): > > https://codereview.chromium.org/2477713003/diff/120001/third_party/WebKit/Lay... > third_party/WebKit/LayoutTests/custom-elements/spec/create-element.html:18: constructor() { > There's no need to write super-only constructors like this, ES provides one if it's not written. > > https://codereview.chromium.org/2477713003/diff/120001/third_party/WebKit/Lay... > third_party/WebKit/LayoutTests/custom-elements/spec/create-element.html:33: setup(w); > Why do you need any custom elements for this test? > > https://codereview.chromium.org/2477713003/diff/120001/third_party/WebKit/Lay... > third_party/WebKit/LayoutTests/custom-elements/spec/create-element.html:52: w.customElements.define('b-b', B, {extends: 'div'}); > Why not use setup? > > https://codereview.chromium.org/2477713003/diff/120001/third_party/WebKit/Lay... > third_party/WebKit/LayoutTests/custom-elements/spec/create-element.html:56: }, '2. If context object is an HTML document, let localName be converted to ASCII lowercase'); > I don't think "is" is a local name. Consider splitting this into two tests. > > https://codereview.chromium.org/2477713003/diff/120001/third_party/WebKit/Lay... > third_party/WebKit/LayoutTests/custom-elements/spec/create-element.html:62: }); > These are good test cases. > > Add a third parameter briefly describing what's happening in each of these. > > https://codereview.chromium.org/2477713003/diff/120001/third_party/WebKit/Sou... > File third_party/WebKit/Source/core/dom/Document.cpp (right): > > https://codereview.chromium.org/2477713003/diff/120001/third_party/WebKit/Sou... > third_party/WebKit/Source/core/dom/Document.cpp:720: bool isV1 = stringOrOptions.isDictionary() || !registrationContext(); > This v0, v1 split thing is very tricky. > > The way you have it here makes sense--for v0, use createElement(string, string); for v1, use createElement(string, dictionary). > > The downside with that is that authors have to switch from document.register and createElement(string,string) to customElements.define and createElement(string, dictionary) in one go, which will be hard. > > On the other hand it has many benefits. You can implement the synchronous exception for missing definitions accurately, for example. > > I think you have made the right decision. I've updated a slide deck describing custom elements stuff to allude to this and when it lands I'll send mail to devrel and some users. > > In hindsight I'm a bit sad with how the spec for customized built-in elements has turned out; throwing an exception instead of doing upgrade will make them difficult to use. > > https://codereview.chromium.org/2477713003/diff/120001/third_party/WebKit/Sou... > third_party/WebKit/Source/core/dom/Document.cpp:823: // 1. Validate and extract > These comments seem incomplete? > > https://codereview.chromium.org/2477713003/diff/120001/third_party/WebKit/Sou... > third_party/WebKit/Source/core/dom/Document.cpp:842: // 3. Let definition be result of lookup up custom element definition > Transcribe these carefully. PTL, changes made.
More comments inline. https://codereview.chromium.org/2477713003/diff/160001/third_party/WebKit/Sou... File third_party/WebKit/Source/core/dom/Document.cpp (right): https://codereview.chromium.org/2477713003/diff/160001/third_party/WebKit/Sou... third_party/WebKit/Source/core/dom/Document.cpp:746: // 5. If 'is' is non-null and definition is null, throw NotFoundError Could you add a TODO to check this once that web platform issue 608 is resolved? https://github.com/w3c/webcomponents/issues/608 https://codereview.chromium.org/2477713003/diff/160001/third_party/WebKit/Sou... third_party/WebKit/Source/core/dom/Document.cpp:851: if (!definition && !is.isNull()) { I think "is" is leaking out from behind the flag and affecting behavior here? https://codereview.chromium.org/2477713003/diff/160001/third_party/WebKit/Sou... third_party/WebKit/Source/core/dom/Document.cpp:861: bool shouldCreateBuiltin = I think I commented earlier, but shouldCreateBuiltin the *should* part might be too definite. We may get this far and not be creating a built-in, I think?
On 2016/11/17 at 01:36:15, dominicc wrote: > More comments inline. > > https://codereview.chromium.org/2477713003/diff/160001/third_party/WebKit/Sou... > File third_party/WebKit/Source/core/dom/Document.cpp (right): > > https://codereview.chromium.org/2477713003/diff/160001/third_party/WebKit/Sou... > third_party/WebKit/Source/core/dom/Document.cpp:861: bool shouldCreateBuiltin = > I think I commented earlier, but shouldCreateBuiltin the *should* part might be too definite. We may get this far and not be creating a built-in, I think? PTL I made the shouldCreateBuiltin be for creating a V0 or type extension. I also changed it so if the runtime flag is disabled and a dictionary options is provided, it'll be ignored when looking for a custom element definition.
The CQ bit was checked by dominicc@chromium.org to run a CQ dry run
LGTM One comment inline about the TODO. https://codereview.chromium.org/2477713003/diff/180001/third_party/WebKit/Sou... File third_party/WebKit/Source/core/dom/Document.cpp (right): https://codereview.chromium.org/2477713003/diff/180001/third_party/WebKit/Sou... third_party/WebKit/Source/core/dom/Document.cpp:751: // TODO(yurak): https://github.com/w3c/webcomponents/issues/608 In addition to the link to the issue, add some brief prose (no more than one more line) describing this. A good pattern for TODO text is "[what] when [thing]" so someone can quickly know what to change and whether the change is unblocked by evaluating "thing"; in this case "issue ... is closed". In this case the issue may actually be already closed, but the TODO is still OK for the purposes of breaking the patch up.
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was checked by yurak@google.com
The patchset sent to the CQ was uploaded after l-g-t-m from dominicc@chromium.org Link to the patchset: https://codereview.chromium.org/2477713003/#ps200001 (title: "V0-V1 interoperability")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: linux_chromium_asan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
The CQ bit was checked by yurak@google.com
The patchset sent to the CQ was uploaded after l-g-t-m from dominicc@chromium.org Link to the patchset: https://codereview.chromium.org/2477713003/#ps220001 (title: "patch fix")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Message was sent while issue was closed.
Committed patchset #12 (id:220001)
Message was sent while issue was closed.
Description was changed from ========== https://dom.spec.whatwg.org/#dom-document-createelement Definition is checked for HTML namespace elements in document.createElement Customized built-in elements can now be created with the document.createElement NOTE: This is behind runtime enabled flag "CustomElementsBuiltin". Syntax: https://html.spec.whatwg.org/multipage/scripting.html#custom-elements-customi... Implemented create element algorithm https://dom.spec.whatwg.org/#concept-create-element Steps 5-7: /core/dom/custom/CustomElement.cpp Added some tests. (Sorry this patch is big) BUG=648828,657583 ========== to ========== https://dom.spec.whatwg.org/#dom-document-createelement Definition is checked for HTML namespace elements in document.createElement Customized built-in elements can now be created with the document.createElement NOTE: This is behind runtime enabled flag "CustomElementsBuiltin". Syntax: https://html.spec.whatwg.org/multipage/scripting.html#custom-elements-customi... Implemented create element algorithm https://dom.spec.whatwg.org/#concept-create-element Steps 5-7: /core/dom/custom/CustomElement.cpp Added some tests. (Sorry this patch is big) BUG=648828,657583 Committed: https://crrev.com/fe200cd217b99368dbded68a0350d33c552c6a5b Cr-Commit-Position: refs/heads/master@{#433146} ==========
Message was sent while issue was closed.
Patchset 12 (id:??) landed as https://crrev.com/fe200cd217b99368dbded68a0350d33c552c6a5b Cr-Commit-Position: refs/heads/master@{#433146} |