66822 - (rot13) implement rot-13

Status: NEW

(SeaMonkey :: MailNews: Message Display, enhancement)

Description

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

tracker bug.

Comment 1

[Daniel Bratell]

Damon Gallaty talks about doing this as a test case for bug 22687.

Comment 2

[scottputterman]

reassigning to [e-mail]

Comment 3

[Matthew Tuck [:CodeMachine]]

The ROT13 algorithm would be only a couple of lines, most of the work would be
in getting it to apply to a message, putting it on the menus, etc.

Comment 4

[Damon Gallaty]

Attachment: ROT-13 source code

Comment 5

[Damon Gallaty]

Attachment: ROT-13 header file

Comment 6

[Damon Gallaty]

Unfortunately, I don't have the time to actually integrate this into the 
MailNews client. It works in the PGP sample that I'm doing for bug 22687, and 
I'll gladly make corrections to the ROT-13 code itself, but someone else needs 
to do the integration, starting with where to put the ROT-13 code in the 
directory structure.

Comment 7

[Gervase Markham [:gerv]]

mpt: Could I have some UI design here, please? Do we want a menu item? Context 
menu item? Mailnews content window only? Do the title as well? Just the 
selection or the whole message? Etc. etc.

I'd guess this is best implemented by getting all the text nodes in the DOM of 
the content window and messing with them individually.

Gerv

Comment 8

[Matthew T (active 1999-2002)]

Certainly, sir.

_View
-----
  _Show                                   >
-------------------------------------------
  _Go                                     >
  Sto_p                               Esc
  _Reload                        Ctrl+U
  {_Load|Re_load} Objects  Shift+Ctrl+U
-------------------------------------------
  Text _Zoom                              >
  _Use {Style|Formatting}                 >
  Text En_coding                          >
-------------------------------------------
  Col_umns                                >
  _Messages                               >
  S_ort Messages ...
  E_xpand Threads                Ctrl+Left
  Collapse _Threads              Ctrl+Right
-------------------------------------------
  _Headers                                >
  _Attachments                            >
-------------------------------------------
  Message _Info/Source           Ctrl+I

(If you want to clean up Navigator's `View' menu in a similar fashion, to make 
it consistent with this, please file a separate bug and make my day.)

Now, for an HTML message we show the `Use Style' submenu; for a plain-text 
message, we show the `Use Formatting' menu instead. Note that this makes the 
dastardly assumption that those people who post in HTML (rather than plain 
text) won't have been clueful enough to use rot-13 in the first place. I think 
that's fairly safe, especially since HTML clients don't tend to allow for the 
creation of rot13-ed text at all.

And the `Use Formatting' submenu looks like this:

_Use Formatting
---------------
/ _Wrap Long Lines
  _Unscramble (rot-13)

Both of these items should apply to the whole message, and both should persist 
across messages. (It's unlikely that we'll come across several rot13-ed 
messages in a row, but if we do, then having to turn it on for each message 
would be very annoying. And the inconsistency with the behavior of `Wrap Long 
Lines' would be noticable.) However, while `Wrap Long Lines' should persist 
across sessions, `Unscramble (rot-13)' should not. The reason for this is that 
if a novice turns rot-13-ing on by mistake, and has no idea how they did it, 
restarting Mozilla should work as a means of `fixing' it. (And *that* level of 
inconsistency with the behavior of `Wrap Long Lines' would *not* be noticable.)

The keyboard access to this consists of Alt,V,U,U, which I think is easy enough 
for such an obscure feature.

This item does not belong in the context menu, because it is neither heavily 
contextual nor extremely common.

Comment 9

[Gervase Markham [:gerv]]

mpt: Thanks for taking the time to do the design; but the spec you've given me,
while wonderful, involves a complete rearrangement of the Mail/News menus,
implementation of five new functions (at least, I can't see them in the current
menus) and rather exceeds the scope of this bug.

If you want the menus reorganised, that's cool, but I am definitely not the
person to do it (I don't have the skill yet), and it's not this bug. Also, it
would be rather handy to get some assurance from Mail/News that they'd take the
patch - otherwise the person who wrote it has to continually fix it to keep up
with the tree while it gets argued over.

I'm happy to do the Use {Style|Formatting} menu to put ROT-13 in, and I could
probably hook up "Wrap Long Lines" as well. But I can't do the rest.

Gerv

Comment 10

[Matthew T (active 1999-2002)]

Sorry, Gerv, I was going to write `You don't need to implement all of this in 
order to fix this bug' ... but I forgot. :-) Just implementing the `Use Style'/
`Use Formatting' switch, with the `Unscramble (rot-13)' item in the `Use 
Formatting' submenu, would be enough. However, it would be good to add `Wrap 
Long Lines' to the submenu too, to avoid having a submenu with only one item.

