35929 - Hide/Mute quoted text

Status: NEW

(MailNews Core :: MIME, enhancement)

Description

[Ben Bucksch (:BenB)]

Some users seem to prefer not to read quotes. Add a preference to hide them
while reading, possibly with the ability to hide only from a certain depth of
nested quote (quote levels) on, e.g. "hide all quoted quotes" (which means
roughly "hide all lines starting with "> > "").

This will be easy to implement after bug #31906 is fixed. You can just add a
rule to your stylesheet (messenger.css) like
blockquote blockquote {display: none}
which would achive "hide quoted quotes".

Question: Is this desireable as a pref in the UI?

Comment 1

[Phil Peterson]

As I said in email, I think the sexy thing to do here is to provide some
widgetry in the message body to expand/collapse quoted material, as we do in
threaded view in the thread pane. Also needed would be a clear indication that
some of the message body is not shown.

Comment 2

[Ben Bucksch (:BenB)]

I suggest a menu View|Body|Show quotes, which will change the pref and trigger a
reload of the msg pane.

If the pref is true, everything will display as usualy (means after 31906, i.e.
the behaviour of my current local Mozilla copy). That's because I *really* like
the current display and don't want it to be littered with (small) buttons.

If it is false, there should be a small line and an open button (just like in
the other panes) on the left. If clicked, the line will disappear, (only) the
corresponding quote will open and the button will change into a close button.
This state will not be saved across msg displays (i.e. after reopening the msg,
all wuotes will be closed again). That way, a quote will behave like a thread of
folder with the initial state closed.

What do you think?

The line, buttons and open/close behaviour *should* be implemented in the
frontend only, e.g. using CSS2' |:before| pseudo-element and JS altering the DOM
or similar magic. It shouldn't be hard, if you know, how to do it, but I don't,
so, this would propably have to be done by somebody else.

Comment 3

[lchiang]

cc: jennifer.

Comment 4

[Karl Ove Hufthammer]

I would prefer to buttons on the toolbar, similar to the 'Increase indent' and 'Decrease indent' buttons, which would show/hide quoted content from a certain depth, i.e. the buttons would increase or decrease to which depth quoted content should be shown.

Comment 5

[Phil Peterson]

huftis, I'd prefer something simpler. Hide quotes vs. show quotes or something.
Clicking once to hide a level, and then again to hide another level, and
clicking some more times to show them again, sounds like a pain.

Comment 6

[Karl Ove Hufthammer]

Well, perhaps it can be similar to Undo/Redo buttons word processors or Back/Forward in web browsers. You can then hide/show one more/less quote level, or a number of levels/depths.

Comment 7

[Ben Bucksch (:BenB)]

huftis, I agree with phil here, because what you suggest is more the procedural

style of UI, where yuo give commands to the app, instead of the

object-orientated, where you manipulate data directly and in place. This is much

more intiutive, in part, because the user doesn't have to look for a function,

but can directly see it.

Phil's suggestion (which I outlined in more detail) for the expand/collapse

quote buttons is a good example fot the latter. The menu entry "Hide quotes",

although being an example for the former approach, is useful 1) to quickly turn

all quotes on/off and 2) to hide all this widgetry for people, who doen't need

or like it.

Comment 8

[Ben Bucksch (:BenB)]

I'll try to get it in my schedule, but no promises.

Comment 9

[Ben Bucksch (:BenB)]

Won't make it in M16. I think, this can be implemented with CSS + minimal
JS/XUL. Maybe, I'll have the chance to fix this in the near- to mid-term future.
M17 for now.

Comment 10

[Ben Bucksch (:BenB)]

Moving a bit out. I have more important bugs (in the composer/sender) to fix for
NS6. Vote, if you disagree.

Comment 11

[Eugene Savitsky]

Personally I prefer like it does The Bat! (www.ritlabs.com)

ES>>
ST>

etc.

So I can see how spoke what in longer quote...

Comment 12

[Ben Bucksch (:BenB)]

