tracker bug.

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

reassigning to nobody@mozilla.org

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.

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.

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

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.

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

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 :-)

See also bug 77243.

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

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

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

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

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

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

> 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

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

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

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.

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

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

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

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

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

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.

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.

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

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

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.

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

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.

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

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.

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

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"... :)

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

Feature - pushing out. Gerv

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

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.

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.

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.

works perfectly here

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?

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.

Works perfectly on build 2002031608 Win2K

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

Works perfectly for me - Build 2002031104, Win98

I'm crashing on Linux when launching MailNews... Build 2002032008-trunk. Talkback ID: TB4302108Y

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

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

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!

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.

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.

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

The permissions problem is probably due to bug 111124.

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

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

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

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

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

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

clearing target milestone since this has no owner

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.

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

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.

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.

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.

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

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

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.

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

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

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

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

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