This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 22827 - [Custom]: Confusing condition on documents and registration contexts in constructor invocation
Summary: [Custom]: Confusing condition on documents and registration contexts in const...
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - Component Model (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: Dimitri Glazkov
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 14968
  Show dependency tree / graph
 
Reported: 2013-07-29 04:58 UTC by Dominic Cooney
Modified: 2013-08-08 16:27 UTC (History)
0 users

See Also:

Attachments

Description Dominic Cooney 2013-07-29 04:58:22 UTC 
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.
Comment 1 Dimitri Glazkov 2013-08-07 20:44:11 UTC 
(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?
Comment 2 Dominic Cooney 2013-08-08 08:04:01 UTC 
(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?
Comment 3 Dimitri Glazkov 2013-08-08 16:20:03 UTC 
(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.
Comment 4 Dimitri Glazkov 2013-08-08 16:27:30 UTC 
(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.