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.

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

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.

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();

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

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

Reopen mail/news HELP WANTED bugs and reassign to nobody@mozilla.org

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

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

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?

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

moving out there.

> 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.

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

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.

That's right.

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.

See also bug 66822.

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.

Taking. In <c1ik5m$1j9h0d$1@ID-14284.news.uni-berlin.de> (sorry, in German) I have outlined a possible solution which I'm willing to modify for use within MailNews.

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.

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 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 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!

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

Fix checked in.