- From: <bugzilla@jessica.w3.org>
- Date: Wed, 07 Aug 2013 20:44:11 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22827
Dimitri Glazkov <dglazkov@chromium.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #1 from Dimitri Glazkov <dglazkov@chromium.org> ---
(In reply to comment #0)
> The constructor generation algorithm says
>
> "DOCUMENT [is] the owner document for new custom element"
>
> Then
>
> "Let CONTEXT be the registration context of DOCUMENT"
>
> and later
>
> "If the registration context of ELEMENT's document is different from
> CONTEXT, throw an InvalidStateError and stop."
>
> It is not clear to me how this error could arise, since the owner document
> for the new custom element's registration context is by definition the
> registration context of element's document.
This is meant to describe the situation when a constructor from frame A is
called in frame B. But at the time when constructor runs, element's document is
unknown, so I messed up.
> I think it would be simpler if generated constructors worked like the image
> constructor does, which is:
>
> "The element's document must be the active document of the browsing context
> of the Window object on which the interface object of the invoked
> constructor is found."
>
> This won't exactly work, because the generated constructor is not defined on
> a Window object per se. But something like this would make the
> implementation better--as it is, we have to keep the document the definition
> was registered against alive just to own elements until they can be adopted
> into their ultimate destination.
I can work with this.
https://dvcs.w3.org/hg/webcomponents/rev/9ebeedebe488
WDYT?
--
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Wednesday, 7 August 2013 20:44:12 UTC