340179 - Implement Web Applications 1.0 "registerContentHandler"

Status: RESOLVED FIXED

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

Description

[Ben Goodger (use ben at mozilla dot org for email)]

To allow other web based feed providers to register to show up in the set of choices, we need to implement registerContentHandler. See URI for details.

Comment 1

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: patch

This adds a nsIDOMClientInformation interface... also a nsIWebContentHandlerRegistrar interface & contract id that a component elsewhere has to implement... and makes nsNavigator implement the ClientInformation interface. 

I'm not so hot on the location of nsIWebContentHandlerRegistrar in the source repository, but it was the best I could think of.

Comment 2

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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

This is missing the actual nsIWebContentHandlerRegistrar implementation. Is that being written in another bug or did you diff the wrong directories?

Or is the idea that that part will be handled by an extension?

r=me on the parts that are here though.

Comment 3

[Ben Goodger (use ben at mozilla dot org for email)]

It is being implemented in another directory, right now browser/components/feeds, but I'll move it to toolkit once it begins to handle more than just feed types (probably in Firefox 3.0)

Need to circle around with Hixie once mroe and then I'll land this. 

Thanks for the review!

Comment 4

[Darin Fisher]

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

sr=darin

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

Please land this on trunk, let bake, and request approval-1.8.1 once it's cooled.

Comment 6

[Boris Zbarsky [:bzbarsky]]

So I have a few questions:

1)  Could we add comments to the new interfaces either explaining what the
    methods do or pointing to the spec that explains it?
2)  Is there a reason we don't implement the MUST about URIs not containing
    '%s' from the spec?
3)  This contract is expected to be implemented by embeddors, right?  Do we
    want to use the "embeddor.implemented" thing we were going to use as a
    convention for such things at some point (e.g. "@mozilla.org/embeddor.implemented/bookmark-charset-resolver;1" is an example.
    We should probably consider creating a CID file for content things like
    this too...

Comment 7

[Ben Goodger (use ben at mozilla dot org for email)]

bz-

How about: 
"@mozilla.org/embeddor.implemented/web-content-handler-registrar;1" ?

I'll make a follow on patch.

As far as processing of the parameters themselves, I had delegated that to the implementation (in browser/). Do you think that should be brought in here? Otherwise I can add a note to the nsIWebContentHandlerRegistrar interface stipulating that the implementor must do this. 

Comment 8

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I thought the idea was that the interface was implenented by content in browser/? I.e. that no extensions or embeddors were involved in this?

Comment 9

[Ben Goodger (use ben at mozilla dot org for email)]

Jonas, Camino may wish to implement this too, depending on how they want to handle feeds. 

Comment 10

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: patch for branch, incorporating contract id and comments

Comment 11

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: update for the trunk changing contract id and comments

Comment 12

[Darin Fisher]

Comment on attachment 228244 [details] [diff] [review]
patch for branch, incorporating contract id and comments

a=darin on behalf of drivers

Comment 13

[Ben Goodger (use ben at mozilla dot org for email)]

fixed-on-trunk, fixed-1.8-branch