22827 2013-07-29 04:58:22 +0000 [Custom]: Confusing condition on documents and registration contexts in constructor invocation 2013-08-08 16:27:30 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Component Model unspecified PC Linux RESOLVED FIXED P2 normal --- 14968 1 dominicc dglazkov public-webapps-bugzilla oldest_to_newest 91369 0 dominicc 2013-07-29 04:58:22 +0000 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. 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. 91743 1 dglazkov 2013-08-07 20:44:11 +0000 (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? 91778 2 dominicc 2013-08-08 08:04:01 +0000 (In reply to comment #1) > https://dvcs.w3.org/hg/webcomponents/rev/9ebeedebe488 > > WDYT? I think it is implementable. It seems draconian--why not just let the constructor run, but create an element in the browsing context's document? 91796 3 dglazkov 2013-08-08 16:20:03 +0000 (In reply to comment #2) > (In reply to comment #1) > > https://dvcs.w3.org/hg/webcomponents/rev/9ebeedebe488 > > > > WDYT? > > I think it is implementable. It seems draconian--why not just let the > constructor run, but create an element in the browsing context's document? That's a good question. I guess the original intent was to protect the user from creating scripting context entanglements, but I think you're asking if this is too nanny-state of us. 91799 4 dglazkov 2013-08-08 16:27:30 +0000 (In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > https://dvcs.w3.org/hg/webcomponents/rev/9ebeedebe488 > > > > > > WDYT? > > > > I think it is implementable. It seems draconian--why not just let the > > constructor run, but create an element in the browsing context's document? Poured this comment into bug 20488.