11080 - news "spoiler" feature

Status: RESOLVED FIXED

(MailNews Core :: Backend, defect, P3)

Description

[(not reading, please use [e-mail] instead)]

this is something alecf told me about a while back.

basically, if a news message has a certain sequence of characters, the message
should be displayed with a button.  clicking on the button shows the rest of the
message.

it's called the surprise feature or something.

Comment 1

[lchiang]

Alec - can you elaborate on this?  What type of sequence of characters?   Why
would someone want this feature?

Comment 2

[(not reading, please use [e-mail] instead)]

marking m15.

let me explain the feature a little more:

there would be a message, like this:


Q: Why did the chicken cross the road?
\r
A: To get to the other side

When viewed, the A: part would be hidden and there would be button (or
something) that when clicked would show the whole message.

renaming the summary to be "spoiler", as that is what it's called.

Comment 3

[Alec Flett]

we should use the same twisty icon that we use when a mail message has many
recipients to show/hide the recipient list.

Adding rhp to the list because this is really a libmime feature.

Rich, the way seth and I were thinking about this was to basically have a
"surprise counter" in libmime that would determine how many surprises to
display. Each surprise twisty would have an index, when you click on the twisty,
it would look like:

if (twisty.closed)
  surpriseCounter = twisty.index+1;
else
  surpriseCounter = twisty.index
reflow()

then libmime would basically display messages as it normally did, but if it
encountered a twisty, it would do something like:

message.surpriseCount++;
if (surpriseCounter <= message.surpriseCount)
  abortRestOfMessage();

Comment 4

[(not reading, please use [e-mail] instead)]

this should be obvious, but this is a LOW priority feature.  way low.

Comment 5

[Phil Peterson]

Bulk-resolving requests for enhancement as "later" to get them off the Seamonkey
bug tracking radar. Even though these bugs are not "open" in bugzilla, we
welcome fixes and improvements in these areas at any time. Mail/news RFEs
continue to be tracked on http://www.mozilla.org/mailnews/jobs.html

Comment 6

[Phil Peterson]

Reopen mail/news HELP WANTED bugs and reassign to [e-mail]

Comment 7

[Matthew Thomas, usability weenie]

The sequence of characters in question is ^L (that is, Control+L). See
http://www.deja.com/getdoc.xp?AN=524344854&fmt=text for a nice
discussion about its support in other newsreaders. There's no reason
it shouldn't apply to e-mail as well as Usenet, of course.

The usual case is someone talking about a movie or whatever on Usenet,
who doesn't want to annoy those who haven't seen/read it yet. The
lowest-common-denominator solution is to insert lots of blank lines
(liberally marked with `SPOILER SPACE'), so people have to scroll to
see it. ^L is the, uh, more sophisticated solution.

-- mpt

Comment 8

[Garth Wallace]

There should be some easy way of adding a spoiler mark when composing a message, 
too. But that's another bug.

Comment 9

[Garth Wallace]

BTW, spoiler insertion in composition is now Bug #27153.

Also, I wonder how this would affect HTML mail. What happens if there's a ctrl-L
character inside a block element (like <P>, <DIV>, <BLOCKQUOTE>)? Would this
cause a problem with layout?

Comment 10

[John Moreno]

I have a "spoiler" page, which shows how various newsreaders support the spoiler 

char: <http://www.newsreaders.com/spoilers/> (I make no claims as to the 

completeness of the list).



John Moreno

Comment 11

[Scott MacGregor]

moving out there.

Comment 12

[Karl Ove Hufthammer]

> Also, I wonder how this would affect HTML mail.
> What happens if there's a ctrl-L
> character inside a block element (like <P>, <DIV>,
> <BLOCKQUOTE>)? Would this
> cause a problem with layout?

The form feed character is defined as white space in HTML, and should be 
treated as such. In XHTML (XML), the form feed character is forbidden.

Comment 13

[Jesse Ruderman]

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

Comment 14

[Greg K.]

So, let me see if I understand this. Bug 11080 is about Mail/News handling the
spoiler character for display, and bug 27153 is about enabling insertion of this
character in Composer.

Comment 15

[Garth Wallace]

That's right.

Comment 16

[John Moreno]

Yep. I'm not sure how likely 27153 is, as the most useful way of adding 
the ability to insert it is via a menu, and it's my understanding that there is 
some reluctance to add them.  It almost certainly won't get added until 
after this bug is fixed.

PS -- 14 messages with a spoiler char in rasfw on Sep 6.

Comment 17

[mental]

See also bug 66822.

Comment 18

[Garth Wallace]

66822 is only tangentially related. It's unlikely that it would have any impact 
on this bug, or vice versa. Yes, rot13 is sometimes used to hide spoiler text, 
but otherwise it's an unrelated feature.

Comment 19

[Karsten Düsterloh]

Taking.
In <c1ik5m$1j9h0d$[e-mail]> (sorry, in German) I have
outlined a possible solution which I'm willing to modify for use within MailNews.

Comment 20

[Ben Bucksch (:BenB)]

Karsten, the code would probably be the plaintext converter, probably the
generic one, in netwerk/streamconv/converters/mozTXTToHTMLConv, function
GlyphHit, somewhere around "// x^2 -> sup".

I'd either
- just replace the spoiler with <div class="moz-txt-formfeed">, plus CSS that
inserts 100% height *before* the tag
- use alecf's proposal of using grippies, if possible, but then you definitely
need sensibly positioned </div> tags.

Note that you can't use JavaScript, I think, it's usually disabled and the doc
you produce is content, not chrome.

Comment 21

[Karsten Düsterloh]

Attachment: Very simple patch that turn ^L into an empty page

Just turn the spoiler space denoting character ^L (aka \f aka FF) into a <div>
with the new class moz-txt-formfeed and style its height to 100%, thus creating
an empty page within the respective <browser>.
This pattern translation is part of the kGlyphSubstitution.

Comment 22

[Ben Bucksch (:BenB)]

Comment on attachment 142267 [details] [diff] [review]
Very simple patch that turn ^L into an empty page

r=BenB

I'd prefer the Twisties, but it seems they're much harder, given that libmime
feeds the converter line by line.

Comment 23

[Ben Bucksch (:BenB)]

Comment on attachment 142267 [details] [diff] [review]
Very simple patch that turn ^L into an empty page

Actually, the FF char is potentially inline, as shown by the examples, so maybe
use a span in the konverter and turn it into a display: block in the
stylesheet. (No need a for a new patch, you can do what while checking in.)

Thanks for the patch, Karsten!

Comment 24

[John Moreno]

Let me add my thanks for the patch, Karsten: Thanks!  I hope it gets checked in soon.

Comment 25

[Karsten Düsterloh]

Attachment: final patch with BenB's comments

Comment 26

[[e-mail]]

Fix checked in.