For some reason, I tought this stuff is already done... If I click on feed:// URIs in Firefox, thunderbird opens open a new message window. I am going to debug this tomorrow, if it turns out this isn't fixable for 1.8, I will disable the feed handling in the mac shell service...

Just a note: From bug 282048 comment 5: "I don't yet handle feed://<some url>, just feed:<some url>."

My reg expression foo is not strong enough. I'm sure someone else can come up with the right foo for: aUrl = aUrl.replace(^feed:/i, ''); feed: needs to really be, feed: followed by 0 or two forward slashes (//) that will allow us to strip out both: feed://http://myfeed.xml and feed:http://myfeed.xml I keep having problems when I try to put two forward slashes in my reg expression. \/\/ doesn't seem to work either.

My reg expression foo is not strong enough to figure out a way to do this in one line so I'm doing it in two. if the string beings with feed:, strip feed: from the url and then if we have two forward slashes left, strip those off too. this means we now work with feed: and feed:// when receiving feed urls from the desktop.

Comment on attachment 193632 [details] [diff] [review] [patch checked in] handle feed:// urls + // feeed://http://somesite/feed.xml s/feeed/feed

Scott, have you tested this on mac (I didn't have a chance, yet). I am pretty sure we have _another_ issue there.

whoops, your right. the comment about not handling feed:// threw me off since I know we didn't have that support yet. re-opening, assigning back to you. On the mac I still see a compose window come up when given either a feed: or a feed:// uri.

OK, the mac command line handling code is a crap and will only get fixed in the 1.9 timeframe; we'll have to only expose the mail part of the default client UI.

This removes the news and feeds part of this UI for 1.5. I'll rework the mac commandline service on the trunk so this isn't necessary there.

i left this in on the trunk as we work on a real solution. Leaving open but moving off the 1.1 radar.

Scott, in the future, I prefer to keep cvs blame usable, thanks.

(In reply to comment #10) > Scott, in the future, I prefer to keep cvs blame usable, thanks. ?

I could check this in myself and keep the log a bit more usable, that's all. :)

Just want to add that I've faced a similar problem in Windows and Linux too! When using Firefox with Livelines extension to pass the feed url to Thunderbird, it does not accept feed://domain.com/abc.xml urls (domain/abc.xml is not a valid RSS feed). It only accepts feed:http://domain.com/abc.xml or feed://http://domain.xml It seems alot of RSS Readers use http as the default, except Thunderbird. Using TB 1.5

Soyapi, file a new bug and assign it to me and I'll take a look. Thanks!

looks like this is slipping to 1.9 per comment 7

> My reg expression foo is not strong enough to figure out a way to do this in > one line so I'm doing it in two. Here is a one-line version: aUrl = aUrl.replace(/^feed:(\/\/)?/,''); The code doesn't seem right, though, at least not according to this spec (I'm not sure whether there is considered authoritative): http://www.25hoursaday.com/draft-obasanjo-feed-URI-scheme-02.html feed://http://somesite/feed.xml (as mentioned in the patch) doesn't look like a valid feed URL. The format is either feed:http://somesite/feed.xml or feed://somesite/feed.xml.

Yup. That, however, isn't this bug - "Mac-only, feed URLs open a compose window" - it's bug 329501, which will actually be fixed by bug 348450 (once I get over my mad about this bug, and just land something that only works on the two platforms I rarely use, and fails on the one I mostly use).

Okay, I know the *what* now, though I'm still unsure about the *how* (to avoid it): If we are not running when a browser launches us with "feed://example.org/feed/", then we wind up with commandline arguments of "-url", "feed://example.org/feed/", "-foreground". Then http://ln-s.net/U7w fails to recognize "-url", and for backward-compat eats both it and the feed: URL. Easy enough to hack around, with an #ifdef XP_MACOSX handleFlagWithParam("url"). If we *are* running, though, we go clattering through toolkit's Mac commandline handling stuff until we fall out in http://ln-s.net/U82 where because of bug 234541 we get the feed: URL passed to messengercompose.xul, our OS X default for browser.chromeURL, which not surprisingly has no idea what to do with it. So far, the closest thing to an idea for dealing with that I've come up with is to instead use hiddenWindow.xul for browser.chromeURL, and give it a window.arguments parser that will open a compose window for mailto:, or pass feed: to a 3-pane.

Filed bug 380163 on fixing toolkit to actually call command-line-handers for commandlines, since I failed to grasp that this Thunderbird bug was Mano's Toolkit bug for that.

Don't think this is a blocker considering bug 348450 will improve things quite a bit, right?

Not really: it would be more accurate to say that there are two bugs: Bug 348450 Can't subscribe to feeds passed from Firefox (Windows & Linux) Bug 304704 Can't subscribe to feeds passed from Firefox (Mac) (But I don't think marking it as a blocker will magically make someone able to figure out how to fix toolkit's commandline handling.)

what's the status of this 4 years old bug? is someone still working on it? i tested with a current nightly trunk build (2010-02-21, new empty profile with just an RSS account created) and i get Warning: unrecognized command line flag -url on the console instead of the feed being subscribed in tb. doesn't look like the fixed1.8 flag has any meaning if it's still not working in 1.9?

see bug 646031. -url is not how to do it.

if the procedure in bug 646031 comment 3 does not work on mac, reopen.

This is the problem because Firefox (tested on 34.0 on Mac OS X) sends an `-url` parameter when subscribing to a feed. So if I navigate to the website with a RSS feed in Firefox, click Bookmarks -> Subscribe to this page and I choose Thunderbird to open it, Thunderbird gets focused, but nothing happens, and in the Console I see the error above. Thunderbird 31.3.0.

So this is a problem because Firefox sends such parameters to the program. The procedure in bug 646031 comment 3 does not help, because the question is how to get or Firefox to send correct parameters, or how to get Thunderbird to accept the parameters Firefox sends.