Closed Bug 898136 Opened 7 years ago Closed 5 years ago

Remove nsIDOMGlobalObjectConstructor

Categories

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

defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 1089811
mozilla25

People

(Reporter: emk, Assigned: emk)

References

Details

(Keywords: addon-compat)

Attachments

(1 file)

Not used anymore. New APIs should use JS-implemented WebIDL.
Attached patch patchSplinter Review
Attachment #781282 - Flags: review?(mrbkap)
Comment on attachment 781282 [details] [diff] [review]
patch

r=me assuming no extensions are using this. Do we need dev-doc-needed here?
Attachment #781282 - Flags: review?(mrbkap) → review+
Keywords: dev-doc-needed
Keywords: checkin-needed
(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...
Depends on: 900243
https://hg.mozilla.org/mozilla-central/rev/9c6dc3897c17
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla25
(In reply to neil@parkwaycc.co.uk 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
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.
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?)
Whoops, I was confusing it with nsIJSNativeInitializer.
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.
(In reply to neil@parkwaycc.co.uk 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.
This was backed out and apparently never commented as such in the bug...
https://hg.mozilla.org/mozilla-central/rev/c84673c64f39
Missed comment 6. Anyway, better to add a [leave open] to the whiteboard when backing out prior to it even hitting m-c :-)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(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.
(In reply to neil@parkwaycc.co.uk 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.
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.)
Also, site cannot use this interface. Existence check will be covered by bug 898817.
Keywords: site-compat
Bug 1089811 has the latest patch. duping forward.
Status: REOPENED → RESOLVED
Closed: 7 years ago5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1089811
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.