69529 - Pref to view mail as unprocessed source

Status: RESOLVED FIXED

(MailNews Core :: MIME, enhancement)

Description

[Eric]

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 95)
BuildID:    2001021508

The mail component needs a feature that lets you turn off HTML rendering of 
messages.  This would allow one to prevent e-mail tracking in the form 
of "invisible" images that send a user's IP to back to the sender/spammer.

Reproducible: Always
Steps to Reproduce:
none.

Actual Results:  There's no way to turn off HTML rendering in e-mail.

Expected Results:  There should be an easy way -- maybe a button on the Mail & 
News window?

Comment 1

[Tim Powell]

May be a duplicate of Bug 30888. It'd be nice to be able to just see the
plaintext. Bug 18427 "Non-presentational HTML mail" is also related and may be
better in that it could maintain html formatting, but may be able to sidestep
some of the webbugs/images.

Comment 2

[J Luh]

See also bug 28327, "No server hits at HTML mailnews reading - privacy"

Comment 3

[Jesse Ruderman]

*** This bug has been marked as a duplicate of 31907 ***

Comment 4

[Jesse Ruderman]

Wait, this isn't quite a duplicate, because bug 31907 seems to be leaning 
toward allowing the user to turn off specific features of HTML instead of 
turning off HTML entirely.

Comment 5

[u27431]

It sounds like the various ideas flying around for this are needlessly complex
for the user (e.g. blocking image loading in mail for specific domains).  What I
think is a very clean approach that works well for mail is:

   "Disable HTML mail for all addresses not in my address book"

That seems like a reasonable source for trust information.  Perhaps it should
omit automatically collected addresses though.  It's sort of the inverse of
using your address book to decide who you can send HTML mail to.  You could do
the receive thing on that basis as well, but I think that's probably needlessly
complex.  I think the main application of this is to avoid rendering HTML-based
spam, at least, that's what I want it for.

This wouldn't work as well for news, of course, but then you can get down to
blocking specfic domains, etc. if people still want to go that route.  It still
might be a useful option for news.

It might be worth optionally prompting users to see if they want to render HTML
from unknown addresses.  The pref could be:

(X) Always show HTML email/news.
( ) Prompt before showing HTML email/news from people not in my address book.
( ) Never show HTML email/news from people not in my address book.
( ) Never show HTML email/news.

Some messages have both plaintext and HTML, and the plaintext should be
displayed if available.  What would be really great, but probably hard, would be
to take HTML-only messages and strip out the tags and display that.  But that
should probably be another feature request.  I would be more than happy to see
the simple idea presented above.

Sorry this is kind of long.

Comment 6

[Julz]

I wouldn't mind if the HTML is just displayed inside a <pre> tag or even just
displayed as plain text.  The HTML rendering still occasionally crashes Mozilla
Mail and News.  And I find HTML mail really annoying.  A link to a site is much
better.
Maybe a link should be displayed instead of the HTML and clicking this shows it
from the cache or message...

Comment 7

[[e-mail]]

"dont show HTML" could mean: show the source; for those who from
the source decide that the email is harmless a button or context menu
option would come in handy to show as rendered HTML.

Comment 8

[Ola Thoresen]

*** Bug 86406 has been marked as a duplicate of this bug. ***

Comment 9

[Kathleen :Brade]

I'd be happy if this was a toggle in the menus.
I like the idea of using my addressbook to determine whether I want plaintext or 
HTML (as described above on 2001-05-01 19:43).

Comment 10

[Matthew Tuck [:CodeMachine]]

It is wrong to do this.  HTML mail is the new standard for email - like it or
not.  It has many advantages, and all of the "disadvantages" are purely problems
with current implementations.

Comment 11

[u27431]

The preceeding comments doesn't seem particularly useful.  It claims that HTML
mail is the future and that it is currently flawed, but completely fails to
suggest how to deal with "all of the disadvantages".  That is hardly
constructive.  This RFE addresses a very real problem.

While I am delighted to receive HTML mail from trusted sources, I value my
privacy and HTML is sufficiently powerful to violate that privacy.  Were it
purely a formatting language (e.g. LaTeX) there would be no problem.  As it
stands, I believe this feature is necessary for privacy.  I'm certainly not
willing to trade my privacy and control of network activity for the sake of nice
fonts and pretty pictures.

Note also that this is a "preference".  If you don't like it, don't turn it on.

Comment 12