Changing personal priorities. Giving away most of my bugs :-( (reassigning to
default owner).

I will still track these bugs closely. If you need my input, feel free to ask me.

New owner: Please do *not* close these bugs (as WONTFIX or whatever you may
find) unless they are fixed. Rather, reassign to <[e-mail]>, if you
don't want to work on them.

Comment 13

[scottputterman]

reassigning to ducarroz

Comment 14

[Garth Wallace]

Would it be possible to make the quotebars clickable, and use those as 
the "hide quote" widgets? The "open quote" widget could be a horizontal bar of 
the same color in place of the quote.

Comment 15

[Ben Bucksch (:BenB)]

Might be possible with much trickery. As they are, they are style added by CSS,
and that style is not "active", i.e. cannot be scripted.

Comment 16

[John Moreno]

I believe that bug # 71583 depends upon this.  Also, I would suggest that 
the summary be changed to "Hide/Mute quoted text" to make it easier to 
find.

Comment 17

[Garth Wallace]

No, it does not. This feature is so that people can hide/skip (and unhide)
quoted text in a message they're viewing. Bug #71582 is for a feature to delete
the deepest-quoted text (or quoted text from a given depth onward) when
composing a reply. Very different functionality.

Comment 18

[John Moreno]

This is a popular feature in various mail/news programs, do you think it'd 
motivate anyone to work on it to list them?  Gravity, Xnews, Pan, Mulberry 
(just found out about that), Gnus....

Comment 19

[John Moreno]

Dialog has this feature as well.

Also, could the summary be updated so that it says "Hide/Mute quoted text"?

Comment 20

[Garth Wallace]

I've never heard it called "muting" before

Comment 21

[u60234]

This feature would be even more useful if Hide/Mute would still show the last 4
or 5 lines of the quoted text. This would suppress large blocks of quoted text,
but still give some context, so you know what the reply is all about. Gravity
does this. 

Comment 22

[Garth Wallace]

That sounds like it'd just make the window look messy. I'd rather the whole
quote be compacted (this would probably be easier to code, too). If I want the
context, I can uncompact the relevant quote.

Comment 23

[John Moreno]

As mentioned in the original description, adding

blockquote[type=cite] { 
display: none;
} 

To userContent.css results in the text being hidden when it's recognized as quoted.  Of course that's 
not much of an interface...

Comment 24

[M.J.G.]

(In reply to comment #23)
> As mentioned in the original description, adding
> 
> blockquote[type=cite] { 
> display: none;
> } 

Forgot to mention, but this comment let me to develop the quotecollapse extension quite a while back. Don't know if this means the bug can be closed.

Cheers,
Michael

https://addons.mozilla.org/thunderbird/347/
http://quotecollapse.mozdev.org

Comment 25

[Peter Lairo]

(In reply to comment #24)
> Forgot to mention, but this comment let me to develop the quotecollapse
> extension quite a while back. Don't know if this means the bug can be closed.

I hope not. This bug is about having Hide/Mute quoted text in the base application, not an extension. 

Could you contribute the code for quotecollapse as a patch?

Comment 26

[Ben Bucksch (:BenB)]

> http://quotecollapse.mozdev.org

http://www.mozdev.org/source/browse/quotecollapse/src/chrome/content/quotecollapse/quotecollapse.js?rev=1.3&content-type=text/x-cvsweb-markup

Ah, so you're adding the twisty as background (of the blockquote) and an onclick to the document, and then in the onclick use event.target and
// react only to active spot (leave rest for copy etc.
if( (event.pageX > target.offsetLeft+12) || (event.pageY > target.offsetTop+12) ) return true;
to find clicks on the twisty. Plus CSS for hiding etc..

I was hoping to insert the twisty as DOM node and be able to hang off an onclick on that (comment 2, last paragraph), but I guess that's an OK workaround.

Comment 27

[Ben Bucksch (:BenB)]

> I was hoping to ... (comment 2, last paragraph)

Boy, is this really over *6* years ago? *Phew!*

Comment 28

[Ben Bucksch (:BenB)]

Attachment: Possible fix, v1

OK, inspired by the above mentioned code, I added this to Thunderbird core.
Patch attached. It works fairly well, but a few things are left:
- Twisty graphics. I don't think I can load chrome imgs in the msg body,
  not sure why it works for the extension. Or maybe I just use a bad path.
  Should try to reuse existing imgs in skin.
- There should be an obvious un-missable hint that there is text hidden.
  I tried to add "..." using :after { content: "..." }, but it doesn't
  show up, because we cut the height of the node and it appearantly
  is part of it.
  In any case, I made the background light grey.
- Initial state is expanded. State is not remembered across msg loads.
  There is no pref or anything to hide quotes when loading a new msg.
  So, all it does is to allow the user to manually hide a quote.
Implementation notes:
- I would have preferred to attach the onclick to each blockquote, but then
  I get mutiple events for nested quotes, for all upper ones, too.
- Not sure about the CSS rules, esp. the height.
  I used those from MJG, more or less.

Does anybody (MJG) want to adapt this? If not, any comments from the mail owners?

Comment 29

[Peter Lairo]

Some great progress, Ben. Just a few comments/suggestions:

(In reply to comment #28)
> - Initial state is expanded. State is not remembered across msg loads.

This item is essential for this bug to be considered fixed.

Some other things I'd like to see implemented:

1. UI option to set how many quote levels are *not* hidden:

   Show the [ 1 ] most recent quote level(s). ("all" or "0" shows all)

2. UI option to set how many lines of text are shown in non-hidden quotes.

   Show the first [   ] lines of quoted text.

I think this could greatly increase the efficiency of reading heavily quoted texts (e.g., newsgroups). The result might look something like this: 

(levels shown = 1, lines shown = 2)
-----------------------------------
>> [-] A friend of mine sais that Thunderbird doesn't use valid W3C code in >>
> [-] Thanks for all your knowledgeable responses.
> So the consensus seems to be that Thunderbird is using invalid HTML, even
I like type=cite! Short, concise, and (I think) does quoting well. Outlook's quoting is horrendous! "<BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px"> "! Give me a break! Though I more often see "<blockquote
 cite="[e-mail]"
 type="cite">".

Result:
The >> level shows only one line, because it's a "non-shown level" (yes, the one line does show, but that's necessary and good).

The > level shows 2 lines, as set in the options.

The non-quoted (new) text is shown completely.

BTW: I like the (geeky) shortcut keys in the quotecollaps extension, where you can expand/collapse all quote levels at once (IIRC, it's CTRL+click).

Comment 30

[M.J.G.]

(In reply to comment #28)
> Created an attachment (id=241281) [edit]
> Possible fix, v1

Hey, you're making my extension obsolete! ;)

> OK, inspired by the above mentioned code, I added this to Thunderbird core.

Some mentioning of the source of inspiration would comfort me over the loss of my extension...

> Patch attached. It works fairly well, but a few things are left:
> - Twisty graphics. I don't think I can load chrome imgs in the msg body,
>   not sure why it works for the extension. Or maybe I just use a bad path.
>   Should try to reuse existing imgs in skin.

In versions below QC 0.5 I used existing images from the skin. It turned out that different versions of the TB skin used different imgs: gif versus png, which would make the path dependent on the TB version. Bad for an extension, but OK if  it's integrated. The paths used to be

chrome://global/skin/tree/twisty-clsd.gif

resp. png etc. I didn't check the current ones.

> - There should be an obvious un-missable hint that there is text hidden.
>   I tried to add "..." using :after { content: "..." }, but it doesn't
>   show up, because we cut the height of the node and it appearantly
>   is part of it.
>   In any case, I made the background light grey.

Gmail displays a huge button replacing the quote entirely. I prefer seeing the first line or so. I bet ":after" inserts content at the end of the quote, not the end of the first line. Alternatively, instead of the twisty one could use a different background mimicking a right arrow or a series of down arrows or a CR or such. "Fading away" using alpha transparancy would be really "kool". ;)

> - Initial state is expanded. State is not remembered across msg loads.
>   There is no pref or anything to hide quotes when loading a new msg.
>   So, all it does is to allow the user to manually hide a quote.
> Implementation notes:
> - I would have preferred to attach the onclick to each blockquote, but then
>   I get mutiple events for nested quotes, for all upper ones, too.
> - Not sure about the CSS rules, esp. the height.
>   I used those from MJG, more or less.

They use em and ex so they should mostly adjust to the font. Counting actual lines and adjusting the height dynamically would be quite laborious. The initiated can still use user-content.css and style away.
 
> Does anybody (MJG) want to adapt this? If not, any comments from the mail
> owners?

I'd be happy to go for it since I kinda know the code... Indeed, I've been planning to change QC so that it can be configured more easily. Glad you caught me before. Ideas which came up (based on user suggestions):

- Have a menu entry
- Have key bindings
- Have preferences for default state and # of displayed quote levels

What's the timeline for this? Too late for 2.0, I guess?

Michael

Comment 31

[Frank Wein [:mcsmurf]]

Ben, please fix the name of Håkan Waara in your patch. He does not like getting his name corrupted ;).

Comment 32

[Ben Bucksch (:BenB)]

> Hey, you're making my extension obsolete! ;)

Hey, you stole my idea! ;-P

I thought you'd be glad to see it moved to core. However, after having posted the patch, I thought that this is maybe indeed best left as extension, because most people usually don't need it? Or is Outlook quoting so bad that ordinary people would *need* it?

- I don't think that *any* visible preference or menu item for this is warranted, nor needed, given that the twisties are right in your face and obvious "direct manipulation". See (ill-phrased) comment 7, first paragraph.
- I do think that remembering on/off state per quote level *may* be a good idea, but may just as well get into the way and render the feature useless, if you just want to collapse an occasional single huge/overzealous quote.
- It might be a good idea to hide all quotes of the same level at once, though.

> What's the timeline for this? Too late for 2.0, I guess?

Given the questions above, I think that's not something for 2.0.

> The paths used to be chrome://global/skin/tree/twisty-clsd.gif

I don't think that's still in the source, and I don't know what replaces it.
There's the potential problem that the size of the twisty is different in different skins, because you (and I) are hardcoding its size. Marked with XXX in code.

Comment 33

[Ben Bucksch (:BenB)]

Oh, re credits: I think that belongs into the CVS check-in comment (given that the code hardly resembles yours, apart from 2 lines and CSS), and yes, I did intend to add an "inspired by ..." there.
If you want to adopt/takeover the patch, feel free to do so.

Comment 34

[M.J.G.]

(In reply to comment #32)
> > Hey, you're making my extension obsolete! ;)
> 
> Hey, you stole my idea! ;-P

Indirectly, at least. I think I picked it up from some newsgroup. Forgot about the related bug until I saw it mentioned recently.

> I thought you'd be glad to see it moved to core. However, after having posted

Yes, definitely.

> the patch, I thought that this is maybe indeed best left as extension, because
> most people usually don't need it? Or is Outlook quoting so bad that ordinary
> people would *need* it?

I don't know. I wouldn't read want to read newsgroups without QuoteCollapse any more, but then I might be somewhat biased.

The default state should be "expanded" so that "most users" won't cry out loud because things changed. For the rest there should be some way of specifying different defaults - through preferences (hidden or with GUI) or through user-content.css, although the latter really makes it a geek thing.

> - It might be a good idea to hide all quotes of the same level at once, though.

That's what a CTRL-click does in the extension:
CTRL-click: expand this level everywhere
SHIFT-click: expand all contained quotes
CTRL+SHIFT-click: expand everything

sed -e 's/expand/toggle/g'
 
> > What's the timeline for this? Too late for 2.0, I guess?
> 
> Given the questions above, I think that's not something for 2.0.

I'll update the extension then. It works with 2.0, just needs a maxVersion bump (and maybe a new twisty).

> > The paths used to be chrome://global/skin/tree/twisty-clsd.gif
> 
> I don't think that's still in the source, and I don't know what replaces it.
> There's the potential problem that the size of the twisty is different in
> different skins, because you (and I) are hardcoding its size. Marked with XXX
> in code.

It's suboptimal but it doesn't mess up things completely. It just means that the "active spot" doesn't necessarily match the twisty completely. In an early version the whole blockquote was "active". The only problem was that text selection triggered QC...

(In reply to comment #33)
> If you want to adopt/takeover the patch, feel free to do so.

I don't even know how to. We can work on this together any way - I put the smileys there for a reason.

So, if this is going to land in core for 3.0 I won't put much effort into the extension any more.

I think the question of preferences (which and how) is quite open. One idea is to have the basic feature in core but make it easy for an extension to tune it. Kinda like: quote colors are in core but there's also an extension named QuoteColors which can change all aspects of the rendering of quotes (except for expanding/collapsing).

Michael

Comment 35

[M.J.G.]

(In reply to comment #34)
> (In reply to comment #32)

> > > The paths used to be chrome://global/skin/tree/twisty-clsd.gif
> > 
> > I don't think that's still in the source, and I don't know what replaces it.

skin/classic/global/tree/twisty-{clsd,open}.png in chrome/classic.jar, i.e.
chrome://global/skin/tree/twisty-{clsd,open}.png are in the 1.8.0 and 1.8 branches and the trunk.

Michael

Comment 36

[M.J.G.]

(In reply to comment #28)
> Created an attachment (id=241281) [edit]
> Possible fix, v1

Ben, I just saw you requested review from me. Sorry, but I'm glad I remember how to request review - but how do I deal with a request? I mean, technically I'm challenged by the bugzilla interface :| 

Codewise: Do you want me to go ahead and tinker with your code? I would integrate a key binding, possibly the "advanced clicks" for expanding by level/nesting. Do I have the right impression that you're somehow opposed to pref UI? How about hidden prefs for the default of quote levels shown? Would do the UI as an extension then ;)

Michael

Comment 37

[David Ascher (:davida)]

Is there anyone interested in updating this patch for trunk?

Comment 38

[Magnus Melin [:mkmelin]]

Attachment: updated to trunk (needs more work)

This is a patch for trunk - though i don't think it's usable as is. 
(The icons needed !important to show.)

Comment 39

[David Ascher (:davida)]

Based on comment #33, reassigning to Magnus.

Comment 40

[Magnus Melin [:mkmelin]]

I'm not currently working on this.

Not a primary focus for the thunderbird3 release; wanted- don't indicate we wouldn't accept patches.

Comment 41

[David Ascher (:davida)]

Attachment: Updated with better twisty handling

The attached patch works pretty well.  It doesn't persist across messages, which I can see being useful, but I'm not sure how to do that simply.  Ideas?

Comment 42

[David :Bienvenu]

what would you need to persist? The fact that quoted text should be collapse for every message you display (in which case, a pref would be the way to go), or that quoted text for a particular message should be collapsed (in which case setting a bool property on the msg hdr would be the approach, nsIMsgDBHdr::setUint32Property), or would you want to store the collapsedness of a particular quote on a particular message? In which case, multiple properties on msg hdrs, with some sort of identifier for the quote that you roll into the property name. But I don't know how you identify the block quotes - can you decorate the html mime outputs with a unique per quote in msg identifier that could be used in the property name?

Comment 43

[Ben Bucksch (:BenB)]

> persist ... I'm not sure how to do that simply. Ideas?

Did you try the persist= flag for XUL? I don't know whether that only works for XUL or only for chrome (you're in untrusted HTML), but it would be perfect.

OTOH, the non-persistence can be an advantange for use-cases where there's only a single msg with too long quotes. It also prevents people from missing quotes, which can sometimes carry important meaning which gets lost *without* the reader realizing it.

Comment 44

[David Ascher (:davida)]

We could have a global pref of "collapse by default", but I suspect the ideal UX would have it be "collapse long quotes by default", which the current libmime model would make really hard.

I think the most useful kind of persistence would be per-message, per-blockquote persistence.  Which is doable, but strikes me as a  lot of work, again, given the libmime model.  My vote would be to get the feature in w/o persistence, because I think that's a time sink with relatively low payoff.

I'd rather spend the time figuring out how to do something with libmime so that we have more flexibility there on message body stuff (inline image viewers, etc.)  (maybe use the new JS emitter?)

Comment 45

[Peter Lairo]

I agree that sensible defaults are much more valuable than persistence within each message (how often does one go back to a specific message with multiple quote levels?).

Some sensible defaults could be:

[ ] - show 1st quote level and
    - collapse all others

[ ] - show 1st quote level and
    - show the 1st (and 2nd?) line from the 2nd quote level and
    - collapse 3rd and higher quote levels

[x] - show 1st quote level and
    - show the 1st (and 2nd?) line from all but the first quote levels

[ ] - show the 1st (and 2nd?) line from all quote levels

Comment 46

[Magnus Melin [:mkmelin]]

Why introduce a non-standard level attribute on blockquote, when you can do it just as well with regular css selectors (like it used to be)? I don't find that justified just to make the lines shorter. Also, I do hope those aren't something we ever write out to disk, or send out in replies.

Comment 47

[David Ascher (:davida)]

AFAIK, none of this generated HTML ever makes it out anywhere, but I could be wrong.

re: level attribute vs. css selectors, I was mostly worried about performance of nested child selectors, but I'm certainly fine w/ taking it out.

Note that I'm actually generating much more non-standard divs before the blockquotes to support button-like twisties which change image on hover over the twisty (rather than hover over the blockquote).

Comment 48

[Ben Bucksch (:BenB)]

> none of this generated HTML ever makes it out anywhere, but I could be
> wrong.

It does go out in replies, depending on the mode the class is in. There's a "plain" (for Save As) and I think a "quoted" mode (for replies).

> I'm actually generating much more non-standard divs ...
> to support button-like twisties

Yes, it would be nice if we could do without that. That's what my patch tried. Downside is that it has to hardcode the image size.

Comment 49

[Ben Bucksch (:BenB)]

(To clarify, I don't object to the <div>s, as long as they are used only in display cases.)

Comment 51

[Wayne Mery (:wsmwk)]

This issue should be tested in the 115 environment becaues the message reader is being largely rebuilt for version 115. 115 becomes available in July. Testing beta 3-4 weeks from now is possible.

Note also this bug blocks meta Bug 456814 which is being closed.

Comment 52

[Ben Bucksch (:BenB)]

the message reader is being largely rebuilt for version 115

Hey Wayne, could you please cite the bug number for that "rebuild"?

Comment 53

[Wayne Mery (:wsmwk)]

From https://docs.google.com/document/d/10cGsl0JtJcjQya9w6Spk3QEeFzZ8iQyub8KIxGpNwaE/edit?usp=sharing that would be bug 1811379. However after further consideration I doubt that work will impact quote/collapse capability.