In Mozilla 1.0 thru 1.4, this command string: mozilla -mail mailto:email@example.com would open a compose window with the mailto: fields loaded into their respective window fields. No other window (e.g. browser or mail/news) would be opened. As of 1.5RC1 (at the latest) and perhaps earlier, and carrying over to 1.6a, that command string ignores the URL and behaves exactly as mozilla -mail which is to say, it opens the mail/news window. The command string mozilla mailto:firstname.lastname@example.org opens both a browser window and a compose window, and so is unsuitable. Since the -compose switch doesn't process a URL in the command line (and hasn't for quite some time), there is now no way to get external programs to launch a Mozilla compose window, short of breaking down the URL parts into the argument to -compose (documented at http://www.mozilla.org/docs/command-line-args.html ) I'm marking this a regression, but personally, I'd rather see bug 209403 fixed instead; it makes far more sense for the -compose switch to process the URL than the -mail switch. I'm also calling it 'major' because this is a loss of functionality: there is no viable workaround. Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030916 Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20030923
This is the result of a checkin on July 12 -- revision 1.41 of nsMessengerBootstrap.cpp. The checkin comment is: -mail command line handler CAN handle args. Set this to true. This means you can now do: mozilla.exe -mail news://<news server> and it will work. This also means that clicking on news and snews urls in a browser will do the right thing for thunderbird. Over to mailnews, since this is a pure mailnews issue.
Assignee: law → sspitzer
Component: XP Apps: Cmd-line Features → Composition
Product: Browser → MailNews
QA Contact: sairuh → esther
Requesting a block on 1.5.
OK, I've found a workaround: mozilla -browser mailto:email@example.com Works the same as the -mail switch used to; does not open a browser window (!). It does open the 'ghost' window described in bug 204752. May I suggest that this behavior is highly counterintuitive? It seems to me that the -browser switch should always result in a browser window, the -mail switch should always result in a mail/news window, and the -compose switch should always result in a compose window; then, if the URL is pertinenent to the window type, that window should process the URL, otherwise, a window pertinent to the URL should also be opened.
Another situation that used to work, and can now be worked around: It's possible to get a halfway-decent association to .EML files by loading them into Mozilla with a file:// URL. I used this command string in Windows: mozilla.exe -mail "file:///%1" This no longer works, but again, substituting -browser for -mail does the job. The actual window that displays in this case is not a standalone message window, nor is it strictly a browser window -- it's more like a popup window (no status bar, address bar, menus) but contains the message as it would be displayed within a regular browser window.
Mozilla doesn't seem to know how to open URLs from the command line, the best it can do is to forward them to a ghost browser window :-/
*** Bug 228009 has been marked as a duplicate of this bug. ***
You know Mike. thunderbird -compose mailto:firstname.lastname@example.org does work it just doesn't work in the suite. I bet the following thunderbird hack is why this works: http://lxr.mozilla.org/seamonkey/source/xpfe/appshell/src/nsAppShellService.cpp#1134 Not sure yet how to fix this the right way. But we'll want a generic solution that works for seamonkey too.
Assignee: sspitzer → mscott
Target Milestone: --- → mozilla1.7beta
For what it's worth, it seems that this bug still exists in version 1.7 beta. I am using nightly build 20040421, running on Windows XP SP1. From the windows command line, I type "mozilla -mail mailto:email@example.com". A standard Mozilla Mail/News window opens. I do NOT get a message composition window with the proper URL filled in, as I would expect to get. It also does not work using the "mailto://firstname.lastname@example.org" URL format (with the slashes, instead of just a colon). Closely related (duplicate?) bugs that I've found are: 236774 209403 235961 As someone in one of those reports pointed out, this bug means that there is NO way to click on a mailto link in an external browser and have Mozilla Mail/News respond appropriately. I hope this can be fixed soon. Thanks!
(In reply to comment #8) > For what it's worth, it seems that this bug still exists in version 1.7 beta. Unless someone marks it Resolved in some way, the continued existence of this, or any, bug is not worth commenting on. > bug 236774 If that bug is fixed, this bug is moot. -compose is obviously the better solution. Unfortunately, Scott is busy with Thunderbird (which already has this fix in place). > bug 235961 That's an install issue which requires either 236774 or this bug to be fixed first. > As someone in one of those reports pointed out, this bug means that there > is NO way to click on a mailto link in an external browser and have Mozilla > Mail/News respond appropriately. The workaround is in comment 4.
Mike I just checked in the seamonkey code to make the suite's compose window handle mailto urls as an argument. (trunk checkin)
The patch checked in for bug 236774 does indeed do the job. I no longer care if -mail parses URLs, so I'm going to WontFix this bug.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → WONTFIX
*** Bug 244196 has been marked as a duplicate of this bug. ***
-compose not longer handles mailto-URLs, so we again don't have any way to send mailto:-URLs to mozilla. I vote for either reopening this one and setting Bug 236774 to "wontfix" or fixing Bug 236774 *and* updating the documentation: http://www.mozilla.org/docs/command-line-args.html
Comment 13 was correct for a short while, but whatever the problem was, was fixed. 1.8 builds have been using -compose correctly.
*** Bug 290745 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.