[Matthew Tuck [:CodeMachine]]

The solutions have already been suggested - bug #28327 and bug #18427.  With
these fixed, I see no reason that anyone would want HTML mail off.  Don't get me
wrong, I'm as annoyed at bad HTML mail implementations as the next person.  But
we are not that far off of a good implementation.

Just because you can preference it doesn't make it a good idea.  Firstly, we'll
never get into a world of decent rich mail if everyone turns HTML mail off.  And
secondly, we don't want to spatter useless preferences around the product.  If
it's always going to be a user preference fine, but if there's a better
solution, we shouldn't introduce the preference.

Note that I never advocated "fonts" as a useful feature.  Quite the opposite. 
Pictures (within MHTML so there's no privacy concern) are certainly a useful
feature though.  Useful features are stuff like soft wrap, proper hyperlinks,
and structural styling (emphasis, headers, bulleting, etc).

Comment 13

[Kathleen :Brade]

I think this bug is proposing an alternate fix for #28327/#18427 which solves the 
same problem (avoiding spammers / privacy issues).  See comments on 2001-05-01 
19:43.

Comment 14

[Alfonso Martinez]

I don't think that this bug is _only_ related to avoiding spammers / privacy
issues. Personaly I would like it to be implemented like a comment has
previously stated: "Disable HTML mail for all addresses not in my address book"

I say that because there out there too many people that think that sending
emails with big fonts, colorful backgrounds, etc.. is "nice", but whenever such
a mail arrives at me I know that he is a looser and he's got nothing interesting
to say. Reading only the text of such messages will show what they really got to
say, not the beautiful backgrounds that his email client got.

Comment 15

[Ola Thoresen]

I still want to be have the ability to disable HTML from everyone (including people in my address book).  So far, I have never recieved any HTML-mail where the HTML was neccesary to understand the contant, or even made it more understandable.
HTML makes it more difficult to copy and paste, a "nice" background makes the mail less readable.  Tables, images, fonts.. all this makes the viewing of the actual mail slower.
I want to read the content of the mail, and that's it.

Notice - I do not want to deny any of you the pleasure of looking at those nice, colorful and blinking mails.  All I want is the freedom to choose how I want to see the mails I recieve.

On a sidenote, though... a huge photo of you and your dog included in every mail is a waste of both your (which I don't care about) and my (wich I definetly care about) badwidth.
I read mail on everything from a 100Mbit local LAN to a 9600bps GSM-dialup.
So please remember, that your mail - with all your pretty formatting and flashy images - could make me give up reading mail when I am on the road, and thereby missing some important info. - Important info for me - or even for you.

Rgds.

Comment 16

[John Hardin]

I just want to be able to set a global flag of "Ignore HTML body parts
completely", but I think [e-mail]'s four options idea will suit
the general audience better.

Comment 17

[(Don't use, old account) - Kai Engert]

*** Bug 102511 has been marked as a duplicate of this bug. ***

Comment 18

[Kai Engert (:KaiE:)]

Changing my e-mail address.

Comment 19

[Kai Engert (:KaiE:)]

Removing old e-mail address.

Comment 20

[Christian Eyrich]

I don't think that MrEricSir intetion was to disable HTML at all but what I ever
wanted to be able to do: forbid the mail reader to follow external links to
images anywhere on the net.
That's the point of this bug and not disable HTML because people do worse things
with it (that's true but subject of other bugs).
Bringing up an alert "Code in this mail will load content from the net. Do you
want to allow this? YES|NO" would a very nice solution for this I think (one
time no should also be enough for two or more images in this mail).

Comment 21

[Ben Bucksch (:BenB)]

Comments From Tim Powell 2001-02-20 12:44;
> May be a duplicate of Bug 30888.

It is.

*** This bug has been marked as a duplicate of 30888 ***

Comment 22

[Markus Gerstel]

Sorry, NACK. Comments from Bug 30888 :

Jeandré : Not just have a "View as plain text" option to textify HTML emails,
but have an Edit | Preferences option that all email with f*#$% HTML is
displayed as plain text (source) - never allow images, webbugs, invisible forms... 

Alec Flett : that's another bug, go file it.. dont' polute this one.

Comment 23

[Matthias Versen [:Matti]]

*** Bug 108004 has been marked as a duplicate of this bug. ***

Comment 24

[Kousik Nandy]

While displaying HTML mail we can just allow simple tags like <hr>
<br> <pre> <b> <li> <table> and ignore rest of the tags e.g. <img>
<link>. I guess it'll be tough to do, but that may combine best of
both worlds. A preference entry could be

( ) Render all HTML tags in mail-news
(X) Only render simple HTML tags in mail-news
( ) Never render HTML tags in mail-news

Comment 25

[[e-mail]]

I think there should be two preferences for two different things:
preference1 to control whether email is allowed to do insecure or
undesired things: disallow *any* external reference to images, style sheets,
applets etc (and this should be the default);
disallow javascript (we already have that).

preference2 to control if and how HTML gets rendered. one argument why this
is needed is that often HTML text is hard to read. for this, it might be
good to have the same preference as for browsing pages to specify if
colors and fonts should be shown as specified or as the user wants.

not rendereing HTML at all is kind of redundant since we have the
view source option.

Comment 26

[Ola Thoresen]

What I mean with "do not render html" is not "view source".
I want either: 
a) If the mail is two 
parts, one text and one html - but with the same content (as some mailers send), then only show the 
textpart.

b) If the mail is html-only. Strip all tags, scripts whatnot and show it as text 
only.
Maybe handle it a slight bit more intelligent and render <br> and <p> so we keep the 
linebreaks, but nothing else. I want mail to be text only. Both when I send and when I recieve.  
Call 
me old fashioned - I handle 200+ mail every day, and text-only is the easiest, fastest and most 
convenient way to read them.
=;-)

Ola (T)

Comment 27

[Daniel Veditz [:dveditz]]

Please, please read the entire bug before commenting.
1) we're repeating ourselves
2) we're arguing "this but is really that" when those other related
   features are covered in other bugs, clearly referenced in this bug

