Comment 1 Masatoshi Kimura [:emk] 2013-07-25 14:13:58 PDT

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

Comment 2 Masatoshi Kimura [:emk] 2013-07-25 16:11:59 PDT

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

Comment 3 Blake Kaplan (:mrbkap) 2013-07-30 12:02:56 PDT

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] 2013-07-31 06:31:39 PDT

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

Comment 5 neil@parkwaycc.co.uk 2013-07-31 08:56:01 PDT

(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] 2013-07-31 15:32:14 PDT

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

Comment 7 Wes Kocher (:KWierso) 2013-07-31 17:52:05 PDT

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

Comment 8 Masatoshi Kimura [:emk] 2013-07-31 22:18:08 PDT

(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 neil@parkwaycc.co.uk 2013-08-01 02:55:01 PDT

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 neil@parkwaycc.co.uk 2013-08-01 03:01:22 PDT

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 neil@parkwaycc.co.uk 2013-08-01 03:32:48 PDT

Whoops, I was confusing it with nsIJSNativeInitializer.

Comment 12 neil@parkwaycc.co.uk 2013-08-01 03:50:56 PDT

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] 2013-08-01 07:44:08 PDT

(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.

Comment 14 Ryan VanderMeulen [:RyanVM] 2013-08-01 13:47:58 PDT

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] 2013-08-01 13:49:28 PDT

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 neil@parkwaycc.co.uk 2013-08-01 15:52:52 PDT

(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] 2013-08-01 18:00:47 PDT

(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.

Comment 18 Kohei Yoshino [:kohei] 2013-08-03 21:10:58 PDT

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

Comment 19 Masatoshi Kimura [:emk] 2013-08-04 15:56:55 PDT

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] 2013-08-04 15:59:07 PDT

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

Comment 21 Masatoshi Kimura [:emk] 2014-10-29 19:41:23 PDT

Bug 1089811 has the latest patch. duping forward.

*** This bug has been marked as a duplicate of bug 1089811 ***