<contents of initial description taken from bugsplat bug 331285> Intelligent Send preferences should apply to News Reporter: Jean-David Beyer, (jdbeyer@exit109.com) Enhancement Request: The following Intellieng Send preference should apply to News "When Sending HTML messages to recipients who are not listed as being listed as able to receive them Convert the message to plain text (may lose some formatting)". It currently apply only to Mail. Currently, when I have Netscape Properties for all newsgroups UNCHECKED the Can receive HTLM messages and I try to post a rich text message, it ignore my pref to convert the message to plain text and prompts me and puts up the Intelligent Send dialog. It should have enough information to know that plain text is what I want. Under Mail, it would use what I have set as my default Formating pref. Note: This behavior occurs on 4.5 RTM builds including the Oct 20.2 Win32 and Oct 13 Linux 2.0 build. This is NOT a regression. This problem also occurs in Dogbert 4.07 and the original release of 4.00. As far as I can tell looking through the old Dogbert specs on Intelligent Send, it does not say if this pref should be applied for News as well as Mail. Reference Dogbert Specs: "Intelligent sending of HTML messages" spec at URL: http://warp.mcom.com/client/dogbert/specs/mail/compose/HTMLmessages.html "New Message (Compose) Window" spec at URL http://warp.mcom.com/client/dogbert/specs/mail/compose/comp.htm "Mail and News Specification" spec at URL: http://warp.mcom.com/client/dogbert/specs/mail/mail2/index.html "Preferences for Dogbert" spec at URL http://warp.mcom.com/client/dogbert/specs/general/prefs/ Steps to reproduce problem: 0) Set the Edit|Preferences|Mail & Newsgroups|Formatting|Message Formatting option => Checked for 'Use HTML editor to compose messages' => Checked for 'When Sending HTML messages to recipients who are not listed as being listed as able to receive them Convert the message to plain text (may lose some formatting)' 1) Subscribe to a newsgroup I was subscribed to News://news/mcom.test 2) Select "Mcom.test" in the folder pane of 3 pane UI 3) Edit|Discussion Group Properties The dialog "Discussion Group Properties" The check box option "Can Receive HTML" should be UNCHECKED. If it is checked, please uncheck it. 4) Close the dialog window. 5) Open a newsgroup 6) Click on the 'New Msg' button off the toolbar A HTML Compose window appears The default recipient type and address is filled in as Newsgroup:'mcom.test' 7) Type in a subject title 8) In the message body, type in some rich text. E.g bold some text. 9) Post the message The Intellient Send dialog appears. It ignored my preference setting for "When Sending HTML messages to recipients who are not listed as being listed as able to receive them Convert the message to plain text" ------- Additional Comments From laurel 10/26/98 13:44 ------- FYI: From day one of 4.0, the Intelligent Send in prefs applied only to mail and was told to me to be that way by design. Not spec'd as such, I bugged ui folks about putting wording in the prefs to indicate it was mail only. (I can't remember if I logged a bug about it or not -- am currently querying bugsplat to see, but queries are taking a long time.) I do know that I have a response to my email to jonas from March of this year addressing the same point -- that he spec wording for the prefs to indicate the html prefs are mail oriented only. He claims in a message dated 3/27/98 addressed to chuang, trudelle, mcmullen, dora and bienvenu and copied to me that he changed the spec to include the word MAIL in the prefs panel. I don't see evidence of that in the last image of the prefs panel in the spec, but below the prefs image is an issue addressing this. Please also note the spec NEVER hit M4/cast in concrete. Anyway, Windows UI properly shows the word MAIL in the formatting prefs panel, Unix and Mac do not.

adding QA Contact to fenella

Dunno how important this is. Sending multipart/alternative to newsgroups doesn't sound like a good idea.

Reassign to sspitzer, cc rhp and ducarroz

this is something for the compose back end. rhp creates the message, I just post it. re-assign to rhp.

I think this is more of the interaction between the user and intelligent send dialogs. Just bounce it back if I'm wrong. - rhp

move to M9

Moving to M14.

I don't think this needs to be fixed for PR1

Since this bug is marked P4, moving to M17. If you disagree, please let me know.

moving to future.

Adding mail3 keyword.

For bug triage team: Yes, this is still an issue. We always Ask what format when posting to newsgroup, even though pref is set to convert to plain text. (Didn't test all options.)

marking nsbeta1-

Assign it to Sheelar

reassign to esther

FWIW, GNKSA says always post text/plain to usenet unless ordered otherwise by the user. It should at least be possible to configure for that behavior, and ideally it should be the default.

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614