Closed
Bug 144828
Opened 22 years ago
Closed 21 years ago
mailto: does not open default mail client, nav only doesn't have File | Send ... and File | New | Message UI.
Categories
(MailNews Core :: Networking: SMTP, defect)
MailNews Core
Networking: SMTP
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla1.4alpha
People
(Reporter: gregg, Assigned: shliang)
References
()
Details
(Whiteboard: [adt2])
Attachments
(2 files, 1 obsolete file)
23.30 KB,
patch
|
jag+mozilla
:
review+
sspitzer
:
superreview+
sspitzer
:
approval1.4b+
|
Details | Diff | Splinter Review |
2.66 KB,
patch
|
sspitzer
:
superreview+
sspitzer
:
superreview+
sspitzer
:
approval1.4+
|
Details | Diff | Splinter Review |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0rc2) Gecko/20020510 BuildID: 2002051006 GroupWise is my default email client, and I have modified my user.js file to include: user_pref("network.protocol-handler.external.mailto", true); When I click on a mailto: link in Mozilla, nothing happens (mail and news components of Mozilla are not installed). When I click on a mailto link in IE, GroupWise opens (as expected). Reproducible: Always Steps to Reproduce: 1.Start Mozilla 2.Click on mailto: link Actual Results: Nothing happens Expected Results: Mozilla should have opened my default email client, like IE does. I'm tagging this as a major bug, because in order for a good argument to be made to move away from other browsers, there needs to be support for basic features, such as allowing me to choose my own email client, and not being forced to use the Mozilla email application.
WFM [Mozilla 2002051306 (1.0 branch), Windows 2000, Pegasus Mail 4.01], with Pegasus already installed, from a completely fresh install of Mozilla without Mail & Newsgroups, and no PREFS.JS or USER.JS settings changed
Reporter | ||
Comment 2•22 years ago
|
||
Still does not work for me [Mozilla 2002052108 (1.0 branch), Windows NT4sp6, GroupWise 6.0], with GroupWise already installed, from a completely fresh install of Mozilla without Mail & Newsgroups, and no PREFS.JS or USER.JS settings changed. Also tried with the previously mentioned user.js setting changed, still no luck. Tested on three different systems, of the same config.
Severity: major → critical
Comment 3•22 years ago
|
||
This is a new bug. It did not exist in the build I was using previously, which was from sometime in the middle of April 2002.
*** This bug has been marked as a duplicate of 137795 ***
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
sorry. not a dup
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Comment 6•22 years ago
|
||
I see this in Mozilla 1.0 with Eudora 4.3.2 in Windows 2000. Clicking on a mailto brings up Mozilla Mail thank you very much instead of my default mailer, Eudora. In IE, I get Eudora. I know I've reported this before with prior versions, but damn bugzilla, I can never find anything with this system.
Comment 7•22 years ago
|
||
Same bug here, I have an error message stating that no mail conduit is available (or something like that). Seems that it works with retail 1.0 but not with the trunk (I'm using 2002061707 right now) I'm running win2k
Comment 8•22 years ago
|
||
This should definitely be confirmed. I have the same problem with Eudora as my default mailer. This is a very bad problem. Whenever I want to mail someone a web page, a very common thing to do, I have to open it in IE.
Comment 9•22 years ago
|
||
Simple MAPI is only responsible for setting the Windows registry settings to make Mozilla the default mailto handler when the user makes Mozilla as the default mail application. The code that handles mailto and brings up the Compose Window when the user clicks a mailto URL in Mozilla is the mailto handler (nsMailtoUrl) part of the Smtp code. Changing the component to SMTP.
Component: Simple MAPI → Networking: SMTP
Comment 10•22 years ago
|
||
*** This bug has been marked as a duplicate of 56478 ***
Status: NEW → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → DUPLICATE
Comment 11•22 years ago
|
||
Why is this a duplicate of 56478 "Clicking on a mailto: link doesn't bring up a mail client if Mozilla is installed without Mail/News"? In comments 5 and 8 (at least) Mozilla Mail/News is definitely installed.
Reporter | ||
Comment 12•22 years ago
|
||
This is not a duplicate of bug 56478. Bug 56478 is clearly filed under the OS category of Linux, nowhere in my original bug report did I indicate I was using Linux...
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Comment 13•22 years ago
|
||
This bug is also reproducible on Mac OS. Platform should be something other than PC?
Comment 14•22 years ago
|
||
Is this a dup of bug 11459, or is it a regression in the pref user_pref("network.protocol-handler.external.mailto", true); ?
Comment 15•22 years ago
|
||
Evelyn - Here is one of those bugs we were talking about...There is a similar one that is very close to a dup of this one (http://bugzilla.mozilla.org/show_bug.cgi?id=144828) We need to have this fixed for Buffy. Nominating nsbeta1.
Keywords: nsbeta1
Comment 16•22 years ago
|
||
ccing Scott - he and I spoke today
Comment 17•22 years ago
|
||
reassigning to sspitzer.
Comment 18•22 years ago
|
||
I'm using MS Outlook 2002, and it's dumping me into Mozilla Mail as well. This is definitely a must-fix. In fact it's been bothering me for quite a while... :-)
Comment 19•22 years ago
|
||
According to the FAQ at http://www.mozilla.org/start/1.0/faq/mail-news.html#3.3 , you can just say this in user.js: user_pref("network.protocol-handler.external.mailto", true); Does that mean fixing this bug on Mac and Windows is as easy as changing the default preference from false to true?
Reporter | ||
Comment 20•22 years ago
|
||
According to my original report, I already tried this switch. It does not work...
Comment 21•22 years ago
|
||
Here, reproducible always. Mozilla is the default browser OExpress is the default Mail Program. Any mailto: link within mozilla will opoen up the composer window, instead of (as it should) the Oexpress window.
Comment 22•22 years ago
|
||
For those seeing this: what is the value of the windows registry keys [HKEY_CLASSES_ROOT\mailto\shell\open\command] and [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\mailto\shell\open\command]?
Comment 23•22 years ago
|
||
"C:\PROGRA~1\MICROS~3\Office10\OUTLOOK.EXE" -c IPM.Note /m "%1" That's my command. All programs, including phoenix properly handle this. Mozilla does not, and unconditionally launches its own mailer.
Comment 24•22 years ago
|
||
An other thing to check; does the line user_pref("network.protocol-handler.external.mailto", true); get copied into prefs.js? This should happen when you quit mozilla the first time after this line is added to user.js.
Comment 25•22 years ago
|
||
After adding this entry to my prefs.js manually, Mozilla does what it is supposed to. However, I find it strange that Mozilla did not do this on its own....
Comment 26•22 years ago
|
||
So, the problem seems to be that mozilla does not read user.js. Kevin, could you try to add other lines to user.js to check that nothing get transfered to prefs.js? Note that you have to start and shutdown mozilla before the content of user.js get copied to prefs.js.
Comment 27•22 years ago
|
||
Just one more thing to check, make sure you have set up windows to show the extension to all files and that the file is named user.js and not user.js.txt
Comment 28•22 years ago
|
||
Have the same problem, fixed with the hint from comment #19. Mozilla 1.2, default mailer Outlook (XP). This is still a bug though (IMHO) as the tick in Preferences->Mail&Newsgroups should do the trick by itself.
Comment 29•22 years ago
|
||
There is no UI for this setting, that is bug 11459. Is anyone with a correctly named user.js still seeing this?
Comment 30•22 years ago
|
||
*** Bug 183174 has been marked as a duplicate of this bug. ***
Comment 31•22 years ago
|
||
->all; also see this on Mac OS X (eg, where Mail.app is the default mail client).
OS: Windows NT → All
Hardware: PC → All
Comment 32•22 years ago
|
||
sairuh, are you seeing this yourself? I really think this is due to incorrectly named user.js, which can be hard to see since windows (and Mac OS X IIRC) hides some extensions.
Comment 33•22 years ago
|
||
WORKSFORME using user.js on 2002120103/MacOS 9.2.2 + Outlook Express and 2002112907-MachO/MacOS 10.2.1 + Mail.app. I agree with comment 32.
Comment 34•22 years ago
|
||
ah, i'll check that out in a bit...
Comment 35•22 years ago
|
||
WFM with user.js with build 2002120908/WIN2K SP3. I think this is a significant enough issue that it ought to be in the release notes. I would be willing to write up the issue for inclusion, but I need to be pointed in the right direction for who to send it so and for format/style guidance.
Reporter | ||
Comment 36•22 years ago
|
||
Still does not work for me; NT4sp6, Mozilla 1.2.1 (20021130). I've also tried manually adding the below mentioned line to my user.js file with no success: user_pref("network.protocol-handler.external.mailto", true); I've noticed that once the above setting has been added to my user.js file, this setting is automatically added to my prefs.js file after starting and closing Mozilla. In addition, I've double-checked these filenames from a dos window, in order to be absolutely sure they are named correctly. Output of DOS/cmd "dir" command: Volume in drive C is Local_Drive Volume Serial Number is XXXX-XXXX Directory of C:\WINNT\Profiles\testuser\Application Data\Mozilla\Profiles\Test\6oygcjhe.slt 12/10/02 09:50a <DIR> . 12/10/02 09:50a <DIR> .. 12/10/02 09:48a 5,323 bookmarks.html 12/10/02 09:44a <DIR> Cache 12/10/02 09:44a <DIR> chrome 12/10/02 09:50a 765 history.dat 12/10/02 09:48a 6,055 localstore.rdf 02/01/02 04:07p 298 mimeTypes.rdf 11/24/02 07:51a 1,647 panels.rdf 12/10/02 09:50a 0 parent.lock 12/10/02 09:47a 730 prefs.bak 12/10/02 09:48a 792 prefs.js 11/24/02 07:51a 2,071 search.rdf 12/10/02 09:47a 64 user.js 12/10/02 09:48a 1,202,643 XUL.mfl 15 File(s) 1,220,388 bytes 87,099,392 bytes free To answer comment 22: The registry values: [HKEY_CLASSES_ROOT\mailto\shell\open\command] (Default)=C:\Novell\GroupWise\gwmailto.exe /% [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\mailto\shell\open\command] (Default)=C:\Novell\GroupWise\gwmailto.exe /%
Comment 37•22 years ago
|
||
Gregg, can you try to install Mozilla _without_ mailnews and report back what happens when you click on a mailto link. And just to be sure, you have tried to create a new profile?
Reporter | ||
Comment 38•22 years ago
|
||
Actually, I had already done both at the time of my last reply. I first uninstalled Mozilla, then reinstalled 1.2.1, then deleted my existing profile, and used the profile manager to create another one. Now that I think about it; the only thing I didnt do, was delete the c:\program files\mozilla directory structure before reinstalling (just to be sure everything was deleted during the uninstall) I can try that...
Comment 39•22 years ago
|
||
Editing prefs.js doesn't work for me.
Comment 41•22 years ago
|
||
I to have this problem, with one wrinkle. After editing my pref.js file (I do not have a user.js file) to include: user_pref("network.protocol-handler.external.mailto", true); When I click on a mailto: link my Eudora comes up (my default mail client). HOWEVER when I use File -> Send Page, N7 mail client pops up, disregarding my registry and Internet Options settings. I am running WinNT4.0 sp 6 as well.
Comment 42•22 years ago
|
||
Today I installed the entire set up on a Win98 box and can duplicate the issue. Clicking on a mailto link will bring up Eudora, using File -> Send Page will not. It seems as if the issue is not WinNT related.
Comment 43•22 years ago
|
||
see also http://www.mozilla.org/mailnews/altmail/index.html accepting, I hope to get to this for 1.3 final, as it's important nav only users.
Status: NEW → ASSIGNED
Comment 44•22 years ago
|
||
i have a similar problem but the other way round. i have mozilla as my default mail and browser. when i use explorer on a mailto link, netscape 4.61 (which was my primary before mozilla) starts up, and net shows an own mail composing window. it only works properly in mozilla itself.
Comment 45•22 years ago
|
||
updating summary, aiming for 1.3 final
Summary: mailto: does not open default mail client → mailto: does not open default mail client, nav only doesn't have File | Send ... and File | New | Message UI.
Target Milestone: --- → mozilla1.3final
Comment 46•22 years ago
|
||
not going to happen for 1.3 final. now hoping for 1.4 alpha.
Target Milestone: mozilla1.3final → mozilla1.4alpha
Comment 47•21 years ago
|
||
(fixed URL) If this bug has morphed from "mailto:" didn't work right for me to "File | Send <stuff>" does not use "network.protocol-handler.external.mailto", that should really be a new bug. As for editing prefs, I've put up some documentation on prefs, I'd be looking for some feedback, and hopefully it will help other people who want to change this setting (I already learned a couple things about user.js, I've alwyas been a prefs.js hacker)... http://www.mozilla.org/catalog/end-user/customizing/briefprefs.html
URL: http://mailto: → mailto:
Comment 48•21 years ago
|
||
> If this bug has morphed from "mailto:" didn't work right for me to "File|Send > <stuff>" does not use "network.protocol-handler.external.mailto", that should > really be a new bug. There is one already (Don Catanzaro, please take note): Bug 152526. I've been working out the mailto issue today, testing Mozilla 1.3 final on Windows 2000 SP3, plus some similar testing on a Win98SE laptop. 1) The protocol-handler.external pref *was* copied from user.js to prefs.js. I did have a glitch there where I put the "true" in quotes, interpreted as a string; once stored in prefs.js like that, an unquoted version in user.js did not override the prefs.js one; I had to edit prefs.js to fix it. 2) In every case where HKEY_CLASSES_ROOT\mailto\... pointed to an executable *and* the protocol-handler.external.mailto pref was true, Mozilla opened the correct program. I could not duplicate the problems described in Comment 36.
Comment 49•21 years ago
|
||
Following up myself: I am not sure that this bug should be left open, at least without additional information from reporters. I have no problems getting Mozilla to open a different program under Windows, and I understand from extensive reading of other mail-related bugs that the net.p-h.ext.mailto pref works for OSX as well. The same issue under Linux is addressed by Bug 56478. One issue that might be addressed by this bug is whether the preference should have a UI associated with it; and, see also Bug 196798. Windows users who are still seeing this problem: check to be sure that you have a program associated with 'mailto' in the Windows registry. -- Win98: In Windows Explorer, open View|Folder Options. Select the File Types tab. Scroll down to find the entry for "URL(mailto)" (near the bottom of the list); click Edit; select the "open" action; click Edit. -- Win2K: In Windows Explorer, open Tools|Folder Options. Select the File Types tab. Scroll down to find the entry "N/A -- URL(mailto)"; click Advanced; select the "open" action; click Edit. Alternately, in the Registry Editor, locate HKEY_CLASSES_ROOT\mailto\shell\open\command and see what the 'default' value for that key is. Since I want Mozilla as my default mailer, I have this value set to "C:\Program Files\Mozilla\mozilla.exe" -mail "%1" The precise syntax of that command for other mailers is dependent on those programs. I know from testing that Outlook Express will set up this key correctly for itself. (Mozilla does *not* set this key up when it declares itself the default mailer, for which see Bug 96717.)
Reporter | ||
Comment 50•21 years ago
|
||
In regards to comment #49, I am still seeing this with Mozilla 1.3 (Gecko/20030312) on NT4sp6a. Mail/News is not installed, and my registry entry still shows the same values as noted in comment #36. The prefs.js/user.js entry is as follows: user_pref("network.protocol-handler.external.mailto", true); It looks like comments #45 and #46 hint towards a fix in a later Mozilla milestone release...
Comment 51•21 years ago
|
||
ok, I think we just care about: handling mailto: properly and: File | New Message File | Send Page File | Send Link and the context menu stuff. (see mailNavigatorOverlay.xul) when mail is not installed. (build --disable-mailnews) once we get the front end work done, we'll figure out how to properly launch the default mailer, which will be fun. (blizzard already has some ideas for linux.)
Assignee: sspitzer → shliang
Status: ASSIGNED → NEW
Comment 52•21 years ago
|
||
The usual way to do this is to just pass the url to be loaded to a command line handler that knows how to find the right browser and launch it if required. There's also the internal route where you can use the xremoteservice to talk to an already running instance. (mozilla -remote already uses this.) Then you can launch something if it's not running. On recent Red Hat versions we just have a little program called htmlview that passes urls to the "right" browser.
Assignee | ||
Comment 53•21 years ago
|
||
add file|new msg and send link, send image in context menu to nav-only installs
Attachment #122148 -
Flags: review?(sspitzer)
Comment 54•21 years ago
|
||
Comment on attachment 122148 [details] [diff] [review] preliminary patch 1) + var gCanCompose = ("@mozilla.org/messengercompose/composeparams;1" in Components.classes); instead of gCanCompose, something like gHaveIntegratedMailClient; 2) +<!ENTITY newMessageCmd.label "Message"> +<!ENTITY newMessageCmd.accesskey "m"> should be "M", right? 3) +<!ENTITY newCardCmd.label "Address Book Card..."> +<!ENTITY newCardCmd.accesskey "c"> should be "C", right?
Attachment #122148 -
Flags: review?(sspitzer)
Assignee | ||
Comment 55•21 years ago
|
||
Attachment #122148 -
Attachment is obsolete: true
Comment 56•21 years ago
|
||
Comment on attachment 122234 [details] [diff] [review] patch sr/a=sspitzer
Attachment #122234 -
Flags: superreview+
Attachment #122234 -
Flags: approval1.4b+
Comment 57•21 years ago
|
||
Comment on attachment 122234 [details] [diff] [review] patch r=jag
Attachment #122234 -
Flags: review+
Comment 58•21 years ago
|
||
As part of the Nav-only install issue, shouldn't the preference for network.protocol-handler.extern.mailto be set to True by default? (per Bug 196798)
Assignee | ||
Comment 59•21 years ago
|
||
patch checked in
Status: NEW → RESOLVED
Closed: 22 years ago → 21 years ago
Resolution: --- → FIXED
Comment 60•21 years ago
|
||
It's a shame that we did cvs remove and cvs adds here and lost revision history.
Comment 61•21 years ago
|
||
> It's a shame that we did cvs remove and cvs adds here and lost revision history.
leaf might be able to fix that, by hand.
Comment 62•21 years ago
|
||
> As part of the Nav-only install issue, shouldn't the preference for
> network.protocol-handler.extern.mailto
> be set to True by default? (per Bug 196798)
is that needed? I saw shuehan run her fix on windows,
and I don't think she had that.
but if that's the case, maybe we can do is this:
at build time, if we are building --disable-mailnews,
in mozilla/modules/libpref/src/init, add a disable-mailnews.js that *only* gets
built / installed when we don't build mailnews.
network.protocol-handler.extern.mailto can be set to true in disable-mailnews.js.
note, for nav only installs, we have (and need) mailnews.js.
(shuehan, can you confirm?)
the reason is for people who do this:
1) run 4.x (with mail)
2) install mozilla, just the browser
3) migrate the 4.x profile (need mailnews.js to migrate properly)
4) later, install mozilla again, with mail
obviously, if you don't build --disable-mailnews, we don't want to export
disable-mailnews.js
Comment 63•21 years ago
|
||
logged bug #204621 for better linux support, per blizzard. I'm not sure if mac works well or not.
Comment 64•21 years ago
|
||
>> As part of the Nav-only install issue, shouldn't the preference for >> network.protocol-handler.extern.mailto >> be set to True by default? (per Bug 196798) > is that needed? I saw shuehan run her fix on windows, > and I don't think she had that. I am having a lot of trouble getting the 0506 build to behave (due to Bug 204676), but the testing I was able to do indicates that this preference now makes no difference (Windows 98). It appears that in a Navigator-only installation (Messenger not installed), the system mailer will be used for the menu items and for mailto: links; this is as desired and maybe even will fix the problem for the original reporter, who had no luck using the preference to get the browser to handle mailto:'s with his default mail program. You could claim that this fix has also fixed Bug 152526. In a Navigator-plus-Messenger installation, it appears that Messenger will be used for all invocations of the mailer from the browser, even if Messenger is not the default mail program. For those who want to have an alternate primary mailing program, but also to keep Messenger installed for testing or whatever reason, this could be a problem.
Comment 65•21 years ago
|
||
Does mailto: not support &subject= for the send page/image title?
Comment 66•21 years ago
|
||
Neil: mailto:?subject= works fine (for invoking Messenger, Win2K); using the menu items, the subject is not set for Send Image (image context menu), but it is set for Send Page or Send Link (from the File menu) or Send Page (from the page context menu) -- again, for invoking Messenger. For an external mailer, the subject is not being set; and for Send Image, the image is not being attached. I don't think the page is being attached for Send Page, either, but I've got another problem right now where I can't verify that. It's possible the problem of "no attachment" is a problem with the mailer I'm using to test; is there a generic means of specifying an attachment when invoking a mail program? If not, maybe the Send Page and Send Image menu items should *not* be included for non-Messenger mail installations.
Assignee | ||
Comment 67•21 years ago
|
||
add subject to mailto, fix js errors in message view source, forgot to check in contents.rdf
Attachment #122680 -
Flags: superreview?(sspitzer)
Comment 68•21 years ago
|
||
Comment on attachment 122680 [details] [diff] [review] additional patch r/sr/a=sspitzer for 1.4 final. (the tree should be open for that soon.)
Attachment #122680 -
Flags: superreview?(sspitzer)
Attachment #122680 -
Flags: superreview+
Attachment #122680 -
Flags: approval1.4+
Comment 69•21 years ago
|
||
I am now using the 050712 build, which fixed the problem that was interefering with my testing. I am not seeing Send Page menu items in either the context menu or the File menu, in a Navigator-only installation (Win98); I'm not sure, now, if they were available in 0506. File|New|Message, File|Send Link and Send Image (from the image context menu) are all present; the latter two behave as described in comment 66.
Comment 70•21 years ago
|
||
shuehan, could this fix have caused bug #204882?
Assignee | ||
Comment 71•21 years ago
|
||
additional patch checked in
Comment 72•21 years ago
|
||
> I am not seeing Send Page menu items in either the context
> menu or the File menu, in a Navigator-only installation (Win98)
send page isn't implemented, because we don't have a way to send the page to the
external mailer.
Comment 73•21 years ago
|
||
That makes sense; in that case, don't you also need to remove Send Image from the image context menu (as I suggested in comment 66)?
Assignee | ||
Comment 74•21 years ago
|
||
send image will act like send link in that case, and send a link to the image
Comment 75•21 years ago
|
||
per comment 74, i've spun off bug 205061.
Comment 76•21 years ago
|
||
Using trunk build 20030515 on winxp I installed ns7 without mail component and launched Browser then tested these cases and they have passed: 1.) Outlook 2000 set as default mail app Send Link, Send Image and mailto link brought up Outlook compose window. Sent msg = received it. 2.) Outlook Express set as default mail app Send Link, Send Image and mailto link brought up Outlook Express compose window. Sent msg = received it. 3.) Eudora Pro set as default mail app Send Link, Send Image and mailto link brought up Eudora Pro compose window. Sent message = received it. 4.) Migrated a 4.7 profile that had a mail account set up. Send Link, Sent Image and mailto link still brought up Eudora Pro compose window which is OK because NS7 doesn't have the mail component installed. 5.) Installed ns7 with mail component and ran migrated profile from step 4 (answered yes to make mail default. Send Page, Send Link and mail to launched ns7 mail compose window. Mail component functioned correctly. Exit. 6.) Reset Eudora as default mail client and launched ns7 without mail client. Send Link, Sent Image and mailto link still brought up Eudora Pro compose window. I tested this on winxp only all scenarios passed. Those reporting scenarios in this bug using other mail apps as default and other OS's please test your scenarios again with fixed build and update this bug.
Comment 77•21 years ago
|
||
Since my testing of this bug shows it working and I have no response from others who saw this probem, I will verify it as fixed. If there is a scenario that still does not work, please reopen and give specific steps and OS.
Status: RESOLVED → VERIFIED
Comment 78•21 years ago
|
||
The bug <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=183174">183174</a> marked as duplicate of this one still be valid: how to use an other mail client than Mozilla when following the 'mailto' links.
Comment 79•21 years ago
|
||
Re comment 78: that is because bug 183174 really is a dupe of bug 11459.
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•