The default bug view has changed. See this FAQ.

Remove nsIDOMGlobalObjectConstructor

RESOLVED DUPLICATE of bug 1089811

Status

()

Core
DOM
RESOLVED DUPLICATE of bug 1089811
4 years ago
2 years ago

People

(Reporter: emk, Assigned: emk)

Tracking

({addon-compat})

unspecified
mozilla25
addon-compat
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

4 years ago
Not used anymore. New APIs should use JS-implemented WebIDL.
(Assignee)

Comment 1

4 years ago
https://tbpl.mozilla.org/?tree=Try&rev=5fb95d77afb5
(Assignee)

Comment 2

4 years ago
Created attachment 781282 [details] [diff] [review]
patch
(Assignee)

Updated

4 years ago
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+
(Assignee)

Updated

4 years ago
Keywords: dev-doc-needed
(Assignee)

Updated

4 years ago
Keywords: checkin-needed
https://hg.mozilla.org/integration/mozilla-inbound/rev/9c6dc3897c17
Assignee: nobody → VYV03354
Keywords: checkin-needed

Comment 5

4 years ago
(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...
(Assignee)

Comment 6

4 years ago
Backed out:
https://hg.mozilla.org/integration/mozilla-inbound/rev/c84673c64f39
(Assignee)

Updated

4 years ago
Depends on: 900243
https://hg.mozilla.org/mozilla-central/rev/9c6dc3897c17
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla25
(Assignee)

Comment 8

4 years ago
(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

Comment 9

4 years ago
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.
(Assignee)

Comment 13

4 years ago
(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.
(Assignee)

Comment 17

4 years ago
(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.
Added: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/25/Site_Compatibility
Keywords: dev-doc-needed → addon-compat, dev-doc-complete, site-compat
(Assignee)

Comment 19

4 years ago
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.)
Keywords: dev-doc-complete → dev-doc-needed
(Assignee)

Comment 20

4 years ago
Also, site cannot use this interface. Existence check will be covered by bug 898817.
Keywords: site-compat
(Assignee)

Comment 21

2 years ago
Bug 1089811 has the latest patch. duping forward.
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1089811
Keywords: dev-doc-needed
You need to log in before you can comment on or make changes to this bug.