Fix upgrading built-in custom elements

third_party/WebKit/Source/core/dom/Element.cpp

Index: third_party/WebKit/Source/core/dom/Element.cpp
diff --git a/third_party/WebKit/Source/core/dom/Element.cpp b/third_party/WebKit/Source/core/dom/Element.cpp
index 6468370fc3edd92e486b70d643012424f9a4c0d2..6ec1f3374caada57a8c90bc99c71b06ec496affa 100644
--- a/third_party/WebKit/Source/core/dom/Element.cpp
+++ b/third_party/WebKit/Source/core/dom/Element.cpp
@@ -1447,8 +1447,14 @@ inline void Element::AttributeChangedFromParserOrByCloning(
     const QualifiedName& name,
     const AtomicString& new_value,
     AttributeModificationReason reason) {
-  if (name == isAttr)
+  if (name == isAttr) {
     V0CustomElementRegistrationContext::SetTypeExtension(this, new_value);
+    if (RuntimeEnabledFeatures::CustomElementsBuiltinEnabled() &&

[dominicc (has gone to gerrit), 2017/06/26 03:03:19]

I thought the timing of processing these was different for customized built-in
elements in V1. Can you put a link to the spec algorithm and note which step
does this?

[Anton Obzhirov, 2017/06/27 19:19:00]

Well it is wrong place to set the state, you are right.

The state is supposed to be set to 'undefined' for new element
if 'is' is not null and definition is null.
See https://dom.spec.whatwg.org/#concept-create-element,
7.3. If namespace is the HTML namespace, and either localName is a valid custom
element name or is is non-null, then set result’s custom element state to
"undefined".

So I think the problem is really in HTMLElementFactory::createHTMLElement so it
doesn't create built-in element through CustomElement::CreateCustomElementSync
API. I will make the changes.

+        GetCustomElementState() == CustomElementState::kUncustomized) {
+      SetCustomElementState(CustomElementState::kUndefined);
+    }
+  }
+
   AttributeChanged(
       AttributeModificationParams(name, g_null_atom, new_value, reason));
 }