The problem occurs within the "languages" sub menu of the context menu of the compose window, where you are supposed to select the right language for spell checking. When I used that menu to select a language in one instance of the compose window, close that window, open a new one and try the menu again the entries in that menu are duplicated and when you repeat that approach the menu keeps growing until a restart of SeaMonkey. Initially the problem occurred for me when I used the English US version of SeaMonkey and had an additional German dictionary installed. However I uninstalled the German dictionary and started SeaMonkey in "safe mode", yet the problem persists, I then get several "English / United States" entries once I used the menu as described above. A screen shot is at http://home.arcor.de/martin.honnen/images/SeaMonkey2011121202.png. At least one other user has confirmed the problem in http://groups.google.com/group/de.comm.software.mozilla.mailnews/browse_thread/thread/505c71f97b940269/be9d4402e9b14d8b?q=group:de.comm.software.mozilla.mailnews#be9d4402e9b14d8b.
This sounds like Bug 688860 which also involve multiple compose windows and spell checking. If you feel confident enough you could try the latest SeaMonkey 2.8a1 builds. But make sure you test this on a separate profile you can thow away if necessary.
I can reproduce this on Linux, with anything from SM 2.2 to current SM trunk (2.9a1). Nothing on the Error Console. Probably an issue with initialization vs. compose window recycling? Maybe Neil knows. SM 2.1 behaves differently; I don't have that menu item there and the Spelling toolbar button is broken. :-/ SM 2.0 doesn't have the menu item either, so I guess it was introduced with SM 2.2. I didn't find anything in the corresponding release notes, though. :-/
The inline spellcheck UI gets reinitialised every time the compose window is reopened. As part of initialisation, it forgets about any menuitems that it added to the context menu... There is a function that removes the menuitems, which would fix the problem, if only there was a convenient place to call it...
Ah of course, the compose recycling listener already removes the suggestions from the menu, so we just need to remove the dictionaries at the same time.
I suppose I should also add [good first bug] in case some one is searching bugzilla for the old GFB whiteboard status.
Created attachment 609123 [details] [diff] [review] Remove entries from languages menu before recreating language list.
Comment on attachment 609123 [details] [diff] [review] Remove entries from languages menu before recreating language list. Review of attachment 609123 [details] [diff] [review]: ----------------------------------------------------------------- ::: suite/common/nsContextMenu.js @@ +332,2 @@ > InlineSpellCheckerUI.addDictionaryListToMenu(dictMenu, dictSep); > } Drive-by nit: With the block reduced to a single line, the braces can go.
Comment on attachment 609123 [details] [diff] [review] Remove entries from languages menu before recreating language list. This isn't the correct way to remove dictionaries form the menu. The correct way is http://mxr.mozilla.org/comm-central/source/suite/common/nsContextMenu.js#476 Note of course that this already exists in nsContextMenu.js, so the problem is specific to the message compose window, because of the way it recycles.
Created attachment 609257 [details] [diff] [review] Remove language entries. (V2)
Once this has landed and verified, we should get this onto both Aurora and Beta.
Pushed to comm-central: http://hg.mozilla.org/comm-central/rev/ea76d70a8e56
Comment on attachment 609257 [details] [diff] [review] Remove language entries. (V2) [Approval Request Comment] Regression caused by (bug #): User impact if declined: Testing completed (on m-c, etc.): Risk to taking this patch (and alternatives if risky): String changes made by this patch:
Pushed to comm-aurora: http://hg.mozilla.org/releases/comm-aurora/rev/3ca7e9109ed3
Pushed to comm-beta: http://hg.mozilla.org/releases/comm-beta/rev/1f375f15344b