Fixing custom element type extensions to have correct native type

Fixing custom element type extensions to have correct native type

This is for bug 14190.

Basically the user has to pass the tag name of the native type that the class is using. Dartium already has validation to ensure that the custom class derives from the native class for that tag, this just saves off that type ID so we can apply it later.

Not sure this is the absolute best approach for the problem, alternate approach is to modify DartHTMLElementWrapperFactory to generate classIds rather than wrappers.

BUG=
R=vsm@google.com

Committed: https://src.chromium.org/viewvc/multivm?view=rev&revision=1456

[vsm, 2013-10-18 21:18:14]

https://chromiumcodereview.appspot.com/27769002/diff/32001/Source/bindings/da...
File Source/bindings/dart/DartCustomElementConstructorBuilder.cpp (right):

https://chromiumcodereview.appspot.com/27769002/diff/32001/Source/bindings/da...
Source/bindings/dart/DartCustomElementConstructorBuilder.cpp:51: ,
m_nativeClassId(-1)
We should make an enum for InvalidClassId just to make sure we don't conflict.

https://chromiumcodereview.appspot.com/27769002/diff/32001/Source/bindings/da...
Source/bindings/dart/DartCustomElementConstructorBuilder.cpp:90: if
(Dart_IsNull(nativeElement)) {
Why not combine these two if clauses?  The bodies look the same.

https://chromiumcodereview.appspot.com/27769002/diff/32001/Source/bindings/da...
File Source/bindings/dart/DartCustomElementWrapper.cpp (right):

https://chromiumcodereview.appspot.com/27769002/diff/32001/Source/bindings/da...
Source/bindings/dart/DartCustomElementWrapper.cpp:136:
DartDOMWrapper::writeNativePointer(fallbackWrapper, element,
DartHTMLElement::dartClassId);
Shouldn't the fallback wrapper still be binding->nativeClassId()?  E.g., if we
fail to update a CanvasElement, we still return a base CanvasElement, right?

[blois, 2013-10-18 23:03:40]

https://codereview.chromium.org/27769002/diff/32001/Source/bindings/dart/Dart...
File Source/bindings/dart/DartCustomElementConstructorBuilder.cpp (right):

https://codereview.chromium.org/27769002/diff/32001/Source/bindings/dart/Dart...
Source/bindings/dart/DartCustomElementConstructorBuilder.cpp:51: ,
m_nativeClassId(-1)
On 2013/10/18 21:18:15, vsm wrote:
> We should make an enum for InvalidClassId just to make sure we don't conflict.

Done.

https://codereview.chromium.org/27769002/diff/32001/Source/bindings/dart/Dart...
Source/bindings/dart/DartCustomElementConstructorBuilder.cpp:90: if
(Dart_IsNull(nativeElement)) {
On 2013/10/18 21:18:15, vsm wrote:
> Why not combine these two if clauses?  The bodies look the same.

Done.

https://codereview.chromium.org/27769002/diff/32001/Source/bindings/dart/Dart...
File Source/bindings/dart/DartCustomElementWrapper.cpp (right):

https://codereview.chromium.org/27769002/diff/32001/Source/bindings/dart/Dart...
Source/bindings/dart/DartCustomElementWrapper.cpp:136:
DartDOMWrapper::writeNativePointer(fallbackWrapper, element,
DartHTMLElement::dartClassId);
On 2013/10/18 21:18:15, vsm wrote:
> Shouldn't the fallback wrapper still be binding->nativeClassId()?  E.g., if we
> fail to update a CanvasElement, we still return a base CanvasElement, right?

Done.

[vsm, 2013-10-18 23:16:19]

lgtm

[blois, 2013-10-18 23:43:08]

Committed patchset #2 manually as r1456 (presubmit successful).