User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1b1) Gecko/20060710 Firefox/2.0b1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1b1) Gecko/20060710 Firefox/2.0b1 Hi, when I try to subscribe to a news feed using the new option of Firefox 2.0 it will open Thunderbird but it will not subscribe to the feed in Thunderbird. I still have to create the subscribtion by my own. Reproducible: Always Steps to Reproduce: 1. Go to the preview page of a rss feed 2. Try to subscribe to the feed having Thunderbird selected as software for handling rss feeds 3. Actual Results: Thunderbird opens but nothing more happens Expected Results: Thunderbird should have subscribe to the feed without any manual steps

Thunderbird seems to want |thunderbird.exe -mail feed:http://...|, which Firefox doesn't know how to send. I'm not sure whether this is a Firefox issue or a matter of Thunderbird registering itself properly. Either way, I'm going to mark this dependent on bug 339514, since Firefox 2 should be able to work with Thunderbird 1.5 even if Thunderbird 2 somehow fixes this.

I can confirm this with FF 2.0b1 (2006081504) and TB 2.0a1 (2006081504 too). But i don't know -- as Robert -- if this is a firefox issue or a thunderbird issue ...

I just downloaded Firefox 2 beta 2 and tried the same and this is still occurring. I can see this being an issue and this needs to be fixed whether that involves modifying firefox or thunderbird.

me thinks this is Thunderbird feed:// handling.

This appears to work in both the initial-launch and subsequent-launch cases.

Comment on attachment 238991 [details] [diff] [review] Mostly-working, rev. 1 thanks benjamin! Feel free to land this on the branch too.

Does this actually work for anyone but Mac, though? In http://lxr.mozilla.org/mozilla1.8/source/browser/components/feeds/src/FeedConverter.js#352 Fx sticks on a feed: #ifdef XP_MACOSX for Safari compat, but I think everyone else will just be getting "thunderbird.exe http://www.mozilla.org/index.rdf" won't they?

I guess. I don't know what we can/should do about that.

Hmm. On Windows (only, I think), Fx will also include the system default feed reader, where Tb ought to be able to name its own commandline terms. It certainly doesn't seem to succeed, with today's trunk Tb and today's 2.0 Fx, but maybe you're fixing that too with this patch? Other than that, does Tb actually get passed http:// URLs that are anything *but* feeds? Could the feed subscription handler at least try any URL that comes in, and pass it off to whoever if it fails?

I am also getting this problem with the Trunk and I am running Windows. I personally think this should be a blocker bug for Thunderbird 2.0. Does Linux have the same bug?