bug 30888 - strip html and show plain text
bug 18427 - suppress some HTML styles (more or less, maybe user mail stylesheet?)
bug 28327 - don't hit the net while reading mail (privacy feature)

This one is "show unprocessed mail source -- disable HTML processing"

Maybe those other bugs would be nice, but this one's got to be a dead easy way
of getting us part of the way there and I, for one, would appreciate the faster
mail rendering and don't mind seeing junky HTML tags for spam I'm just going to
delete anyway.

This differs from the current view-source in two ways
- would be the default presentation, no need to process the HTML also
  and open a new window.
- would show the mail body plain source, but would still do the current
  nice things for the headers and attachments

I realize lots of people want more, but that more is covered in other bugs.

Comment 28

[Ben Bucksch (:BenB)]

dveditz,
most people incl the report just requested to "turn HTML off" but didn't suggest
what to show instead. Some people suggested plain text (version/conversion),
some (incl. you) HTML source.

The first option would be a dup of bug 30888, if alecf allows a pref (in
contrast to only a menu option with temporary effects).

Comment 29

[Daniel Veditz [:dveditz]]

Isn't that what I said? People want different things and they are covered in
different bugs. Let's keep the conversation in *this* bug to the topic not
covered in those other related bugs.

If I put "bicycle" on my Christmas wishlist I don't need someone to tell me that
a car is faster and would keep me dry in the rain. I want a car too, but
meanwhile a bike would be better than walking and much more affordable.

Comment 30

[Daniel Veditz [:dveditz]]

modifying summary to clarify the differences between this and bug 30888

Comment 31

[Quinn Yost (mythdraug)]

*** Bug 121853 has been marked as a duplicate of this bug. ***

Comment 32

[Ben Bucksch (:BenB)]

OK, I have this implemented, so I am taking this bug. I hope, Seth, you don't
mind (otherwiese feel free to assign back to you).

What I did:
You can set the pref (no UI) "mailnews.display.disable_html" to true.
If it is a multipart/alternative message, we will ignore the HTML part, ending
up displaying the plaintext part.
If it is an HTML-only message, I followed dveditz's suggestion and just display
the HTML source for now (technically, I treat the HTML part as plaintext part),
because that indeed turned out to be much easier.
However, I don't think that's a good idea in general and we should convert
HTML->TXT->HTML instead (which would be more towards bug 30888 - I think). I
will do that once I figured out how to drive the HTML->TXT conversion syncronously.

I will attach the current state of the patch here, but further versions will
probably be attached to bug 30888.

Comment 33

[Ben Bucksch (:BenB)]

Attachment: Suggested fix, Version 1

Comment 34

[william.allen.simpson]

I disagree with the proposed implementation.  I thought that the earlier 
discussion to keep these methods distinct was the agreed solution.

