4.36 KB, patch
|Details | Diff | Splinter Review|
3.46 KB, text/plain
8.08 KB, text/plain
1.54 KB, text/plain
99 bytes, text/html
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.
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.
Mass-ACCEPTing to stop annoying autonotifies
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.
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.
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
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
Partially fixed with bug #23091. We still need a long-term solution.
Priority: P3 → P5
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
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.
Component: Mail Back End → Networking
Product: MailNews → Browser
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.
Hardware: PC → All
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.
Let's first discuss the backend prefs in .mailnews (please followup to the post I mentioned above).
Target Milestone: Future → M18
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).
Whiteboard: Waiting for pref decision
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.
> 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.
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).
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.
Created attachment 14768 [details] fix, doc (locale/en-US/pref-convert.html) (placeholder), version 1
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.
OK, then I stayed up for nothing.
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.
Target Milestone: M18 → mozilla0.9
BenB: Is it worth resuscitating this bug, and these patches, or have they rotted? Gerv
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.
*** Bug 77243 has been marked as a duplicate of this bug. ***
*** Bug 77118 has been marked as a duplicate of this bug. ***
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
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
Ben, still working on this? (There seems to be some sort of a patch available..)
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.