Andrew McCreight [:mccr8] Assignee
	Description • 11 years ago

I might as well split this out from bug 851639.  Should I generate the Init() call for all JS-implemented WebIDL?

	Andrew McCreight [:mccr8] Assignee
	Comment 1 • 11 years ago

The alternative is another extended attribute.

	Boris Zbarsky [:bzbarsky]
	Comment 2 • 11 years ago

I think QI followed by Init() if the QI succeeds is reasonable for all JS-implemented stuff.

Another option is to just declare that there's some magic name we always call into and shim it into the callback part of the codegen so we can just do a function call on mImpl and not require QI and such.  But since we're relying on xpconnect for this stuff for now, might as well just keep using it...

	Andrew McCreight [:mccr8] Assignee
	Comment 3 • 11 years ago

Yeah, that was my thought.  Hopefully nobody who wants to use JS implemented WebIDL has a function named "Init"...

	Reuben Morais [:reuben]
	Comment 4 • 11 years ago

Why not [NavigatorProperty] and pass the window to the constructor? That's more explicit (easy to not know about a init function having additional meaning), and would allow me to ignore nsIDOMGlboalPropertyInitializer entirely.

	Boris Zbarsky [:bzbarsky]
	Comment 5 • 11 years ago

> and pass the window to the constructor

To which constructor?

	Reuben Morais [:reuben]
	Comment 6 • 11 years ago

(In reply to Boris Zbarsky (:bz) from comment #5)
> > and pass the window to the constructor
> 
> To which constructor?

Uh, JavaScript semantics…

[NavigatorProperty] interface Foo {}

function Foo(aWindow) {} // <- this thing
Foo.prototype = etc;

	Boris Zbarsky [:bzbarsky]
	Comment 7 • 11 years ago

> function Foo(aWindow) {} // <- this thing

Ah, so the problem is that right now the chrome-side object is created via createInstance.  Which doesn't allow passing any arguments, sadly.

	Jan-Ivar Bruaroey [:jib] (needinfo? me)
	Comment 8 • 11 years ago

> I think QI followed by Init() if the QI succeeds is reasonable for all
> JS-implemented stuff.

There are relatively few JS-uses so far, right? And we can presumably optimize later.

	Jan-Ivar Bruaroey [:jib] (needinfo? me)
	Comment 9 • 11 years ago

Do we want to reuse nsIDOMGlobalObjectConstructor::constructor for this?
http://mxr.mozilla.org/mozilla-central/source/dom/base/nsDOMClassInfo.cpp#3471

	Reuben Morais [:reuben]
	Comment 10 • 11 years ago

(In reply to Boris Zbarsky (:bz) from comment #7)
> > function Foo(aWindow) {} // <- this thing
> 
> Ah, so the problem is that right now the chrome-side object is created via
> createInstance.  Which doesn't allow passing any arguments, sadly.

I see. Well, init works just as well for me. I still would rather have the extended attribute, but it doesn't matter that much. Thanks for working on these so quickly.

	Andrew McCreight [:mccr8] Assignee
	Comment 13 • 11 years ago

Tested with this code:
  var foo = new MyNumber();
  var num1 = foo.value;
  foo.value = 200;
  var num2 = foo.value;
  var num3 = foo.doubleValue();
  alert(num1 + " !!! " + num2 + " !!! " + num3 + foo.win);

This ends up alerting "1024 !!! 200 !!! 400This is aWindow:[object Window]".

	Boris Zbarsky [:bzbarsky]
	Comment 14 • 11 years ago

Comment on attachment 741955 [details] [diff] [review]
try to QI to GPI for all JS implemented WebIDL

Yes, thank you.

	Andrew McCreight [:mccr8] Assignee
	Comment 15 • 11 years ago

https://hg.mozilla.org/integration/mozilla-inbound/rev/ca0a9d06bf72

	Ryan VanderMeulen [:RyanVM]
	Comment 16 • 11 years ago

https://hg.mozilla.org/mozilla-central/rev/ca0a9d06bf72

	Boris Zbarsky [:bzbarsky]
	Comment 17 • 11 years ago

This needs documenting.

	Andrew McCreight [:mccr8] Assignee
	Comment 18 • 11 years ago

Documented.

"The WebIDL constructor invocation will first create your object.  If the XPCOM component implements nsIDOMGlobalPropertyInitializer, then init will be invoked on the object, passing the window to it.  The init method should not return anything."

https://developer.mozilla.org/en-US/docs/Mozilla/WebIDL_bindings