Closed
Bug 2657
Opened 26 years ago
Closed 5 years ago
Intelligent Send preferences should apply to News
Categories
(SeaMonkey :: MailNews: Message Display, enhancement)
SeaMonkey
MailNews: Message Display
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: lchiang, Unassigned)
References
Details
<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.
Updated•26 years ago
|
Assignee: warren → phil
Comment 2•25 years ago
|
||
Dunno how important this is. Sending multipart/alternative to newsgroups doesn't
sound like a good idea.
Updated•25 years ago
|
Assignee: phil → sspitzer
Priority: P3 → P4
Comment 3•25 years ago
|
||
Reassign to sspitzer, cc rhp and ducarroz
Updated•25 years ago
|
Assignee: sspitzer → rhp
Comment 4•25 years ago
|
||
this is something for the compose back end. rhp creates the message, I just
post it.
re-assign to rhp.
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M8
Updated•25 years ago
|
Assignee: rhp → ducarroz
Status: ASSIGNED → NEW
Comment 5•25 years ago
|
||
I think this is more of the interaction between the user and intelligent send
dialogs. Just bounce it back if I'm wrong.
- rhp
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M8 → M9
Comment 6•25 years ago
|
||
move to M9
Updated•25 years ago
|
Target Milestone: M9 → M14
Comment 7•25 years ago
|
||
Moving to M14.
Updated•25 years ago
|
Target Milestone: M14 → M16
Comment 9•25 years ago
|
||
Since this bug is marked P4, moving to M17. If you disagree, please let me know.
Target Milestone: M16 → M17
Comment 12•24 years ago
|
||
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.)
Comment 16•22 years ago
|
||
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.
Updated•20 years ago
|
Product: Browser → Seamonkey
Updated•16 years ago
|
Assignee: ducarroz → mail
Status: ASSIGNED → NEW
Priority: P4 → --
QA Contact: esther
Target Milestone: Future → ---
Comment 17•15 years ago
|
||
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
Status: NEW → UNCONFIRMED
Comment 18•15 years ago
|
||
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
Comment 19•15 years ago
|
||
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
Comment 20•15 years ago
|
||
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
Comment 21•15 years ago
|
||
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
Comment 22•15 years ago
|
||
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
Comment 23•15 years ago
|
||
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 24•5 years ago
|
||
I am not sure whether I understand everything of the function correctly, but
I added "aioe.org" and "de.test" to "Can receive HTML", but nevertheless SM asked me what to to (send as HTML, Plain Text, botz?) when I tried to send my HTML-Mail to "de.test". So it seems to ignore preference. That sourl be " Bug 396395 HTML Mail/News preferences seem to not be applied (when news post is composed in HTML mode using identity of news account, always asked for send format)".
RESOLVED INCOMPLETE due to comment 22
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•