Closed Bug 865544 Opened 7 years ago Closed 7 years ago

Add support for nsIDOMGlobalPropertyInitializer to JS-implemented WebIDL

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla23

People

(Reporter: mccr8, Assigned: mccr8)

References

Details

(Keywords: dev-doc-complete)

Attachments

(2 files, 1 obsolete file)

I might as well split this out from bug 851639.  Should I generate the Init() call for all JS-implemented WebIDL?
Blocks: 850430
The alternative is another extended attribute.
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...
Yeah, that was my thought.  Hopefully nobody who wants to use JS implemented WebIDL has a function named "Init"...
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.
> and pass the window to the constructor

To which constructor?
(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;
> 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 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.
Do we want to reuse nsIDOMGlobalObjectConstructor::constructor for this?
http://mxr.mozilla.org/mozilla-central/source/dom/base/nsDOMClassInfo.cpp#3471
(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.
Attachment #741889 - Attachment is obsolete: true
Attachment #741955 - Flags: review?(bzbarsky)
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]".
Attachment #741958 - Flags: checkin-
Comment on attachment 741955 [details] [diff] [review]
try to QI to GPI for all JS implemented WebIDL

Yes, thank you.
Attachment #741955 - Flags: review?(bzbarsky) → review+
https://hg.mozilla.org/mozilla-central/rev/ca0a9d06bf72
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla23
This needs documenting.
Keywords: dev-doc-needed
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
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.