142149 - Simple HTML mode should give option to view current mail only as original HTML

Status: NEW

(MailNews Core :: MIME, enhancement)

Description

[Stephen Moehle]

The ability to view emails and news articles as "simple HTML" is really great
and much appreciated, but (always a "but") I would really like the ability to
view the current message in the original HTML.  Preferably this would be a
context menu item.  I do not want to use the View menu since that sets the
preference globally.  All I want is to see the current message in the original
HTML.  Once I leave that message, I would expect simple HTML mode to be back in
force even if I view that message again.

Mozilla trunk 2002-05-03-08 on Win2000.

Comment 1

[Ben Bucksch (:BenB)]

See comments in bug 30888. It would have been harder to implement, given how
libmime works, and we chose not to support that. So, you are for now stuck with
using the View menu twice (to Ori. HTML and back).

This bug is a low priority Future bug.

Comment 2

[Ben Bucksch (:BenB)]

.

Comment 3

[Morten Nilsen]

This is a very nice feature, that I am used to having at work, in Groupwise..
Here is how Novell has solved this in their UI:
In quick view mode, there are two buttons to swap between plain text and html mode above the mail headers
In a standalone message window, there are options directly under the view menu, that don't get remembered - they only affect the current message window.

Ben said this was low priority future, and as it is now the future, is there any chance of getting this "soon"?

Comment 4

[Andrew Sutherland [:asuth] (he/him)]

Can you elaborate on your use case a little more?  What type of emails is simple HTML mode not suitable for?

Comment 5

[Morten Nilsen]

In my case, I use plain text mode per default, not simple html mode..
Most times, news letters from online stores I often shop at and sites like MySpace are completely illegibile until I change the display mode.

I'm sorry I wasn't clearer in my initial comment, 
but this bug fits ever so nicely to my issue ,)

Comment 6

[Ben Bucksch (:BenB)]

Then I suggest to always use Simple HTML mode. It's essentially just as safe, and more readable.

Comment 7

[David Ascher (:davida)]

Ben: simple html, which I really like, doesn't always work well for all content -- some messages like bugmail really need the fixed width layout, and some content really needs full html to be readable, like newsletters, which often use tables and background images in valid ways.

Re-summarizing:  

What's being asked for as far as I can tell is the ability to switch view mode (plain / simple html / full html) on a per-message, non-persistent basis.  

This would be easy to add to the Other Actions menu in the message header, maybe as:

  View message as ->
     [ ] plain text
     [x] simple html
     [ ] original html

(a different feature request would be to be able to specify the view mode per contact, which would work for frequent mailings from only some people who send full-bore html)

Comment 8

[Ben Bucksch (:BenB)]

David, thanks for the praise. My last comment 6 compared Simple HTML to plain text mode, not to Original mode. I agree there's a use case for switching between Simple HTML and Original mode.

> What's being asked for as far as I can tell is the ability to switch view mode
> (plain / simple html / full html) on a per-message, non-persistent basis.

Indeed.
Or just binary (on/off button), between simple/plain vs. original, to temporarily enable original HTML.

Implementation:
The reason why this is not implemented yet is because it's hard to pass parameters to libmime converters, you need to touch many places. The current switch is implemented as pref which is read within libmime.

The hack fix would be to change the pref, reload the msg, and change the pref back immediately. One problem with this is that the msg load is async, and I don't think we have a listener for msg load finish event in the frontend yet.

*If* Simple HTML were the default for all messages, this bug would make a lot of sense for many users, and I'd implement it. As is, it's rather low priority for me.

Comment 9

[Ben Bucksch (:BenB)]

Another problem with the hack fix: If we were to use a listener, there may be cases where it never fires, e.g. when the server connection is dead without Mozilla noticing, and TB waits for ages for the data. The listener would not fire and we'd never set back the pref. I'd have to double-check the source and test when exactly the pref is read, maybe it's early. Or maybe we can be very hacky and just use a realtime timeout (assume that the msg start loaded / pref was read after 1s) and then set back the pref. All in all the hack is problematic.

Comment 10

[Andrew Sutherland [:asuth] (he/him)]

I don't think we need to do the hacky thing, or at least anything that hacky.

In mimei.cpp:
a) we modify mime_parse_url_options to check for key "display_as", and have the following value mapping: html => 0, plaintext => 1, htmlsource => 2, simplehtml => 3.  We cram this in a new MimeDisplayOptions field, force_html_as, defaulted to -1 to indicate no value.
b) we modify mime_find_class to set the value of html_as to opts->force_html_as if force_html_as is >= 0.

And then someone writes the UI stuff to cram that in the URI.  Not it.

Comment 11

[Morten Nilsen]

I just feel I need to elaborate a little on my point of view..
When it comes to reading mail, I prefer raw unstyled text - ie. plain text mode

This works for 99% of cases, but every so often, a mail I want to see the original html for comes along..

I tested the simple html mode just now, and while it does solve my main issue with newsletters, it makes html-enabled mail a smidgen less pleasant to my eyes.

If you like, I can grab some screenshots of the Groupwise UI as it relates to this issue..

Comment 12

[Magnus Melin [:mkmelin]]

wanted‑thunderbird3-; can't see how this would be a priority for tb3.

Comment 13

[Marcelo Bastos]

To take it a bit further (but perhaps this should be a separate bug), still better would be the ability to whitelist senders so their mail automatically is opened as Original HTML.
Seamonkey 1.1.x + Multizilla offered that convenience, and it's of the things I miss after upgrading to Seamonkey 2.