That is, I expected something like:
  mailnews.display.html=full    (displaying everything is OK)
  mailnews.display.html=source  (only display source)
  mailnews.display.html=privacy (http://bugzilla.mozilla.org/show_bug.cgi?id=
28327)
  mailnews.display.html=text    (http://bugzilla.mozilla.org/show_bug.cgi?id=
30888)

For new users, the "privacy" selection should be the default, until explicitly 
overridden.

On the UI side, what I really wanted was a default preference, with a UI to 
change that on a per message basis, which would be remembered in the database for 
that particular message.  

As to multipart alternative, what I expected was:
  mailnews.display.alternative=list (list the parts, like 4.x)
  mailnews.display.alternative=text (show text part only)
  mailnews.display.alternative=html (show html part only)

For new users, the "list" selection should be the default, until explicitly 
overridden -- similar to message composition.

Comment 35

[Ben Bucksch (:BenB)]

wsimpson,
it does not make sense to show the HTML source in the message page. Almost no
user can do anything useful with it, and even hardly any people who do know HTML
will want to read the mess that MS Outlook and spammers throw out. As I
understood dveditz, he suggested showing the HTML source only as interim
solution until we can do something more useful.
If you still disagree, then exaplin me why the browser has no option to show the
HTML source instead of the rendered page. Remember that you can always call
View Source (in both the browser and Mailnews).

Bug 28327 (your "privacy" setting) is completely different. It would only be
needed, if disable_html pref is false. We can have another pref for that, no
need to fold them into one. This makes sense, because it's a completely
different feature. It just happens to have the same goal, but prefs are no UI.
The prefs UI can might show them together somehow, the backend prefs are a
different matter.

> On the UI side [...]

Fine. Let's get the backend done first.

Comment 36

[Daniel Veditz [:dveditz]]

Actually I did want to see the HTML source. I'll trash it immediately, of
course, but I want to see the entire mail message that's sent to me, not pieces
selected and processed by the MuA. Yes, I can do "View Source", but when I find
my self doing "View Source" for every message I find myself wanting a pref to
make that the default view.

As a side benefit it should speed up my mail viewing, too, since there won't be
any processing.

Comment 37

[Ben Bucksch (:BenB)]

> I did want to see the HTML source. 

I see. The mimei.cpp subset of the attached patch should do what you want, then.

Personally, I don't see the point of showing HTML source, when there is a
plaintext alternative, but luckily, it's open-source, so you can have what you
want :).

> As a side benefit it should speed up my mail viewing, too, since there
> won't be any processing.

Actually, there is more processing, because the HTML source is treated as
plaintext. We display plaintext by converting it to HTML and displaying that.
The least processing (in libmime) actually happens when displaying HTML.

Comment 38

[Ben Bucksch (:BenB)]

My usual credo is "Backend-prefs are cheap. If they make people happy...", so I
guess I should add the pref. I did so. It is part of the patch that I will
attach to bug 30888.

The prefs are atomic, so you should be able to get all requested and thinkable
combinations.

There is no UI yet, and I don't think showing the HTML source in the message
pane should have any UI. If you disagree, file a new bug (and cite the number
here), but I will vote for WONTFIX.
IMO, there should be UI for bug 30888, however, and I might implement it.

Comment 39

[Ben Bucksch (:BenB)]

Narrowing scope of bug to displaying HTML source, as requested.

Comment 40

[Boris Zbarsky [:bzbarsky]]

*** Bug 130897 has been marked as a duplicate of this bug. ***

Comment 41

[Ben Bucksch (:BenB)]

Fix checked into trunk.

Thanks to all reviewers and all others involved.

This is not yet in the 1.0 branch. I still would like to check it into the
branch. If not, it would not be in any Mozilla 1.0 releases, but only trunk
nightlies and 1.1alpha.

Please test the feature and try to circumvent it, i.e. get arbitary HTML
rendered although the new options are active. If so, please file a new bug
against Mailnews/MIME, owner me, and mention it here.

Some documentation can be found at <http://www.beonex.com/temp/index.html>. When
I have ftp access to my private server again, I will move it to
<http://www.bucksch.com/1/projects/mozilla/108153>.

Comment 42

[R.K.Aa.]

*** Bug 147201 has been marked as a duplicate of this bug. ***

Comment 43

[R.K.Aa.]

*** Bug 149305 has been marked as a duplicate of this bug. ***