898136 - Remove nsIDOMGlobalObjectConstructor

Status: RESOLVED DUPLICATE of bug 1089811

Description

[Masatoshi Kimura [:emk]]

Not used anymore. New APIs should use JS-implemented WebIDL.

Comment 1

[Masatoshi Kimura [:emk]]

https://tbpl.mozilla.org/?tree=Try&rev=5fb95d77afb5

Comment 2

[Masatoshi Kimura [:emk]]

Created attachment 781282 [details] [diff] [review]
patch

Comment 3

[Blake Kaplan (:mrbkap)]

Comment on attachment 781282 [details] [diff] [review]
patch

r=me assuming no extensions are using this. Do we need dev-doc-needed here?

Comment 4

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/9c6dc3897c17

Comment 5

[[e-mail]]

(In reply to Blake Kaplan from comment #3)
> r=me assuming no extensions are using this.

SeaMonkey is using this.

http://mxr.mozilla.org/comm-central/source/suite/feeds/src/FeedWriter.js#1072

Unless you know another way of getting the window object...

Comment 6

[Masatoshi Kimura [:emk]]

Backed out:
https://hg.mozilla.org/integration/mozilla-inbound/rev/c84673c64f39

Comment 7

[Wes Kocher (:KWierso)]

https://hg.mozilla.org/mozilla-central/rev/9c6dc3897c17

Comment 8

[Masatoshi Kimura [:emk]]

(In reply to [e-mail] from comment #5)
> SeaMonkey is using this.
> 
> http://mxr.mozilla.org/comm-central/source/suite/feeds/src/FeedWriter.js#1072
> 
> Unless you know another way of getting the window object...

nsIFeedWriter::Init()?
https://mxr.mozilla.org/mozilla-central/source/browser/components/feeds/src/FeedWriter.js#1126

Comment 9

[[e-mail]]

Let me double-check but I think we ran into some funkiness because we were creating the object from chrome XBL attached to a content page.

Comment 10

[[e-mail]]

I originally thought you were suggesting that we implement nsIFeedWriter, but do you really mean that we should be implementing nsIDOMGlobalPropertyInitializer instead (does that even work for constructors?)

Comment 11

[[e-mail]]

Whoops, I was confusing it with nsIJSNativeInitializer.

Comment 12

[[e-mail]]

Hmm, I guess we can convert the code to be a global property rather than a global constructor, although then it would get created when anyone looked at the property, rather than having to be explicitly created as it is now.

Comment 13

[Masatoshi Kimura [:emk]]

(In reply to [e-mail] from comment #10)
> I originally thought you were suggesting that we implement nsIFeedWriter,
> but do you really mean that we should be implementing
> nsIDOMGlobalPropertyInitializer instead (does that even work for
> constructors?)

I mean that we should convert it to WebIDL bindings if WebIDL-bound objects are available on users of FeedWriter.js. If not available, we will have to wait until bug 890364.
See also bug 851178.

Comment 14

[Ryan VanderMeulen [:RyanVM]]

This was backed out and apparently never commented as such in the bug...
https://hg.mozilla.org/mozilla-central/rev/c84673c64f39

Comment 15

[Ryan VanderMeulen [:RyanVM]]

Missed comment 6. Anyway, better to add a [leave open] to the whiteboard when backing out prior to it even hitting m-c :-)

Comment 16

[[e-mail]]

(In reply to Masatoshi Kimura from comment #13)
> I mean that we should convert it to WebIDL bindings
Are non-libxul components even able to use WebIDL? As I understand it, all of the WebIDL bindings have to be linked into libxul in advance and the contracts hard-coded in.

Comment 17

[Masatoshi Kimura [:emk]]

(In reply to [e-mail] from comment #16)
> (In reply to Masatoshi Kimura from comment #13)
> > I mean that we should convert it to WebIDL bindings
> Are non-libxul components even able to use WebIDL? As I understand it, all
> of the WebIDL bindings have to be linked into libxul in advance and the
> contracts hard-coded in.

Hm, I thought the only requirement for JS-implemented WebIDL was adding FeedWriter.webidl in the Core side. Luckily Firefox and SeaMonkey share the same contract id for the ndIFeedWriter implementation.

Comment 18

[Kohei Yoshino [:kohei]]

Added: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/25/Site_Compatibility

Comment 19

[Masatoshi Kimura [:emk]]

The interface itself has been restored (see comment #6). But "GlobalObjectConstructor" has been removed from the global anyway because of bug 898817. Add-ons and non-Firefox apps will be able to access the interface through Components.interfaces (and it is the documented way. The global "GlobalObjectConstructor" has never been documented.)

Comment 20

[Masatoshi Kimura [:emk]]

Also, site cannot use this interface. Existence check will be covered by bug 898817.

Comment 21

[Masatoshi Kimura [:emk]]

Bug 1089811 has the latest patch. duping forward.