Closed
Bug 387494
Opened 16 years ago
Closed 10 years ago
Think about feed:// and protocol handlers in FFx3
Categories
(Firefox Graveyard :: RSS Discovery and Preview, defect, P3)
Firefox Graveyard
RSS Discovery and Preview
Tracking
(Not tracked)
RESOLVED
WONTFIX
Firefox 3
People
(Reporter: jason, Assigned: florian)
Details
(Whiteboard: [proto] [needs updated patch, checkin])
Attachments
(3 files)
- 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?
Comment 1•16 years ago
|
||
We already support feed://, and it's just part of our feed stuff, so this is WFM.
Status: NEW → RESOLVED
Closed: 16 years ago
Flags: blocking-firefox3? → blocking-firefox3-
Resolution: --- → WORKSFORME
Comment 2•16 years ago
|
||
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•16 years ago
|
||
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
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
Updated•16 years ago
|
Flags: blocking-firefox3? → blocking-firefox3+
Comment 7•16 years ago
|
||
not a hard blocker for M9, will consider a patch if one appears.
Target Milestone: Firefox 3 M9 → Firefox 3 M10
Updated•16 years ago
|
Priority: -- → P1
Updated•16 years ago
|
Target Milestone: Firefox 3 M10 → Firefox 3 M11
Comment 8•16 years ago
|
||
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?
Updated•16 years ago
|
Priority: P1 → P3
Updated•16 years ago
|
Whiteboard: [proto]
Comment 9•16 years ago
|
||
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•16 years ago
|
||
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•16 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.
Comment 12•16 years ago
|
||
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•16 years ago
|
||
Assignee: dmose → florian
Status: REOPENED → ASSIGNED
Attachment #295179 -
Flags: review?(gavin.sharp)
Assignee | ||
Updated•16 years ago
|
Attachment #295179 -
Flags: review?(dmose)
Comment 14•16 years ago
|
||
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•16 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•16 years ago
|
Attachment #295179 -
Flags: review?(gavin.sharp) → review?(sayrer)
Updated•16 years ago
|
Keywords: dev-doc-needed
Whiteboard: [proto] → [proto][needs review sayrer]
Comment 16•16 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+
Updated•16 years ago
|
Whiteboard: [proto][needs review sayrer] → [proto] [needs updated patch, checkin]
Assignee | ||
Updated•16 years ago
|
Target Milestone: Firefox 3 beta3 → Firefox 3 beta4
Updated•16 years ago
|
Target Milestone: Firefox 3 beta4 → Firefox 3
Comment 17•15 years ago
|
||
I don't think there's anything here that needs to block at this point...
Flags: blocking-firefox3+ → blocking-firefox3-
![]() |
||
Updated•15 years ago
|
Version: unspecified → Trunk
Assignee | ||
Comment 18•10 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
Closed: 16 years ago → 10 years ago
Keywords: dev-doc-needed
Resolution: --- → WONTFIX
Updated•5 years ago
|
Product: Firefox → Firefox Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•