387494 - Think about feed:// and protocol handlers in FFx3

Status: RESOLVED WONTFIX

(Firefox Graveyard :: RSS Discovery and Preview, defect, P3)

Description

[Jason Douglas]

- Is it supported?  Does it need to be?
- How does it relate to how feed handlers are registered in FFx2?
- Do we need to line up 3rd party support (Google Reader, Bloglines, My Yahoo!, etc.)?

Comment 1

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

We already support feed://, and it's just part of our feed stuff, so this is WFM.

Comment 2

[Dan Mosedale (:dmosedale, :dmose)]

It's a little more complex than that.  What people currently need to register for is to handle content with a MIME type of application/vnd.mozilla.type.maybe.feed.  This is kinda broken; we need a more standards based solution.  We do currently happen to support feed: protocol handlers locally, and we need to be sure that if we allow remote protocol handlers to register for feed:, they don't break any existing support.  Some technical details here:

http://weblogs.mozillazine.org/ben/archives/010116.html

Comment 3

[Dan Mosedale (:dmosedale, :dmose)]

Re-requesting blocking, based on comment 2.

Comment 4

[cmtalbert]

Yeah, we have some work to do here.

You can take a look at this test.  It attempts to use the "registerContentHandler" API to register the Google Reader as an application to handle feed:// URLs.
http://people.mozilla.org/~ctalbert/test-feed-protocol.html

First, notice that the blue information bar does *not* appear to ask if you want to add Google Reader to the list of applications that can open feed protocols.

Second, if you click on the "test this" link, (and you don't have a default reader setup) you will get the standard "yellow header" feed selection bar across the top of the BBC feed page.  In the drop down on that bar you will not see the application you added.

Here is another test with a non-existent feed reader called "fooReader".  Note that once again, there is no blue information bar, and if you go to the "Firefox Feed Preview" bar, there is no entry for the "fooReader".
http://people.mozilla.org/~ctalbert/test-feed-fooreader.html

I have attached a picture of the lack of the blue information bar and the yellow feed reader chooser bar.

== Expected Behavior ==
I expect to still get the blue information bar asking me whether or not to add "FooReader" to the list of applications that can handle feed URLs.  Once it is added, I expect to be able to select "FooReader" from the drop down on the yellow feed reader chooser bar.

If the reader is *already* in our list of known feed readers, then I expect to see the blue information bar telling me that "Feed Reader X" is already added to the list of feed handlers.  (This is what should happen in the Google Reader case above).

I second the need for this to block FFx 3.

Comment 5

[cmtalbert]

Attachment: The lack of an information bar when encountering a feed handler registration

Comment 6

[cmtalbert]

Attachment: Yellow Feed Reader Chooser Bar picture

Comment 7

[Mike Connor [:mconnor]]

not a hard blocker for M9, will consider a patch if one appears.

Comment 8

[Dan Mosedale (:dmosedale, :dmose)]

I think what we want to do here make registerProtocolHandler for feed: do the exact same thing as registerContentHandler for application/vnd.mozilla.maybe.feed.  Thoughts?

Comment 9

[Phil Ringnalda (:philor)]

Yay for cascading grotesque hacks. feed: was just a hack around people using bad mimetypes and RSS not providing a self-link in feeds so that a local mimetype handler would know where to subscribe, and our internal feed: handling already passes off feed:// URLs as http:// to web handlers, while our content-type handling for local apps turns http:// URLs to feed://, so we might as well turn registerProtocolHandler into registerContentHandler. Do we also want to have removeProtocolHandler("feed", "foo.com") call removeContentHandler()? And, more horrifying, do we want to admit that this goes on in the .idl?

Comment 10

[Dan Mosedale (:dmosedale, :dmose)]

The problem with application/vnd.mozilla.maybe.feed is that it it's not very standards-like.  If we do want to stick with a content handler, we should probably try and get this standardized as something like application/sniffed-possible-feed or some such.  However, last time I poked around with Google, I couldn't actually find a single site that registered one of these handlers, so an alternative might be just to stop supporting external protocol registrations of that and work to see registerProtocolHandler("feed", ...) be the way to go.

If we do end up supporting both a content-type and a protocol handler for this, I suspect the answers to both of your questions should be yes.

Note that we still need to figure out how we really want to make registerContentHandler() work in the general case; my inclination is that it's currently fairly underspecified.  A bit of interesting reading that a former product manager here put together is at <http://wiki.mozilla.org/Firefox3/ContentManagement:Scenarios>.

Comment 11

[Will Guaraldi]

I'd like to work on #400059 which is related to this bug.  Is there any way to have separate protocol types for media feeds as well as text-based feeds?  So then I could shunt text based feeds to a feed reader and media feeds off to Miro or iTunes.

Comment 12

[Dan Mosedale (:dmosedale, :dmose)]

The main reason this bug is still on the table for Firefox 3 at this late date is because Firefox has special builtin knowledge of feed: already, and that happens to mean that registerProtocolHandler("feed", ...) simply doesn't work.

For any new protocol you feel like inventing (e.g. mediafeed:), registerProtocolHandler should work just fine, so I don't think this really creates any problems for experimentation here.

I do agree that users are poorly served by the current state of affairs.  I'm a little unsure that creating a new protocol is necessarily the right fix to this problem, and I don't really have much bandwidth at this point in the release cycle to work through the issue.  I'm certainly willing to listen to proposals, though...

Comment 13

[Florian Quèze [:florian]]

Attachment: patch v1

Comment 14

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 295179 [details] [diff] [review]
patch v1

Looks good to me; be sure to add your name to the license headers.  I would be interested in sayre's thoughts on this approach, maybe switch the review from gavin to him?  Note that since this is in toolkit, unit tests are going to be required.

Comment 15

[Florian Quèze [:florian]]

(In reply to comment #14)

> Note that since this is in toolkit, unit tests are going to be
> required.
> 

We have currently no unit test for register{protocol,content}Handler.  My patch in bug 402788 will add some.  I guess I can just add a line in this patch to test registering a feed protocol handler.

Comment 16

[Robert Sayre]

Comment on attachment 295179 [details] [diff] [review]
patch v1

r+ on the condition that this isn't checked in without an accompanying test.

That test should add/remove via different methods and check for consistency.

Comment 17

[Mike Connor [:mconnor]]

I don't think there's anything here that needs to block at this point...

Comment 18

[Florian Quèze [:florian]]

I'm not working on this, and I suspect this may not even be wanted any more, so I'm resolving as WONTFIX. Feel free to reopen if it still feels needed for some reason.