Better prefs for text enhancement

RESOLVED WORKSFORME

Status

MailNews Core
Backend
P4
normal
RESOLVED WORKSFORME
19 years ago
9 years ago

People

(Reporter: (not reading, please use seth@sspitzer.org instead), Assigned: BenB)

Tracking

({polish})

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments)

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

19 years ago
Whiteboard: Waiting for pref decision
(Assignee)

Comment 1

19 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

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 2

19 years ago
Mass-ACCEPTing to stop annoying autonotifies

Comment 3

19 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

19 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

19 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.
>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

19 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

19 years ago
Partially fixed with bug #23091. We still need a long-term solution.
(Assignee)

Comment 9

19 years ago
Mass-LATER
Priority: P3 → P5

Comment 10

18 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

18 years ago
Target Milestone: M30 → Future
(Assignee)

Comment 11

18 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

18 years ago
Component: Mail Back End → Networking
Product: MailNews → Browser

Comment 12

18 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.
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

18 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

18 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

18 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

18 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

18 years ago
Keywords: polish
Whiteboard: Waiting for pref decision
(Assignee)

Updated

18 years ago
Priority: P5 → P2

Comment 18

18 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

18 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

18 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

18 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

18 years ago
Created attachment 14764 [details] [diff] [review]
Fix, Hooks, version 1
(Assignee)

Comment 23

18 years ago
Created attachment 14765 [details]
Fix, xul, version 1
(Assignee)

Comment 24

18 years ago
Created attachment 14766 [details]
Fix, js, version 1
(Assignee)

Comment 25

18 years ago
Created attachment 14767 [details]
Fix, dtd, version 1
(Assignee)

Comment 26

18 years ago
Created attachment 14768 [details]
fix, doc (locale/en-US/pref-convert.html) (placeholder), version 1
(Assignee)

Comment 27

18 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

18 years ago
OK, then I stayed up for nothing.

Comment 29

18 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.
(Assignee)

Updated

18 years ago
Keywords: patch
Target Milestone: M18 → mozilla0.9
BenB: Is it worth resuscitating this bug, and these patches, or have they 
rotted?

Gerv
(Assignee)

Comment 31

18 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

17 years ago
Target Milestone: mozilla0.9 → mozilla0.9.2
(Assignee)

Comment 32

17 years ago
*** Bug 77243 has been marked as a duplicate of this bug. ***
*** Bug 77118 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

17 years ago
Target Milestone: mozilla0.9.2 → mozilla1.0
(Assignee)

Updated

17 years ago
Priority: P2 → P4

Comment 34

17 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

16 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
Product: MailNews → Core

Updated

10 years ago
QA Contact: lchiang → backend
Product: Core → MailNews Core
Ben, still working on this?

(There seems to be some sort of a patch available..)
(Assignee)

Comment 37

10 years ago
WORKSFORME as-is
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.