Closed
Bug 23582
Opened 25 years ago
Closed 16 years ago
Better prefs for text enhancement
Categories
(MailNews Core :: Backend, defect, P4)
MailNews Core
Backend
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: sspitzer, Assigned: BenB)
References
Details
(Keywords: polish)
Attachments
(5 files)
benb recently fix the "sending emoticons" problem. bug #23330
I've turned my comments from that bug into a this bug, for discussion
we are now in a state where:
1) we always convert urls on send. at first, this didn't make sense, since
mozilla, when viewing a message, would convert urls to html links. but doing it
this way is good, for other mail applications who don't do the conversion from
url to href html. one could argue that we shouldn't do this, since
a) it modifies the original message. I don't mind modifying messages from
rfc/822 to html at display time, but modifying on send is a little scary.
b) converting urls hrefs at display time is a "feature" of mozilla, if another
mailer doesn't do it, that would be a reason to switch to mozilla.
2) we never convert emoticons on send, which makes sense, since other mailers
won't have the chrome:// urls to our gifs. we do this on decoding. this is the
original bug, and appears fixed now.
3) based on prefs, we convert structs to html. again, see point 1. we are
modifying
4) if we stick with how it is, the ui for the convert struct pref has to be
changed to reflect that the pref is not only a view message pref, but a send
pref, too.
Assignee | ||
Updated•25 years ago
|
Whiteboard: Waiting for pref decision
Assignee | ||
Comment 1•25 years ago
|
||
Seth,
I'm well aware of this issue. In fact, I started a thread on .mail-news
("Conversion Prefs", <news://news.mozilla.org/385045E0.BCCD1743@bucksch.org>)
asking for suggestions.
I assumed you read the thread and decided not to address that issue for now,
because the code before my fix used the same prefs for displaying and sending,
too.
The interface of the converter is designed to add such prefs easily, the caller
just has to query other prefs and pass them as flags to my function.
But before we fix this, I suggest we make a final decision about which prefs
we need. Please reply to my post (see above) for that.
> 1) we always convert urls on send. at first, this didn't make sense, since
> mozilla, when viewing a message, would convert urls to html links.
URLs can only be linkified for HTML msgs, and the latter are not altered on
display. The recognition is only done for plain text mails.
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 2•25 years ago
|
||
Mass-ACCEPTing to stop annoying autonotifies
Comment 3•25 years ago
|
||
Carried over from bug 24060:
I've had a specific problem with mailto: URL conversion. Converting "user@host"
to "user@host <mailto:user@host>" on send will screw up communication with
mail-based robost such as majordomo. It's annoying for a majordomo
administrator, who needs two identities, one for sending HTML emails and one for
sending text email to majordomo (You can't say "Compose message in text mode"
from an account that has the HTML compose pref enabled, can you?). But it will
also be pretty annoying for anyone -- and these are "end users", people who
won't know what's going on -- who sends a subscription request to a majordomo
server, composed in HTML and converted to text (automatically, probably, since
the target domain won't be known to accept HTML mail?).
In any event, I'm not sure how useful autoconverting mailto: links is: every
mailer I've used either recognizes user@host as an email address, or doesn't
recognize/deal with URIs at all.
Comment 4•25 years ago
|
||
in 4.x we had a way of doing the "Compose a plaintext message" even if you had
the HTML compose pref on. That was holding down shift while pressing the compose
button on the toolbar. We should probably implement that at the very least.
CC'ing jean-francois to see if he has a bug on that yet.
Comment 5•25 years ago
|
||
Also, you can choose to have the message converted to text/plain on send, even
if you composed in HTML. I do that all the time.
Comment 6•25 years ago
|
||
>in 4.x we had a way of doing the "Compose a plaintext message" even if you had
>the HTML compose pref on. That was holding down shift while pressing the compose
>button on the toolbar.
Covered by bug 16908
Assignee | ||
Comment 7•25 years ago
|
||
zach,
I reopened 24060. This is really a different bug. (Although you have been
pointed to this bug.)
> every mailer I've used either recognizes user@host as an email address, or
> doesn't recognize/deal with URIs at all.
But the feature in question is intended only for HTML mails, and Mailnews does
*not* do this type of enhancements on them.
Also updating summary.
Summary: modifying html messages at send (converting urls to hrefs and structs to html) → Better prefs for text enhancement
Assignee | ||
Comment 8•25 years ago
|
||
Partially fixed with bug #23091. We still need a long-term solution.
Comment 10•25 years ago
|
||
Seems like this is way out there. Marking M30 so it has some milestone on it.
If you think this is wrong, please set a better milestone :-)
Target Milestone: --- → M30
Assignee | ||
Updated•24 years ago
|
Target Milestone: M30 → Future
Assignee | ||
Comment 11•24 years ago
|
||
To make clear, what this bug is about now: The converter is not only used for
Mailnews, but also for AIM and also should be used by the browser (bug 39042). I
don't think, this feature deserves 3 mailnews + 1 aim pref + 2 browser prefs.
This is overkill, I think. We need a way to merge them. My post (see above) was
about that. We still need a solution/decision.
Assignee | ||
Updated•24 years ago
|
Component: Mail Back End → Networking
Product: MailNews → Browser
Comment 12•24 years ago
|
||
I don't like any of this.
* Converting URLs on send has the majordomo problem described by Richard Zach.
* Converting emoticons to graphics never happens, obviously, because the
recipient doesn't have the chrome graphics. For the other two conversion types
to work, while this one does not, could cause a fair bit of confusion.
* Converting structs to formatting on send is just daft. HTML has its own
formatting -- bold, italic, etc -- so adding formatting to pseudo-formatting
structs would only encourage crufty HTML.
Doing all this is *taking away* power from the recipient of a message. A
recipient can choose whether or not to use a client which intelligently converts
URLs/structs/whatever -- or if she is using Mozilla, she can turn such formatting
on or off. But if Mozilla *sends* the messages in formatted form, the recipient
no longer has the option *not* to view this formatting. That would be impolite.
> Doing it this way is good, for other mail applications who don't do the
> conversion from url to href html.'
I think this argument is fallacious, because if a client is able to show HTML
formatting at all, it is virtually certain to be able to highlight plain-text
URLs as links in the first place.
Doing such formatting would also come perilously close to breaking the GNKSA,
section 17:
Posting software ... MUST NOT encode or encrypt articles, unless by
explicit user demand. Hence, it MUST NOT even have the option to encode
or encrypt by default. Whenever some encoding/encryption will be used,
clear feedback showing that it's in effect MUST be provided to the user,
so she is permanently reminded of the fact that her article will not be
posted as composed. The worst DO NOT is the combination of allowing
default encoding without even taking the trouble of telling (warning)
the user about it.
Formatting on send, while probably not regarded as `encoding'/`encrypting' in the
strict sense, would clearly be not posting the article as originally composed.
Reporter | ||
Comment 13•24 years ago
|
||
I agree, we should *never* convert anything we send.
allowing mozilla to convert email or aims or webpages mozilla receives is
acceptable, as long as we have prefs so we can turn it off.
Comment 14•24 years ago
|
||
Ok, so this bug is about how to organize the prefs for text processing on the
recipient's end, to make it cross-component. Right?
What the prefs dialog needs (and what Tardis has) is a `Display' category, which
has subcategories for all the prefs for HTML display (fonts, colors, images,
JavaScript, cookies, etc), prefs which are followed by all components. (The
current prefs dialog has bot prefs for HTML display and prefs for GUI display in
its `Appearance' category, and I think this is highly misleading.)
So prefs for text processing could go in the Display category; but I don't think
they should. As I've said several times before, I think they should go in a
submenu of the View menu instead; because they're things you want to be able to
turn on and off in a hurry. (Wrapping long lines, or showing all/normal/brief
headers, are similarly things which are rarely changed, but which still go in the
menu rather than the prefs dialog because they're things you want to be able to
turn on and off in a hurry.)
The Aphrodite menu spec has this:
View > Use Text Formatting submenu
----------------------------------
. _No Wrapping
* _Wrap Long Lines
. _Rewrap All
-----------------------------
/ Highlight _Links
/ Highlight *_Styles*
/ Highlight _Emoticons :-)
The `Use Text Formatting' submenu is shown whenever the current document is in
plain text format (the rest of the time, it's a `Use Style' submenu for selecting
style sheets). Such a submenu could be turned into an overlay for inserting into
the View menus of relevant components, and I think that would fix this bug quite
nicely.
Hardware: PC → All
Assignee | ||
Comment 15•24 years ago
|
||
mpt,
Richard Zach was referring to a bug, we fixed long ago. If you type
"http://host" in the HTML composer and send as plain text, Mailnews should and
does send just "http://host" (similar for "user@host").
If you send "http://host" as HTML, it sends "<a
href="http://host">http://host</a>", which is exactly the same as 4.x does
(well, I add a class now).
As HTML provides the ability, it is generally considered the responsibility to
format the content appropriately. What would you think about a web page, that
contains "http://host" without being a link?
OTOH, the displaying UA (browser or mail client) has the freedom to process this
however it likes - add formatting, remove formatting, converting.... So, the
recipient indeed has all power (assuming a decent UA).
But I don't know *any* HTML UA, that converts URLs in the content HTML to links.
We (and 4.x) certainly never do it, because we consider this the responsibility
of the sender. So, if we don't recognize it while composing/sending HTML, the
recipient will have to do it manually (without software support). This is, what
*I* would consider impolite.
> But if Mozilla *sends* the messages in formatted form, the recipient
> no longer has the option *not* to view this formatting.
So, sending HTML is generally impolite? I add a class=txt-*, so the recipient
can (e.g. with a user stylesheet) remove this additional formatting easily, even
if sent as HTML.
I get your point about encouraging "*"s in HTML, but I think, we should let the
option in nevertheless.
We do recognize URLs in plain text content.
Assignee | ||
Comment 16•24 years ago
|
||
Let's first discuss the backend prefs in .mailnews (please followup to the post
I mentioned above).
Target Milestone: Future → M18
Assignee | ||
Comment 17•24 years ago
|
||
My suggestion:
Create hidden prefs for each application of the converter (i.e. separate prefs
for Mailnews, AIM, browser etc.), but expose only one or two checkboxes in the
prefs UI which then switch all relevant prefs at once: One for recognition at
display and one for creation time (e.g. Mail or AIM sending).
Assignee | ||
Updated•24 years ago
|
Priority: P5 → P2
Comment 18•24 years ago
|
||
That won't work -- if somebody alters some of the prefs but not the others (using
a text editor, or TweakMoz, or whatever), what are the new states of the
generalized controls in the Mozilla prefs dialog going to be?
You can't use a single control in the prefs UI to control multiple prefs in the
back end, otherwise you will get this sort of mismatch.
Assignee | ||
Comment 19•24 years ago
|
||
> if somebody alters some of the prefs but not the others (using
> a text editor, or TweakMoz, or whatever), what are the new states of the
> generalized controls in the Mozilla prefs dialog going to be?
None is selected. This is the convention, at least under Windows.
If you have better suggestions, speak, but fast.
Assignee | ||
Comment 20•24 years ago
|
||
I have the Pref UI working. Yay!
It is hooked up as a new panel under "Advanced", called "Converters" and looks
like:
Text To Display/HTML
* Minimal
* Moderate
* Maximal
HTML To Text
* Minimal
* Moderate
* Maximal
Moderate = default, Minimal = "raw" (no extra stuff), Maximal = "fancy".
If the user's prefs matches one of these sets, this option is (pre-)selected,
with preference to moderate. If it doesn't match, none is selected. If the
vendor's default (i.e. Moderate) happens to be identical to one of the Maximal
or Minimal sets, the latter is disabled. (This happens in one case for Mozilla,
but not for N6 (which has different defaults :-( ).)
I will attach a patch after more testing. I need a review, and fast, to meet the
N6 deadline and get some sleep (5am here).
Comment 21•24 years ago
|
||
It's time for N6 to ship, not add more features. This feature should go in on
the trunk after N6 branches.
My personal opinion is that this is pretty complex UI, and it doesn't seem that
valuable for real users. Looks like a case of designing UI by/for programmers to me.
Assignee | ||
Comment 22•24 years ago
|
||
Assignee | ||
Comment 23•24 years ago
|
||
Assignee | ||
Comment 24•24 years ago
|
||
Assignee | ||
Comment 25•24 years ago
|
||
Assignee | ||
Comment 26•24 years ago
|
||
Assignee | ||
Comment 27•24 years ago
|
||
Phil,
we had lots of discussion about that stuff (what should be the defaults etc.). I
think, there is a considerable class of users, who will not like our defaults
(no matter how they are). This is teh compromise: don't show the specific
settings to the user, but let him set hios pref on a high level - I liek it
fancy or I like it raw.
BTW: I also added a help button. I can remove it, if there are heavy objectsion,
but i really would like to leave it in, to explain what the options do.
Assignee | ||
Comment 28•24 years ago
|
||
OK, then I stayed up for nothing.
Comment 29•24 years ago
|
||
I have to agree with phil: no new features (and yes, a new pref UI and behavior
to match) and after talking with the rest of the mail team, mail will not be
doing any more context sensitive help until after netscape branches.
There will always be unsatsified users. Sorry.
Comment 30•24 years ago
|
||
BenB: Is it worth resuscitating this bug, and these patches, or have they
rotted?
Gerv
Assignee | ||
Comment 31•24 years ago
|
||
Yes, it is worth to resurrect the patches - they were quite a bit of work (for
me). But I don't have time/moral for it currently.
Assignee | ||
Updated•24 years ago
|
Target Milestone: mozilla0.9 → mozilla0.9.2
Assignee | ||
Comment 32•24 years ago
|
||
*** Bug 77243 has been marked as a duplicate of this bug. ***
Comment 33•24 years ago
|
||
*** Bug 77118 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla0.9.2 → mozilla1.0
Assignee | ||
Updated•23 years ago
|
Priority: P2 → P4
Comment 34•23 years ago
|
||
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1
(you can query for this string to delete spam or retrieve the list of bugs I've
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
Comment 35•22 years ago
|
||
mass assignment of text->HTML bugs to MailNews w/ esther as QA.
Component: Networking → Mail Back End
Product: Browser → MailNews
Target Milestone: mozilla1.0.1 → ---
Version: Trunk → other
Updated•20 years ago
|
Product: MailNews → Core
Updated•17 years ago
|
QA Contact: lchiang → backend
Updated•16 years ago
|
Product: Core → MailNews Core
Comment 36•16 years ago
|
||
Ben, still working on this?
(There seems to be some sort of a patch available..)
Assignee | ||
Comment 37•16 years ago
|
||
WORKSFORME as-is
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•