Think about feed:// and protocol handlers in FFx3

RESOLVED WONTFIX

Status

()

P3
normal
RESOLVED WONTFIX
11 years ago
6 years ago

People

(Reporter: jason, Assigned: florian)

Tracking

Trunk
Firefox 3
Points:
---
Bug Flags:
blocking-firefox3 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [proto] [needs updated patch, checkin])

Attachments

(3 attachments)

(Reporter)

Description

11 years ago
- 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.)?
Flags: blocking-firefox3?
We already support feed://, and it's just part of our feed stuff, so this is WFM.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Flags: blocking-firefox3? → blocking-firefox3-
Resolution: --- → WORKSFORME
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
Status: RESOLVED → REOPENED
Keywords: qawanted
Resolution: WORKSFORME → ---
Re-requesting blocking, based on comment 2.
Flags: blocking-firefox3- → blocking-firefox3?
OS: Mac OS X → All
Hardware: PC → All
Target Milestone: --- → Firefox 3 M9

Comment 4

11 years ago
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.
Keywords: qawanted

Comment 5

11 years ago
Created attachment 283105 [details]
The lack of an information bar when encountering a feed handler registration

Comment 6

11 years ago
Created attachment 283106 [details]
Yellow Feed Reader Chooser Bar picture
Flags: blocking-firefox3? → blocking-firefox3+
not a hard blocker for M9, will consider a patch if one appears.
Target Milestone: Firefox 3 M9 → Firefox 3 M10
Priority: -- → P1

Updated

11 years ago
Target Milestone: Firefox 3 M10 → Firefox 3 M11
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?
Priority: P1 → P3
Whiteboard: [proto]
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?
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

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

Comment 13

11 years ago
Created attachment 295179 [details] [diff] [review]
patch v1
Assignee: dmose → florian
Status: REOPENED → ASSIGNED
Attachment #295179 - Flags: review?(gavin.sharp)
(Assignee)

Updated

11 years ago
Attachment #295179 - Flags: review?(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.
Attachment #295179 - Flags: review?(dmose) → review+
(Assignee)

Comment 15

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

Updated

11 years ago
Attachment #295179 - Flags: review?(gavin.sharp) → review?(sayrer)
Keywords: dev-doc-needed
Whiteboard: [proto] → [proto][needs review sayrer]

Comment 16

11 years ago
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.
Attachment #295179 - Flags: review?(sayrer) → review+
Whiteboard: [proto][needs review sayrer] → [proto] [needs updated patch, checkin]
(Assignee)

Updated

11 years ago
Target Milestone: Firefox 3 beta3 → Firefox 3 beta4
Target Milestone: Firefox 3 beta4 → Firefox 3
I don't think there's anything here that needs to block at this point...
Flags: blocking-firefox3+ → blocking-firefox3-
Version: unspecified → Trunk
(Assignee)

Comment 18

6 years ago
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago6 years ago
Keywords: dev-doc-needed
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.