(In reply to comment #11) > I am also getting this problem with the Trunk and I am running Windows. I > personally think this should be a blocker bug for Thunderbird 2.0. Does Linux > have the same bug? > I also have multiple(2 accounts) RSS accounts with Thunderbird. And when I try to subscribe to a feed through Firefox, I get this message in the error console: Error: [Exception... "'Failure' when calling method: [nsICommandLineHandler::handle]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "<unknown>" data: no] Still would like this nominated for a blocker bug in "Thunderbird 2.0".

*** Bug 355589 has been marked as a duplicate of this bug. ***

this is a Fx bug. Fx does not pass Tb the proper args; if Tb requires \thunderbird.exe -mail feed:%url than that's what has to come across.. since that works fine from the command line. ok, so trying to give browser.feeds.handlers.application a "..\thunderbird.exe -mail feed:" value in prefs.js results in Fx replacing the required command line spaces with %20 literals, and no quoting or escaping i tried made it work. Fx blows up in Feedconverter.js with (NS_ERROR_FILE_NOT_FOUND) due to the required args and their spaces. while Fx doesn't need to know how to pass an rss uri to every external reader, is sure should accept and properly open external apps and respect their required args.

So, this really should have been a blocker bug for Firefox 2.0? Maybe it could be fixed in v2.0.1

I realized, that I no longer get this message: Error: [Exception... "'Failure' when calling method: [nsICommandLineHandler::handle]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "<unknown>" data: no] when I try to export a syndication feed to Thunderbird from "Minefield 3.0a1". Now , I don't get any message in the error console, and Thunderbird doesn't even launch. I also am not fully sure that bug(#339514) would solve all the problems occurring between Firefox and Thunderbird. Several weeks ago, Firefox at least tried to communicate with Thunderbird, but now Firefox doesn't even try to work with Thunderbird.

there's a fix for this here: http://forums.mozillazine.org/viewtopic.php?t=480357

I couldn't get it to work, but I'm using the Thunderbird 3.0a1.

(In reply to comment #18) > I couldn't get it to work, but I'm using the Thunderbird 3.0a1. > the patch allows Fx to be configured to properly start any external reader app according to its args. i used Fx2/Tb2. the patch certainly does not fix the badly flawed Tb subscription code. a single error on an invalid feed eg. will permanently break Tb, requiring its restart to add subsequent (valid) feeds.

So, is it a problem with Firefox? or is it Thunderbird? or is it both? I just find it interesting that Thunderbird (which is one of the most popular Mozilla programs) it seems is almost forgotten. I can't even send e-mail from Minefield to Thunderbird.

(In reply to comment #18) > I couldn't get it to work, but I'm using the Thunderbird 3.0a1. It works for me with TB2 but with TB 3.0a1 only when Thunderbird is not running.

(In reply to comment #21) > (In reply to comment #18) > > I couldn't get it to work, but I'm using the Thunderbird 3.0a1. > > It works for me with TB2 but with TB 3.0a1 only when Thunderbird is not > running. > I have tried every way that is described in those instructions and tried it with Thunderbird closed and open. The result is all the same, Thunderbird can't handle the imported feed. I still get this message Error: [Exception... "'Failure' when calling method: [nsICommandLineHandler::handle]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "<unknown>" data: no] I'm using the latest trunk build of TB on Vista. Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a1) Gecko/20061123 Thunderbird/3.0a1

Scott, since this patch only appears to work on mac I haven't landed it. Feel free to do what you will with it.

I guess this bug didn't make the 2.0 train. So, it should probably be fixed by 3.0? This is a bug that really needs to be fixed so Firefox and Thunderbird can seamlessly integrated.

First, I think it's a bug in Firefox that it doesn't add feed: or feed:// before passing the http url to the user specified RSS client. Firefox does fix the url up correctly for the Mac. I'll file that on Firefox. Thunderbird already knows how to handle feed: urls for subscriptions via the command line. This patch expands that logic by also looking at any http or https url that ends with .rdf or .xml and assumes that url must also be a feed. I leveraged bsmedberg's original patch and moved the logic to the mail default command line handler, this made the feed command line handler obsolete so I removed it as well. Alternatively we could move the logic into the feed command line handler. This is working well for me on Windows. Although it isn't perfect as it won't subscribe you to feed urls that don't have a xml or rdf file extension such as: http://coop.deadsquid.com/?feed=rss2&cat=6 http://feeds.feedburner.com/hecker-mozilla I haven't tried it on the Mac yet. What do you think of this Phil?

I just tried the patch on my thunderbird 3.0a1 (20070328) on Vista. And I couldn't get it to work. I tried it on a atom feed. I still get this error message. Error: [Exception... "'Failure' when calling method: [nsICommandLineHandler::handle]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "<unknown>" data: no] I might of implemented the patch incorrectly. I'll try it tomorrow.

what was the url of your atom feed? Was there referece to a specific file that triggered the JS error?

sorry it was a XML feed. http://www.majorgeeks.com/news.xml There were no other errors.

I still very much want an answer to the second half of comment 10. To have anything happen with https?://, the user would need to have hacked prefs (or had an extension do it), since we ship with network.protocol-handler.expose-all false and no network.protocol-handler.expose.http, and then once they did, what? They'd have an email client that they could use to pass URIs to their default browser?

Hmmm, tb can be registered as the default feed protocol handler on Windows. So you think that should work from Firefox? I can try to figure out why that's not working. I'm not sure what you mean in comment 31. Thunderbird can take http urls via the command line and it loads them into the start page (at least we used to, it's a bug that we aren't doing that right now). This is used for several things including running some automated tests, so we can't always assume that any http url we receive via the command line is a feed subscription.

scott, the Fx bug is 343041. it becomes a larger issue if they want to solve external feed reader subscription generically with protocol registries etc. the Fx patch in comment 17 has been working fine, and i feel it's the only 100% way to make feed subscribing work in all situations from Fx. there's no control over whether external readers register. do all platforms have registries? yet it's unlikely Fx will accept a pref based solution. matthaeus123, in the forum thread in comment 17, there was a user with the exact same error, he solved it with new Fx/Tb profiles.

At least on linux "thunderbird http://mozilla.org" doesn't currently work. If some tests need to do that, maybe we can add some command line flag for them instead (-start-page perhaps?). I'm not sure about the solution in attachment 262723 [details] [diff] [review], I went through my feeds and those criteria would have matched a minority of them. If you choose to go with this, at least check for "feed" "rss" and "atom" anywhere in the url.

(In reply to comment #32) > Thunderbird can take http urls via > the command line and it loads them into the start page Let that be a lesson to me, not to just look at trunk (which does what I describe - a URI gets passed to openURI(), which refuses for anything other than exposed protocols, unlike both branches, where it turns into an argstring that's passed to openWindow(), except when Tb's already open, when it takes the openURI() route). Lest I forget while trying desperately to think of something other than sniffing file extensions in URIs: ^https?.*\.(xml|rdf|atom)$, since the regex in your patch will match mailto:mscott@mozilla.org?subject=Don't%20wanna%20sniff%20.xml

(In reply to comment #33) > scott, the Fx bug is 343041. it becomes a larger issue if they want to solve > external feed reader subscription generically with protocol registries etc. > the Fx patch in comment 17 has been working fine, and i feel it's the only 100% > way to make feed subscribing work in all situations from Fx. there's no > control over whether external readers register. do all platforms have > registries? yet it's unlikely Fx will accept a pref based solution. > > matthaeus123, in the forum thread in comment 17, there was a user with the > exact same error, he solved it with new Fx/Tb profiles. > It didn't solve my problem. I really think that this bug needs to be a high priority on the Thunderbird team's list.

Phil and I were talking about this some more in IRC tonight. We think it's easier to work around this issue in Thunderbird for now. We're going to route all http/https urls that make it to the mail default command line handler over to the feed subscription code (not just feed and http urls that end in .rdf and .xml). Every other cmd line handler (including those implemented by extensions) will get first crack at handling the url. I'm running Bob Clary's spider extension (with the patch in Bug 378942) which takes a cmd line url and verified that it still gets its http url. Furthermore, we don't try to subscribe to the url passed in there.

Are you feeling the pain of touching RSS, yet? Trunk Linux, Tbird already open, it works perfectly. Tbird closed, it opens, but does the "I tried to load that URL as a folder, and failed" thing. Trunk Mac, open or closed, it fails to subscribe and opens a Compose window, and the error console's Error: uncaught exception: [Exception... "Component returned failure code: 0x804b000a [nsIIOService.newURI]" nsresult: "0x804b000a (<unknown>)" location: "JS frame :: chrome://messenger-newsblog/content/Feed.js :: anonymous :: line 36" data: no] makes me think that maybe even though we may *want* feed:// URLs, we don't actually handle them when we get them.

http://mxr.mozilla.org/seamonkey/source/mail/base/content/msgMail3PaneWindow.js#877 thinks that all incoming feed URLs as window.arguments will start with feed:, that should be the Tbird closed on Linux part. http://mxr.mozilla.org/seamonkey/source/mail/extensions/newsblog/js/newsblog.js#139 thinks that feed URLs have the form feed:http://example.org or feed://http://example.org, when in fact they are supposed to be feed:http://example.org or just feed://example.org - we should still support the mistaken feed://http:// format, since a fair number of things point to http://www.brindys.com/winrss/feedformat.html as being *the* format description, but we need to support feed://example.org -> http://example.org, since that's what Firefox will hand us for URLs where the scheme is http, and I suspect that's the Mac brokenness - we turn "feed://www.mozilla.org/news.rdf" into "www.mozilla.org/news.rdf" and then try to treat that schemeless string as a URI.

Well, as it turns out, the Mac problem is partly feed:// vs. feed://http://, which is bug 329501 but fixed here, and mostly bug 304704, where something in the intricate maze of Mac commandline handling turns feed://www.example.org/feed/ into an empty mailto. Still, I'd like to land this on the trunk to bake, while desperately searching for either a clue, or someone clueful, for bug 304704, since this appears to work perfectly with Tb open or closed, with feed://, feed:https://, and http:// URLs, on Linux and Windows, and even works on Mac in the single case of calling ./thunderbird-bin directly with a feed URL with Tb closed.

Comment on attachment 263242 [details] [diff] [review] Two out of three ain't bad But 5.5 out of 6 will be better :)

do you want a review on this, Phil? Or is this going on in an other bug?

Nominating wanted-thunderbird3 to keep it on the radar.

Certainly wanted for 3.

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5 Thunderbird version 2.0.0.14 (20080505) Linux version 2.6.24-17-generic (buildd@crested) (gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)) #1 SMP Thu May 1 13:57:17 UTC 2008 I'm having the same problem.

This is a pretty basic task, and rotten user experience for sure. Bumping to blocking-thunderbird3+.

Honestly. It's only been a year and a half, but I've got no idea how I thought I could get to 2.5 out of 3, only that I must have thought I could manage the fairly worthless case of Mac-while-not-running. Mac commandline handling is insane, at best. Let's land this, which works fine on all the platforms that don't have utterly broken commandline handling, and move on.

Comment on attachment 343864 [details] [diff] [review] Two out of three, v.5 Sorry for the delay on this one, looks good to land on trunk and bake.