Eventually, most of the stuff that's currently in the `Message Display' 
category of prefs would go in the `Use Formatting' submenu instead, like so:
  _No Wrapping
* _Wrap Long Lines
  _Rewrap All
----------------------------
  _Unscramble (rot-13)
----------------------------
  Highlight _Links
  Highlight *_Styles*
  Graphical _Emoticons :-)

Comment 11

[Matthew T (active 1999-2002)]

See also bug 77243.

Comment 12

[Gervase Markham [:gerv]]

I've got this working; I'm just thinking at the moment about ROT-13 for Unicode 
;-)

Gerv

Comment 13

[Karl Ove Hufthammer]

> I've got this working; I'm just thinking at the moment
> about ROT-13 for Unicode ;-)

Don't.

Comment 14

[Gervase Markham [:gerv]]

huftis: Do you want to be more enlightening? I think I've come up with a 
workable scheme. What's wrong with the idea? Why is it that only jokes in ASCII 
can have their punchlines hidden? :-)

Gerv

Comment 15

[Karl Ove Hufthammer]

> huftis: Do you want to be more enlightening?

It will break *both* backwards and forwards compatibility:

1 Backwards compatibility:
  ROT-13 is designed to rotate the characters A-Z 13 characters
  (with wrap-around), and leave everything else alone. This means I
  can write "Ærlige Åse har øydelagt låven" and have it encoded
  and decoded correctly with ROT-13. This is used in ISO 8859-1
  newsgroups and e-mail. If Mozilla changes the way this works, it
  will break *very* many messages already ROT-13-ed ("Mozilla doesn't
  even support ROT-13 properly!").

2 Forwards compatibility:
  If you implement ROT-49194 for ISO 10646, this won't work correctly
  when 10646 is updated to Unicode 3.1 (ROT-94140)
  <URL: http://www.unicode.org/unicode/reports/tr27/ >.

Comment 16

[Gervase Markham [:gerv]]

My idea is to use palindrome - for each contiguous range of letters, you reverse 
it. This makes it reversible by the same algorithm, by ROT-13.

The backwards compatibility problem is solved by excluding from the above all 
letters which are used to augment the simple Latin alphabet. Languages such as 
Norwegian are already obscured enough by the standard ROT-13 algorithm.

I don't quite understand your point about forwards-compatibility. I was planning 
to use the character values as given in Unicode 3.1. Would this cause a problem?

I thought we could check it in for a bit; if it turned out to cause problems, 
we'll have a rethink or take it out. But, as long as we are careful about 
Latin-esque character sets, I don't see a problem.

Gerv

Comment 17

[Karl Ove Hufthammer]

> My idea is to use palindrome - for each contiguous
> range of letters,

So "Mozilla" should be "allizoM"?

How are word boundaries decided? Not all languages use a normal space as a word
boundary.

> The backwards compatibility problem is solved by excluding
> from the above all letters which are used to augment the
> simple Latin alphabet.

You mean all characters in Latin-1 (iso-8859-1)?

> I don't quite understand your point about forwards-compatibility.
> I was planning to use the character values as given in Unicode 3.1.
> Would this cause a problem?

If you write all words backwards (palindroming them), it won't be a problem. But
you really shouldn't call it 'ROT-13' then.

Comment 18

[Gervase Markham [:gerv]]

> So "Mozilla" should be "allizoM"?

No - sorry for not being more clear. Say Unicode defines character codes 1000 to 
1010 to be letters - 1010 would become 1000, 1009 would become 1001, etc. 1005 
would be unchanged (this happens if the range has an odd number of chars in it.)

This is "similar" to ROT-13. The reason you can't do "rotate by X" where X is 
half the range is because, although it would be more similar to the ROT-13 
mechanism, it breaks when the range has an odd number of characters. I suppose 
you could exclude the last one from the rotation (like the middle one in odd 
palindromes) but I think the palindrome thing is more elegant. Either would 
work, though.

> You mean all characters in Latin-1 (iso-8859-1)?

I hadn't yet worked out exactly which chars to exclude - but this may well be a 
good way to decide. This would take a bit of tuning depending on feedback before 
we finalised.

Gerv

Comment 19

[Karl Ove Hufthammer]

> No - sorry for not being more clear. Say Unicode defines
> character codes 1000 to 1010 to be letters - 1010 would
> become 1000, 1009 would become 1001, etc. 1005 
> would be unchanged (this happens if the range has an
> odd number of chars in it.)

Since the Unicode ranges has "holes" in them, this won't work. Example:

   1157;HANGUL CHOSEONG KAPYEOUNPHIEUPH;Lo;0;L;;;;;N;;;;;
   1158;HANGUL CHOSEONG SSANGHIEUH;Lo;0;L;;;;;N;;;;;
   1159;HANGUL CHOSEONG YEORINHIEUH;Lo;0;L;;;;;N;;;;;
<Hole>
   115F;HANGUL CHOSEONG FILLER;Lo;0;L;;;;;N;;;;;
   1160;HANGUL JUNGSEONG FILLER;Lo;0;L;;;;;N;;;;;
   1161;HANGUL JUNGSEONG A;Lo;0;L;;;;;N;;;;;

And these hole may be filled in future version of Unicode.

Comment 20

[Gervase Markham [:gerv]]

Hmm. It would still work - it would just mean that the standard would have to be
specific about the ranges. That is to say, instead of saying "do the reversing
thing on all letter ranges" you could say "do the reversing thing on the
following letter ranges:". That's how it's implemented, after all - the code has
a big array which gives the start char and end char of each range to reverse. We
are going to have to do this anyway because "all letter ranges" will include the
Latin-1-augmenting chars we've decided to exclude.

Alternatively, we could say that any new characters that were to be added to
Unicode now would be so totally obscure that we could just do nothing with them
- i.e. treat them as punctuation - without any ill effect.

I did mean to have this discussion in a newsgroup somewhere... shall we move it
there? Say n.p.m.i18n?

Gerv

Comment 21

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

I hate to be a killjoy, but is hacking on rot-13 the best use of your time?

as one of the mailnews module owners, I'm not interested in this right now.

I'd much rather see work being done on bad p1 bugs, crashers, or features that
people are really asking for.

If rot-13 is the only thing you're interested in working on (I hope not),
consider helping to get the PGP patch into better shape.

Damon [the author of the current (in progress) PGP patch] had used rot-13 as his
test "plugin" to mailnews.  That seemed like the right way to go.  You'd get
rot-13, and users would have a way to drop in PGP support (when it was all done).

Damon is interested in doing what's necessary to get PGP support into mozilla.
let's work on that first.

Comment 22

[Gervase Markham [:gerv]]

Hey, I was just messing around one night. Anyway, we have to have this for 
historical reasons :-)

I'll clean up a non-Unicode version and attach it, and go and do something more 
constructive.

I thought we were blocked on the PGP patch? /me checks again.

Gerv

Comment 23

[Gervase Markham [:gerv]]

Attachment: Patch

Comment 24

[Gervase Markham [:gerv]]

OK, here's my work so far. It's just a menu item on the View menu, although it
could easily be moved. The one bug is that the ROT-13 checkmark on the menu
persists from message to message but the ROT-13-ness doesn't, because I couldn't
figure out where to add the extra call to MsgRot13() - i.e. what JS is called
when you select a new message.

If I get more time (or if someone gives me a clue), I'll come back to this - in
the mean time, it's back to being helpwanted.

Gerv

Comment 25

[Gervase Markham [:gerv]]

sspitzer: 

Would it not be sensible for me to sort out this code so we can have ROT-13 in
Mozilla reasonably soon, rather than waiting for all the stuff related to the
PGP bug? We can always remove it later.

Gerv

Comment 26

[Gervase Markham [:gerv]]

sspitzer: ping :-) 

I have a Javascript ROT-13 ready to go, which we can have this week. Given the
uncertain future of the PGP-related stuff, wouldn't it be good to do this?

Gerv

Comment 27

[Gervase Markham [:gerv]]

I still need a Mail/News guru to tell me the name of the JS function which is
called when the message pane loads a new message...

Gerv

Comment 28

[David :Bienvenu]

You want to be notified after message gets loaded, right? This is an async
operation so hooking up to the place where we start to load the message doesn't
do you any good, right? I'm not sure there is an actual notification for this
event, though there should probably be one.

Comment 29

[Håkan Waara]

As I understood it, this feature was disapproved to get implemented in mailnews
code now (we've got too much code to fix already, let alone implementing
new...), per Seth's 2001-04-27 11:05 comment.

Comment 30

[Gervase Markham [:gerv]]

Bienvenu: You are probably right, yes. Does this mean getting this to work 
requires someone to implement this event? How hard would it be?

Hakan: that comment was based on a view that Damon's PGP stuff would make it in 
pre-Mozilla-1.0. 

Seth may tell me that he doesn't want this feature because it's not a feature 
Mozilla Mail should have. I'll disagree with him, but he could say that. But he 
can't say "I'm not accepting this feature because you, Gervase, should have been 
working on something else." I'll work on what I want to work on. :-)

Gerv

Comment 31

[Håkan Waara]

Fyi, generally, module owners can disapprove patches. I thought that's what he did.

Comment 32

[David :Bienvenu]

Gervase, yes, someone would have to implement this event. It's a good event to
have in general, but it would require some work, and quite possibly it would be
protocol-specific, i.e., need to be implemented for each kind of folder. My
guess is that we would have to implement it by adding code in ::OnStopRunningUrl
that checked if the running url was a message load url, and in that case sending
the notification. Checking if a url is a message load will probably be
protocol-specific.

Comment 33

[Gervase Markham [:gerv]]

Well, the simpler solution would be to make ROT-13 non-sticky - i.e. it doesn't 
persist over message changes. 

mpt: you were the one who wanted it sticky. Would you be happy with non-sticky?

Gerv

Comment 34

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

sorry for the delay gerv.

4.x had it so marking 4xp.

I don't think it is in the mailnews specs, so before we consider adding it we
need to run the idea by jglick.

no one really seems to be dying without it, so it isn't a high priority.

Comment 35

[Matthew T (active 1999-2002)]

> mpt: you were the one who wanted it sticky. Would you be happy with non-sticky?

Well, it would be marginally better than not having it at all. :-)

Comment 36

[John Moreno]

I think that you (mpt) are mistaken about it being best as a persistent 
setting -- it should apply only to the current message.  It's most often used 
in humor groups to hide the punch-line, going from message to message 
you don't want to see the punchline before you see the joke.

Comment 37

[Aleksander Adamowski]

What about ROT-13 scrambling of selected text in the Compose window? I'd  see it
this way: when a portion of text content is selected, I can use a menu item
called "Scramble selection (ROT-13)". 
It would be placed in the Edit menu and, possibly, in the context menu for the
selection.

Edit menu would look like this (fragment):

...
Paste As _Quotation
_Delete                Del
_Scramble selection (ROT-13)
=============================
Select _All            Ctrl+A
=============================
...

Comment 38

[Aleksander Adamowski]

In the far future, we might think about multiple scrambling routines. We'd have
a Submenu called "_Scramble" with items like "_ROT-13", "_ROT-Mozilla",
"ROT-Gerv"... :)

Comment 39

[Gervase Markham [:gerv]]

I plan to revive this feature as a non-sticky, do-the-whole-message,
message-window-only thing. Someone else may like to take the common code and add
a context menu item to ROT-13 the selection in the Compose window, but that's a
different bug.

Future menu redesigns aside, where should it go in the current menu structure?

(Re: Multiple scrambling routines - no.)

Gerv

Comment 40

[Gervase Markham [:gerv]]

Feature - pushing out.

Gerv

Comment 41

[Ben Bucksch (:BenB)]

I found some code for rot13 in libmime, in mimetext.cpp. Dunno. how it's
triggered, though.

Comment 42

[mental]

Bug 11080 suggest using ^L for spoiler protection, and bug 27153 suggests
composer changes for this.  Let's keep those in mind to keep the UI consistent.

Comment 43

[Frank Schönheit]

Seeing that there is a javascript-based patch which enables ROT-13 in a
non-sticky way, and seeing the 24 votes for this bug, I wonder if we could just
live with the non-sticky behaviour (at least for the moment, though I'm not
really sure if stickyness is what you want here).
This may require to find a new location in the menu, to avoid the inconsistence
compared to line wrapping, but this shouldn't be too difficult.

Comment 44

[Tobias Löfgren]

I've implemented Gervase Markham's patch as a itty bitty small XUL Application
available for download/install at http://www.pinkroom.biz/owl/minirot13/ , a bit
cleaner than messing around with the mozilla source itself.

It is not sticky (I really don't think it should be) and as an added feature
it's able to encrypt selected text when composing your own message. 

Have a look and please tell me if I'm doing something stupid, it's my first
venture into XUL and mozilla hacking.

Comment 45

[Christian Emig]

works perfectly here

Comment 46

[Frank Schönheit]

works perfectly here, too (Windows NT)

Is there any chance to get this into Mozilla as patch instead of an external
addon Perhaps after we got some more confirms?

Comment 47

[Vincent Jaubert]

I have tested it on build 2002031608 on winxp.
The problem is that when the plug-in installed, it becomes impossible to compose
a new message.

Comment 48

[Dash]

Works perfectly on build 2002031608 Win2K

Comment 49

[Vincent Jaubert]

About my comment #47.
I did the test again with build 2002031903. Now it works.

Comment 50

[Katja Hoffmann]

Works perfectly for me - Build 2002031104, Win98 

Comment 51

[Aleksander Adamowski]

I'm crashing on Linux when launching MailNews...
Build 2002032008-trunk.

Talkback ID:
TB4302108Y

Comment 52

[Aleksander Adamowski]

A correction to my comment #51:
Actually, the main problem is that the MailNews window gets messed up (all panes
are empty, threadpane doesn't fit in properly). Screenshots coming.

The crash occurs when I try to drag a border between any two panes.
Talkback IDs:
Crash when dragging a border in the first 3-pane layout: TB4306053H
Crash when dragging a border in the second 3-pane layout: TB4305663Z

Comment 53

[Aleksander Adamowski]

Attachment: MailNews window in the first 3-pane layout mode after installing Tobias' rot-13 application

Comment 54

[Aleksander Adamowski]

Attachment: MailNews window in the second 3-pane layout mode after installing Tobias' rot-13 application

Comment 55

[Aleksander Adamowski]

I also get the following error in the JavaScript Console:
Error: column has no properties
Source File:                    Line: 18

Comment 56

[Tobias Löfgren]

Just taking a small guess here: the problem reported in comment #52 looks a bit
like what I encountered when mozilla didn't update chrome.rdf and the
overlayfiles to handle the dynamic overlays of the xul-app. If so it can be
resolved by shutting down mozilla and deleting the file chrome.rdf and the
overlayinfo directory in the chrome/ -path. They will then be correctly rebuilt
when restarting mozilla. 

MORE IMPORTANT: Not that I won't be checking in on good ol bug 66822, but my
little addon isn't a part of the mozilla source so maybe further discussions
regarding this add-on doesn't really belong in this forum? Especially since it
might behave in unexpected ways with new versions of mozilla, without it being
mozilla's fault.

Please contact me by email instead if you have questions, bugfixes or problems!

Comment 57

[Jay Patel [:jay]]

Aleksander:  There is another bug logged with a similar stack to your recent
crashes.  Did you try logging into a pop account?  If so, it might be bug 132597.   

Comment 58

[Aleksander Adamowski]

JPatel, no, I even can't reproduce bug 132597 on my machine when minirot13 isn't
installed.
When I install it, well, I'm unable to use MailNews and login to a POP3 account.

Comment 59

[Aleksander Adamowski]

Now everything is clear!
It is a problem with file permissions.
First, the addon works OK if running Mozilla as root.
It doesn't work for other users.
Second, I didn't notice before that an error message is shown on the terminal
when launching MailNews:

*** Failed to load overlay chrome://minirot13/content/messageOverlay.xul
Warning add child failed!!

This explains everything. It is a problem with file permissions.
I've just verified that during installation the file chrome/minirot13.jar is
created with permission mode 400. That means read permission for owner (root),
no permiss
ions for owning group, no permissions for other users. The file should rather be
created with mode 644 (read,write for owner, read for owning group, read for
others), just like all the other files in chrome/ directory.
If on my system I execute
chmod 644 /usr/local/mozilla/chrome/minirot13.jar
then MailNews for all users on this machine is OK and rot-13 in the context menu
works like a charm :)

That might also shed new light on bug 132597. Since it has a similar stack
trace, maybe it's also a problem with file permissions to Mozilla files
somewhere? For example to Classic skin chrome files in affected builds? I cannot
reproduce that bug, though, using the recent build (2002032508-trunk).

Comment 60

[Aleksander Adamowski]

The permissions problem is probably due to bug 111124.

Comment 61

[[e-mail]]

Attachment: Some JS rot-13 code you might like

This code demonstrates using XPath iterators, regular expression functions and
even tries to preserve editor formatting - although I see lots of exceptions
:-(

Comment 62

[Gervase Markham [:gerv]]

That's very smart, but at first look I suspect it'll be quite inefficient -
calling a function for each character can't be good.

Gerv

Comment 63

[[e-mail]]

You mean for each letter. Your method processes each character...

Comment 64

[Jesse Ruderman]

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

Comment 65

[Nico Dummer]

Attachment: rot-13 plugin i found on a website

This is the Website where i got the plugin.
http://www.hmetzger.de/tips6/rot13.html

Comment 66

[Gervase Markham [:gerv]]

Sorry, I'm not going to get to this.

Gerv

Comment 67

[Jonas Jørgensen]

clearing target milestone since this has no owner

Comment 68

[Lapo Luchini]

I don't understand the comments madness about "new obfuscating schemes".
This bug is about ROT-13.
ROT-13 is a "standard" at least in newsgroup anti-spoiler.
We could of course create a "generic trasformation function" in that menu and
having ROT-13 just as a "specific case" (other useful cases would be conversion
between codepages maybe) but that would be a different bug on which this would
be dependant, of course, but a different bug.

Comment 69

[Daniel Furrer]

Wouldn't it be possible to just implement a new Character Coding which is like
ROT-13?

Comment 70

[Garth Wallace]

re comment #69: that sounds like a case of severe overkill. What possible
purpose would that serve? Besides, rot13 s frequently used for small parts of a
message, not just whole messages.

Comment 71

[Grey Hodge (jX)]

Attachment: ROT13 Bookmarklet

Jesse Ruderman and myself have whipped up a bookmarklet to ROT13 a highlighted
passage in-situ. As a whole, it's about 992 bytes, in one line (as bookmarklets
need). I've attached it. It would seem to me that all we need now is a
button/menu-command to attach it to.

Comment 72

[[e-mail]]

Attachment: minirot13.js

I quite liked the ROT13 plugin but I've modified the JS to work with a
selection,
and I've also had a crack at preserving editor formatting but I keep running
into weird editor behaviour which I don't understand.

Comment 73

[R.K.Aa.]

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

Comment 74

[Matthias Versen [:Matti]]

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

Comment 75

[Stewart Gordon]

Re: Description

Why is "tracker bug." all this bug has for a description?

Re: early comments

What would be the point of ROT13ing a whole message?  The purpose of ROT13 is to 
conceal parts of a message that certain people might not want to read (potentially 
offensive content, spoilers) or at least not immediately (punchlines).

If they don't want to read the message at all, they can just not open it.  There's no need to 
ROT13 the whole thing as an extra step.

Comment 76

[Mats Palmgren (inactive)]

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

Comment 77

[Stewart Gordon]

In the meantime, anybody who'd like a ready-to-use ROT13 coder can go here
(requires a JS-enabled browser):

http://smjg.port5.com/faqs/usenet/rot13c.html

Comment 78

[Asa Dotzler [:asa]]

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

Comment 79

[Jens Müller (:tessarakt)]

I'd like to nominate this for blocking  Bug 176238.

Comment 80

[Joshua Cranmer [:jcranmer]]

(In reply to comment #79)
> I'd like to nominate this for blocking  Bug 176238.

Nomination for that belongs in bug 176238, and mostly rests with Felix. I don't think it would be accepted, per bug 176238 comment 25. In particular, comment 14 of that bug is also key: "This is not a general tracker for enhancement requests."

Mnehny--a widespread extension that adds many news features--supports ROT 13.