So SetVerbose(true) doesn't do what we expect in all cases?

I guess we should re-review this and come up with a standard way to "report the exception"
https://html.spec.whatwg.org/multipage/webappapis.html#report-the-exception
and use it everywhere.

IIUC this should be cross-function of DOM and binding?

Looks like you're fixing another case in
https://codereview.chromium.org/2161003002/
and applying the same fix to this code path should fix this too. Can you take a look?

Side note: When I put the "script" in "body" instead of "head". The innerHTML is well updated. (I know now it's not permitted either but I wanted to signal it,  reason why I suspected a bug.) 

I'm working on the case where define happens before the <test-v1> element is parsed right now.

If you move the script tag after <test-v1>, then the behavior you are seeing is correct and working as intended:

In that case, when the parser encounters test-v1, there is no definition for it. The parser does not wait for one; it creates the element and continues to set children ('Avant') on that node, etc.

When you call define after that point the definition is "upgraded." This is a distinct operation from "creating" the element. Although both "creation" and "upgrade" run the element's constructor, the restrictions on what they can do are different.

dava@, if you find not easy to work on this, please assign back to me. If this is on your queue, that's fine.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8b406045bb585b6a4bc7808d15df7070ba6e93ca

commit 8b406045bb585b6a4bc7808d15df7070ba6e93ca
Author: kojii <kojii@chromium.org>
Date: Mon Aug 22 08:34:26 2016

Fix "report the exception" in Custom Elements V1

There are 2 places the spec uses "report the exception"[1]:

1. The document parser invokes constructors synchronously.
2. Upgrade.

Currently Blink has 2 different code paths for each, and each has
different issues:
1. The synchronous constructor uses SetVerbose(true), which works for
   thrown exceptions, but ExceptionState::throwIfNeeded() only puts
   the exception into pending exceptions, which will be cleared when
   TryCatch scope exits.
2. Upgrade fires error events and calls
   ExecutionContext::reportException() to avoid it, but it always uses
   NotSharableCrossOrigin. This works in run-layout-test where the
   origin has m_unversalAccess, but not in, for instance, file URL.

This patch unifies the 2 code paths.

[1] https://html.spec.whatwg.org/multipage/webappapis.html#report-the-exception

BUG= 632940 

Review-Url: https://codereview.chromium.org/2244203002
Cr-Commit-Position: refs/heads/master@{#413421}

[add] https://crrev.com/8b406045bb585b6a4bc7808d15df7070ba6e93ca/third_party/WebKit/LayoutTests/custom-elements/spec/report-the-exception.html
[modify] https://crrev.com/8b406045bb585b6a4bc7808d15df7070ba6e93ca/third_party/WebKit/Source/bindings/core/v8/ExceptionState.h
[modify] https://crrev.com/8b406045bb585b6a4bc7808d15df7070ba6e93ca/third_party/WebKit/Source/bindings/core/v8/ScriptCustomElementDefinition.cpp
[modify] https://crrev.com/8b406045bb585b6a4bc7808d15df7070ba6e93ca/third_party/WebKit/Source/bindings/core/v8/ScriptCustomElementDefinition.h
[modify] https://crrev.com/8b406045bb585b6a4bc7808d15df7070ba6e93ca/third_party/WebKit/Source/bindings/core/v8/V8ScriptRunner.cpp
[modify] https://crrev.com/8b406045bb585b6a4bc7808d15df7070ba6e93ca/third_party/WebKit/Source/bindings/core/v8/V8ScriptRunner.h

Let's say fixed, I'll open another if the spec goes differently.