Closed Bug 56301 (spellchecker) Opened 20 years ago Closed 17 years ago

connect a spellchecker engine for Mozilla


(Core :: DOM: Editor, enhancement, P3)






(Reporter: rcassin, Assigned: mkaply)


(Depends on 1 open bug, Blocks 1 open bug, )


(Whiteboard: Please do not add comments unless you want to implement (code) something)


(12 files, 20 obsolete files)

3.82 KB, text/plain
5.69 KB, text/html
5.69 KB, text/html
1.85 KB, text/plain
251.23 KB, application/x-xpinstall
251.27 KB, application/x-xpinstall
307 bytes, text/html
251.36 KB, application/x-xpinstall
20.51 KB, application/octet-stream
268.69 KB, application/octet-stream
252.67 KB, application/x-xpinstall
14.02 KB, text/plain
The editor needs spell checking. It's a really nice feature that Mozilla still 
I'm working on this, and I plan on using ASpell (open source spell checker).

Accepting bug.
Go, Hurricane, go!

(And thanks to Netscape for opening the source to the spell checker UI.)
Target Milestone: --- → mozilla0.9.1
Blocks: 63059
63059 is a dup of bug 16409 - ""[RFE] invoke spell check in browser window"
16409 is a "helpwanted".

It seems this bug too (56301) is really a dup of 16409. Please mark as such if
you agree, and assign or adjust dependencies in accordance with bug 16409.
Blocks: 16409
> It seems this bug too (56301) is really a dup of 16409.

No, this bug is about the Editor (Composer), the other one about the browser
No longer blocks: 63059
No longer blocks: 16409
Shouldn't this have the "4xp" keyword?
Severity: normal → enhancement
Keywords: 4xp
is this done yet?  I see spell checker for the editor in a resent netscape
commercial build.   what needs to happen to get this bug wrapped up?
is there time to do it in the next week or so.  if not lets retarget
to a better/more accurate milestone.
This bug is a request for an open source spellchecker implementation of the
nsISpellchecker interface.

This isn't referring to the proprietary spellchecker used in netscape commercial.

My guess is that this won't make it for Mozilla 0.9.1, right Ryan? How about
moving this to Mozilla 1.0.1? Or do you think you'll get it in before Mozilla 1.0?
I don't know if our current plan to use PSpell is practical, since it doesn't 
compile on Mac (it'd have to be ported). At any rate, this bug won't make it 
until at least Mozilla 1.0, and a more practical target is Mozilla 1.0.1

What do you folks think? Should I work on this to get it implemented even if it 
means just Linux and Windows users benefit?

Additionally, I'm not entirely sure that PSpell can be used in Mozilla?'s 
released under the LGPL and, last time I checked, the author has no plans to 
change the license to MPL.

A few things need to be ironed out before any serious work gets done in this 
department. Input is appreciated.
Target Milestone: mozilla0.9.1 → mozilla1.0.1

Is there a port of PSpell for OS X? Perhaps just get it to work in the Carbon 
Fizilla build of Mozilla.
As far as I know, it only compiles under linux, unix, bsd, solaris, and windows 
(but cygwin must be used). It doesn't work under any MacOS environment, be it 
Classic or OS X.
I think we're fine if we use it in Mozilla, regardless of the fact that Pspell 
is under the LGPL. Looking at:
"Even though you the LGPL license gives you the right to use Pspell in your 
application without ever notifying me..."

And the author of PSpell seems to be aware that we plan to use his project in 
Mozilla on his site, See the "Where Pspell is 
Used" section. Mozilla is mentioned in "In the Planning stages"

So, even if we do have authorization from the author to use Pspell in Mozilla, 
is it a must to have the code MPL'd?
OS X is a port of BSD. Where can I get the BSD source (link)? I'll try to build 
it on my Mac.
Built nicly in OSX, just like on BSD. I'm assuming that if it built correctly 
(without errors) it should run okay?
Yeah, that's a safe assumption :) ...I'll get to work putting spell checking
into Mozilla then.

Thanks! :)
I'd also like to add my two cents. I'm not quite sure how spelling is 
implemented now in Netscape 6, but it would be nice if misspelled words received 
a specific CSS style so that they could stand out in the document as they do in 
4.x with red dotted underlines. It would also be cool if text areas could do 
this..but aren't they just Ender objects anyway?
I believe I have bugs on my list somewhere, that cover those 2 issues you mention.
See: RFE: Need realtime spellchecking mechanism
I'm not a license guy, but LGPL might be compatible with Mozilla. Check/post on
*** Bug 83469 has been marked as a duplicate of this bug. ***
Depends on: 58615
I really think we should use the C interface for pspell since the C++ interface 
has binary compatibility problems.
*** Bug 86184 has been marked as a duplicate of this bug. ***
Blocks: 69687
No activity on this recently and a 1.0.1 target- I know the schedule's hurried
and everybody's overloaded, but I don't think we can ship a 1.0 product without
spell checking without getting mud in our faces. People need this feature badly
and many users aren't likely to migrate simply for this reason. Maybe you should
publish some sort of specification which the spell checker needs to conform to
for your interfacing needs and see if you can attract some opensource community
attention to it.
I completely agree with Daniel.  As a professional, spell checking is something
I require.  Currently, I am writing my emails in word, and copying them into
mozilla to send them.  This really doesn't work too well as you might imagine,
especially since I have an older computer & running Mozilla and word at the same
time.  We've already taken enough media flack for our schedule (which is
rediculous if you ask me).  This is just another pr problem waiting.  Just
wanted to get my $0.02 in. 
media? pr? This is a development project. There are no end-users, and there is
supposed to be no press reporting about how well Mozilla works for end-users.

> As a professional

If you are a professional, then you are welcome to code the spellchecker
support. Otherwise, please don't add comments about how important it is - we all
know that already. We need somebody to *do* it.
Just an extra thought. 

I am no software expert, so what I am saying could be completely wrong, but
there might be something useful. As many of you know the W3C produces a web
browser/editor called amaya, which is open source. Well amaya includes a
spellchecker and has spellchecker dictionaries for several languages. However I
don't know about the type of license amaya i.e. is it open source that could be
used in other programs like mozilla or is it a restricted open source?

In the case this were viable the spellchecks for languages other than english
can be found at
Amaya's license is at
and requires "Copyright © [$date-of-software] World Wide Web Consortium,
(Massachusetts Institute of Technology, Institut National de Recherche en
Informatique et en Automatique, Keio University). All Rights Reserved." to be inserted, their own license included,
and a listing of all changes made to the source- not something we can use.
Aspell/Pspell is, in my opinion as in that of most here, the way to go; it needs
porting, and I don't have the ability to do that (especially to Mac OS X) and
I'm wondering how we can best get the word out that the best Linux/Unix spell
checker needs porting and the ability to interface with our favorite lizard.

Ben, if you think that this is a developers only project, I'm afraid you're
quite mistaken. Taking a poll of all those who use Mozilla, even of just those
with Bugzilla accounts, would reveal that many end users are trying to use this
as their primary browser. And perhaps Brian's field of work is not spell checker
interface programming. Please try to be a little patient with him and the rest
of us- it won't benefit anyone to turn this into a flame war or shouting match.
hrm, personally i started hacking on amaya's spellchecker and didn't find any 
serious license issues, I also know that we have other code in the tree which 
requires the same sort of notice as daniel jensen referenced [I think I own the 
bug to fix about to honor them ...]
*** Bug 99309 has been marked as a duplicate of this bug. ***
About Mac OS X: Apple provides a spell checking framework on OS X. (Bug 86886)
Mac OS 9.x and earlier: the Word Services Apple Event suite provides a spelling
checking architecture. See Bug 67208.
Just a thought, but has anyone looked at the spell checker that comes with the
GPL'd Star Office?  I've always thought the Star Office spell checker to work
quite well.
*confusion error* StarOffice is *NOT* GPL. OpenOffice is being developed under
an open source licensing policy. StarOffice is to OpenOffice as Netscape6 is to

AFAIK the SpellChecker is not open source for the same reasons netscape's isn't.
Too bad.  This would have been a great solution. 

Open Office 638c DOES include a spell checker:

It is indicated that it was added by community members:

The Open Office License is GPL, LGPL, or SISSL (Sun Industry Standards
Source License).

I think I read the Star Office spellchecker was not owned by Sun and could not
be released to Open Office. The current one in Open Office was community
Looks like the spell checker in Open Office is based on ispell/pspell and
"builds on almost any system":
odd, i was almost positive ispell was *GPL.  it appears to be BSDL.

whatever, if anyone wants to work on a MPL compatible spellchecker feel free,
there's no one stopping you and will probably answer any
questions you may have.

Mitchell: is SISSL MPL compat? i can't remember
No, I odn't htink we want SISSL code in the mozilla tree.  But I cna try and
talk with the open office folks and see if we can find some answer.
From the FAQ:
   1. Which license does the project use? uses a dual license strategy for the source code. These
licenses are the GNU Lesser General Public License(LGPL) and the Sun Industry
Standards Source License (SISSL).

 The LGPL AND the SISSL. You get to choose. So this should still be a good
choice given LGPL can be made into GPL code.
There is also international ispell, which is under the University
of California license (a.k.a., Berkeley license), and has the
additional advantage of international support.  

However, is the Berkeley license compatible with MPL?
Most software under a "Berkeley license" has been relicensed under the
BSD License, version 2, which has only three terms.  In summary:

1. Include the copyright notice, permission notice, and disclaimers in the
   source files that contain code under BSDL 2.
2. Include the copyright notice, permission notice, and disclaimers in the
   help file.
3. Don't claim that the author endorses your product.


The actual text of the license: (labeled General)

Most of Mozilla is licensed under the "Netscape JavaScript" license (disjunction
of (L)GPL and NPL).  I am not a lawyer, but I don't see any incompatibility
between BSDL 2 and NPL, and RMS says that BSDL 2 is compatible with GNU GPL 2.
However, BSDL 1 (the old four-clause version with clause 3 referring to
advertising) is incompatible with GNU GPL 2.

See also LGPL and GPL are both 100% unacceptable <period>. That's
why i asked about the other license.

[IANAL nor do I represent] BSDL is fine, we have code that uses it,
so does microsoft, so does linux.
Hang on, GTK+ has a LGPL licence, and Moz is linked against that. Why can't we
link against the LGPL pspell?
Please, people.  This is a bug reporting tool, not a bulletin board.  Discussion
belongs in the newsgroups.  Read before you post.


I want a spell checker as much (or more!) than any of you, but this isn't
getting us anywhere.
*** Bug 106877 has been marked as a duplicate of this bug. ***
I think this can be interesting for who check the bug for the first time.
Shouldn't this bug belong to the MailNews product and not the Browser product ?
The Editor (called also Composer) is not part MailNews. It's the HTML editor. As
  both it and the MailNews compose window use spellcheckers, I believe the
component chosen is correct.

Ok, to make it clearer : shouldn't this bug be categorised in the MailNews
product line AND the Composition component ? Just like most of the bugs related
to spellchecking (109127, 69687, 89296...) ?

Even if the Editor component is based on the browser, this is not a rendering
issue but a composition issue. If I wanted to vote for this bug, I would
definitely put the MailNews keyword in my query and I wouldn't find it (but I
would find some dups of this bug). Perhaps are we loosing useful votes for this
bug as well as a better exposure.

I might have a wrong reasonning when I think that spellchecking is directly
related to e-mail and remotely related to browsing and rendering issues. If so,
then I would suggest
moving the "Check spelling before sending" from the "Mail&News/Message
composition" pref pane to the "Composer" pane. Just to make the UI consistant ;-)

Editor (aka Composer) bugs are tracked in the Browser component. Bugs are filed
where the code is (and which people work on it, consequently), not where people
look for them. There is no way to file one bug in 2 products.

Adding relnote keyword. He have hundreds of questions about it. Maybe a relnote
will help.

ALL: Please do no add comments unless you want to implement (code)
Keywords: relnote
Whiteboard: Please do no add comments unless you want to implement (code) something
I still plug away at this one, give it some time and I'll have it. Others remain 
welcome to try their hand at it though :)
I have managed to get a slightly mangled version of Kevin Hendricks' MySpell
mostly working in Mozilla.  Myspell is a simple straightforward spell checker
loosely based on ispell, and used by OpenOffice.  There is still a bunch of work
that I need to get done before it is anywhere near presentable.  I do have a
bunch of questions.

Where should the dictionaries, both system and presonal go?

How do multiple dictionaries work?  I can't get more than en-US into the combo
box. I can't see why. Yo no hablo javascript.

Right now the dictionary gets loaded each time you activate spell checking.  Is
there some way to make it load the hash table once and use it as necessary?

Are there threading issues I should worry about? I don't believe so, but...

Is there a way to get from an nsIFile to  an nsInputFileStream without
extracting the filename and making an nsFileSpec?

Is there any new documentation on the new string classes?  The spell checker is
still doing a fair amount of work on char*.  Convince me that using
nsAFlatCString is worth the additional typing.  

It appears that there is no way to access the unicode equivalents of isalpha,
isupper, islower, or even nonAscii versions of these. These are used, at least
in english for lookup, wordbreaking, and suggesting.  From what little I know of
other european languages, they would be useful there as well.  I can allow for
non european character sets, but I want to have some idea as to what sort of
word-breaking, suggestion making and whatever you call lowercasing capitalized
words algorithms are needed.  Or is this all something that is taken care of by
some localization library?
> Where should the dictionaries, both system and presonal go?

For the netscape implementation of the spellchecker, we put the spellchecker dll
and the dictionaries it relies on in the components/spellchecker directory. 
This has the benefit of allowing the spellchecker to be autoregistered the next
time mozilla is started, if it was not previously installed.

The user dictionary should be written out to the user's profile directory since
that is probably the only place you will have write access on most platforms.

> How do multiple dictionaries work?  I can't get more than en-US into the
> combo box. I can't see why. Yo no hablo javascript.

Are you returning more than one dictionary name from your implementation of the
nsISpellChecker GetDictionaryList() method?

If you are, you may have to put some dump() calls in the InitLanguageMenu()
function in mozilla/editor/ui/dialogs/content/EdSpellCheck.js to see what's
going on.

> Right now the dictionary gets loaded each time you activate spell checking.
> Is there some way to make it load the hash table once and use it as necessary?

> Are there threading issues I should worry about? I don't believe so, but...

There shouldn't be any threading issues.

> Is there a way to get from an nsIFile to  an nsInputFileStream without
> extracting the filename and making an nsFileSpec?

I think so, check out

it can create an input stream based on an nsIFile.

> Is there any new documentation on the new string classes?  The spellchecker
> is still doing a fair amount of work on char*.  Convince me that using
> nsAFlatCString is worth the additional typing.

The spellchecker code/interface was done several years ago (in march/april 1999)
before any of the XPIDL/JS string classes existed so that's why the interfaces
use PRUnichar*.

> It appears that there is no way to access the unicode equivalents of isalpha,
> isupper, islower, or even nonAscii versions of these. These are used, at least
> in english for lookup, wordbreaking, and suggesting.  From what little I know
> of other european languages, they would be useful there as well.  I can allow
> for non european character sets, but I want to have some idea as to what sort
> of word-breaking, suggestion making and whatever you call lowercasing
> capitalized words algorithms are needed.  Or is this all something that is
> taken care of by some localization library?

I know we have some of these utilities, for example, I know there's an
nsIWordBreaker and nsICaseConversion interface, which you can get a hold of
somehow via the document. might be able to help you with
these questions.

I should also mention that I've been thinking that we need to simplify the
spellchecker API, and push the responsibility for wordbreaking, selecting,
scrolling, and replacement out to the app/caller.

The new spellchecker api I'm thinking of would be simple and just contain a
CheckWord() method as well as the existing methods for manipulating and getting
info about the dictionaries used by the implementation, with the addtion,
perhaps, of allowing the word to be looked up in multiple dictionaries at once.

In any case removing the reliance on TextServices, not having to manage
selection and replacement, etc, would greatly simplify the implementation of new
spellchecker backends for mozilla.
>> Is there any new documentation on the new string classes?  The spellchecker
>> is still doing a fair amount of work on char*.  Convince me that using
>> nsAFlatCString is worth the additional typing.

>The spellchecker code/interface was done several years ago (in march/april 1999)
>before any of the XPIDL/JS string classes existed so that's why the interfaces
>use PRUnichar*.

Inside the spell checker itself everything (right now [*]) is assumed to be in 8
bit character strings. Spell checking and suggesting basicaly consists of doing
grisly but simple things to these strings and checking if the result ends up in
a hash table.  What I want to know is if there are good reasons for me to expend
the extra work to use the string classes vs plain old pointer mangling.

[*]  I know how to allow multibyte character dictionaries, but we really want to
allow languages that fit into 8 bits to stay that way.

>The new spellchecker api I'm thinking of would be simple and just contain a
>CheckWord() method as well as the existing methods for manipulating and getting
>info about the dictionaries used by the implementation, with the addtion,
>perhaps, of allowing the word to be looked up in multiple dictionaries at once.

Here I wholeheartedly agree.  I am trying to keep the interface to the spell
checking engine simple and direct for a number of reasons, the major one of
which is so it will be easy for someone to replace the engine (even the author
of myspell thinks that Aspell does a better job, it's just a whole lot more
complicated,) but also because I suspect that non european languages may use
some different algorithms, and we may need to spell check with multiple engines,
and not just multiple dictionaries.

All this is far in the future.  Right now I would rather have a slightly
inelegant implementation that at least does a fair job of spell checking USian,
but doesnt sneer too badly at the rest of the world and work from there.

One more thing.
>For the netscape implementation of the spellchecker, we put the spellchecker dll
>and the dictionaries it relies on in the components/spellchecker directory. 
>This has the benefit of allowing the spellchecker to be autoregistered the next
>time mozilla is started, if it was not previously installed.

If I put the dictionary in the components/spellchecker directory, how do I find it?
I can get NS_APP_DEFAULTS_50_DIR, then cross out 'defaults' and pencil
'components/spellchecker' in in crayon, but there should be a better way.  

The profiles directory I can find.
components should be found somehow using:

kin: the new api sounds good, i ran into the same sorts of problems w/ my impl. 
because of all the string stuff i ended up rewriting a lot of the code (and 
didn't finish, leaving the code in an indeterminate state).
This is what I see as the api of the spell checking engine, at least it is what
I am coding to.  I have split off the Personal dictionary into a seperate
As you can probably see the interface to this is somewhat wider than is
I want to be able to store past spelling errors, to improve the probability
that the first suggestion is what is desired.
I have added a language attriute in because eventually we will probably want to
allow users to restrict personal entries to specific languages.  I'm not
entirely sure how this should work.  I welcome suggestions, especially from
multilingual people.
Of course the initial implementation will have these as stubs.
RE. Multilingual Spell Checking:

Users could create a "user word list" of custom words. There should be a user
word list (UWL) file for each language. Hence, you could have "CustDict_EN.uwl"
for English, "CustDict_DE.uwl" for German, etc (the regular/default word lists
could be "Dict_EN.spl").

The tricky part is having the spell checker know which language is being
checked. Ideally, the document could be marked as "language XX" (a default would
be cool). Then the spell checker and appropriate UWL would be used/updated. Even
better would be the ability to mark text portions *within a document* as
"language YY". That way a message could contain multiple languages and the spell
checker would seamlessly check the whole document and automatically check the
correct language. This is quite common in non-monolinguistic cultures (i.e.,
almost everywhere but the US). Of course the markings for where a language
starts and stops would exist only while the message is being composed (or part
of the template during creation).
You could set the default language for spellchecking to be the same as for
webpages ie en_US. And then use last used language.
I just wanted to let you know that I have started a major rewrite of
Aspell/Pspell dubbed "The New Aspell".  More information can be found
at  One of the major goals of this rewrite is to
make Aspell/Pspell a lot simpler and more straightforward to use.  I
consider the Pspell attempt a failed attempt at greater portability
because it made things too complicated and most everyone just used it to
get at Aspell.

I would appreciate it if you would work with me to make the new Aspell
meet your needs as I really hope that the result of the merge will be
one cross-platform spell checker than everyone can use.

PS: Aspell will compile on Mac Os X just fine.  If gcc is used Aspell
should compile anywhere.  Not using gcc can cause problems but I am
slowly working on it.
Attached file spellcheck.tar.gz (obsolete) —
This is a simple spell checker.  If you untar it into
/mozilla/extensions/spellcheck it should build on windows.  I would appreciate
help getting the unix/mac makefiles working.
I also would like any comments on the architecture, coding style, etc.
The american dictionary is included, and I believe that German and Portugese
are available, with more to come. (I need to implement word compounding to
handle german noun soup though.)
This should work on any machine that mozilla works on.	The major problem is
the time it takes to load the hash table. Advice is desired.
In a few weeks when the new Aspell interface exists I intend on making a thin
XPCOM binding to it, and then writing some glue code to map Aspell's bindings
to Mozilla's so that people who have aspell can use it with mozilla.
Attachment #60059 - Attachment is obsolete: true
Attachment #60061 - Attachment is obsolete: true
Attached file An updated spellchecker. (obsolete) —
Sorry to bother everyone, but the previous version had a serious buffer overrun
if you spellchecked words with over 100 characters.
I'm looking into making an .xpi
Attachment #61924 - Attachment is obsolete: true
I made an effort to get attachment 62035 [details] to compile on Linux. This patch has
some changes I had to apply - both to top-level configure scripts and to
spellchecker files from the attachment 62035 [details]. I failed to push through all the
way since it turned out I need sources fresher than Dec 3 17:10 to get
NS_NewUTF8ConverterStream which spellchecker uses. I may try it later, but do
not wait for me :-)
This lets it compile on linux.	However, it builds a 0 length
thereby giving

GetFactory(/home/einstein/mozilla/dist/bin/components/ Load
FAILED with error: /home/einstein/mozilla/dist/bin/components/
cannot open shared object file: No such file or directory

when you try to run it.
I suspect that some combination of my code fixes and Aleksey's Makefiles should
get things working.
I apologize for all the signed/unsigned and const/nonconst problems VC++
emitted nary a peep.
Ok, with much thanks to Aleksey, it now dcompiles and runs on linux.  I have
not extensively tested it here, I'm running on a k6 133 and a debug build is a
bit sluggish, but it does discover misspelled words and make plausible
Note you'll need Aleksey's patches to the base make and config files.
Attachment #62035 - Attachment is obsolete: true
With these changes I was able to compile it on Linux and even build RedHat RPMs
with spellchecker included (as a separate RPM).
Attachment #62059 - Attachment is obsolete: true
Attachment #62069 - Attachment is obsolete: true
I tried using this spellchecker on RedHat Linux 7.2, here are the problems I had:
1) It checks even URLs and e-mail addresses in the text. It would be nice if it
knew to ignore URLs and e-mail addresses.
2) When I pressed "Recheck" after checking the whole message, Mozilla died.

Still, it's very nice to have at least some spellchecker in Mozilla, even if it
is not perfect yet. It would be really nice if it would make it into 1.0
Keywords: mozilla1.0
Any more detailed info on the crash?  IWOMM, but I think I see some potential
problems around rechecking, and I'll look into them tonight.  
Skipping things like email addresses and url's should not be difficult, I'm more
afraid of not checking something that I should check than checking things that I
shouldn't be. Are there any Regular Expression utilities in the moz infrasturcture?
> Any more detailed info on the crash?
So far I failed to reproduce it.
> Skipping things like email addresses and url's should not be difficult, I'm more
> afraid of not checking something that I should check than checking things that I
> shouldn't be.
How about doing it in a way that would simplify turning it into a preference
later (or doing it as a no-UI preference form the beginning)? This way we can
later give people a chance to make their own choices in this trade-off.

I saw another problem, not sure whether it's your code or what's already in
Mozilla - the list of hints was bigger than the box it's ought to be in and part
of it was occupying the same space as the "language" menu in a weird way - see
screenshot at

P.S. Thanks a lot for working on this, it is so nice to finally have a

RE screenshot in comment #71:

I think it would be much better if the ignore/ignore all and change/change all
were vertically ordered instead of side-by-side. For some reason, i think that
makes it easier/quicker to identify and read.

Could you make it look like this:

+- Check Spelling ---------------------------------+
|                                                  |
| Suggestions:                                     |
| +--------------+                                 |
| |              |  [   Change   ]  [   Ignore   ] |  <-- these buttons
| |              |  [ Change All ]  [ Ignore All ] |  <-- and these
| |              |                                 |

That way, the user could mainly focus on the top two (most visible/discoverable)
buttons. Also, the buttons just look better grouped that way. :)
A small bug that Aleksey found
Ok the crash is happening because the dialog is setting the language to "".  I
should make the checker behave better in those situations, but this should
help. I hope.
The code in the dialog has been there for quite a while.  I make no claims as
to understanding how it works  I know that the list box displays more elements
than it has space for, and that the language selection combo box is screwy.  I
would appreciate any help from those who understand javascript and XUL.
My priorities for the future are
1) Stabilizing this code, so that it at least doesn't crash Moz.
2) Widen the low level XPCOM interfaces so that other spell checking engines
can be used, possibly simultaneously.  This is important for a number of
reasons. First there are better, much better spell checkers out there. Second,
many systems, KDE and Gnome at least, provide system wide spell checkers. 
Using these spell checkers will allow users to keep their personal dictionaries
and spell checker preferences in one place, and I have been convinced that this
is a good thing.  I think that these spellcheckers can be used without using
their UI elements. Finally, it will allow people to write their own spell
checkers for mozilla, having very little mozilla knowledge.
3) Attempt to attack those spellcheck related bugs which will cause widening of
XPCOM interfaces. For example bug 51550 or bug 58612. As the interfaces are
congealing rapidly in the race to 1.0 this may or not be possible.  I would
also really like to be able to spellcheck textboxes right now.
4) Add small features to the current spell checker. Skipping email adresses,
URLs and roman numerals falls into this category, as do bugs 6547 and 91131.
Attached file A new base for sources. (obsolete) —
I apologize for the reversed, unlabeled patches.  I now have this locally in
and so will be able to make saner patches in the future.
I believe that this fixes Aleksey's crash as well (an embarrassing bug).
Sorry for all the trouble.
Oh, That previous attachement is a tar.gz of the sources only.  Get the
dictionaries from one of the other tar.gz's. Sorry.
Attached patch Patch to fix the listbox problem (obsolete) — Splinter Review
This is a patch to editor/ui/dialogs/content/EdSpellCheck.xul that fixes the 
suggestion listbox problem.  The list box should be a few pixels taller, but
I'm not sure how to achieve that.
David, would it make sense to file the EdSpellCheck.xul part as a separate bug?
Do you know what exactly the problem there? Am I right assuming that it's not
specific to your spellchecker implementation and would affect other
implementations (such as Netscape's internal implementation)?

CC'ing who was the last to modify that file and that line.
David Einstein,

> Skipping things like email addresses and url's should not be difficult,
> I'm more afraid of not checking something that I should check than
> checking things that I shouldn't be.

(i.e. you skip "URLs" which are none?)

The URL-skipping could be implemented on the Mozilla-side of the interface,
because Mozilla knows best what a URL is and all spellcheckers will need to skip
URLs. (OTOH, A-/Pspell will need to skip URLs in all apps.)

There is the TXT->HTML converter, which has a reliable URL recognizer. I could
write you a function that takes a string and returns the bounds (indices) of the
first URL (or similar), if you need it.

> Are there any Regular Expression utilities in the moz infrasturcture?

Yes and no.

Yes, there is a regexp facility in JS, but unfortunately, there is no convient
C++ interface (you'd have to set up a JS context and invoke the internal regexp
functions, I think).
  I'm not sure at this point whether filing a seperate bug makes sense at this
point.  Once I figure out how to make some .xpi files so that testing can be
more widespread and the spell checker looks somewhat solid then filing a
seperate bug makes sense.  Besides, the thrill of spamming all these people
annot be underestimated.
>There is the TXT->HTML converter, which has a reliable URL recognizer. I could
>write you a function that takes a string and returns the bounds (indices) of the
>first URL (or similar), if you need it.

That'd be great! If you could work it into mozEnglishWordUtils::FindNextWord
that would be fantastic. The FindNext word implementation is really rudimentary
right now.
I have tried to keep things structured in such a way so that we have the choice
of how much or how little of a spell checker's interface we want to use.   

Please consider letting the spellchecker NOT skip e-mail address. That is a
useful method for making sure that an e-mail address way written correctly. If
it is, then the user can add it to their custom dictonary and never be bother by
that address again (if he types it correctly); if the e-mail address is typed
incorrectly, then it would be a pitty if the recipient sent e-mails to an
invalid/incorrect address and perhaps never noticed it :(

Please let spellchecker *NOT* skip e-mail addresses.
Any skipping of things will certainly be controllable by preferences.  One of
the reasons that I left the word splitter so simple was that I did not want to
skip things that people wanted to check. Of course the other reason was laziness.  

Even if you do not want to skip email adresses, you probably want the whole
thing recognized as one 'word'. 
I had some problems building this spellchecker for Sparc Solaris 7 with gcc 2.95.2.

I got errors like the following from mozSpellI18NManager.h and

In file included from mozSpellCheckerFactory.cpp:44:
mozSpellI18NManager.h:47: parse error before `{'

I tracked the bug to multi-line #defines in the .h files.  The problem came in
because the files were DOS format text files (new line and carriage return)
instead of unix style (newline only).  For some reason gcc could ignore the
difference in other places, but not in multi-line #defines.

Anyway, cvs might take care of the problem transparently when this gets into the
tree.  Or is there some other way of handling this file format problem? 
Regardless, there
are a couple of ways of working around this for anyone else who runs into the
problem. First, manually change the offending files to unix format.  Or use the
patch I'll attach in a minute (which I hacked up before I figured the cause of
the problem) which turns the multi-line #defines into long line #defines.
Attached file Just to join the pieces together. (obsolete) —
This tar ball includes the contents of attachment 62288 [details] plus the dictionary
directory of attachment 62101 [details], with all the files with Unix line termination.

The RPMs of Mozilla (recent 0.9.7 branch build) with the spellcheker are
available from
(should work at least on RedHat Linux 7.1 and 7.2).
Attachment #62101 - Attachment is obsolete: true
Attachment #62256 - Attachment is obsolete: true
Attachment #62264 - Attachment is obsolete: true
Attachment #62288 - Attachment is obsolete: true
Attached file win32myspell.xpi (obsolete) —
This is an xpi file that should install the spellchecker in a recent w32
You will need to restart mozilla after loading it to get the spellchecker to
I have a problem with the cursor not resetting properly at the end of the
install, but I had the same problem with the netscape spellchecker xpi.
I will try to get a linux xpi built but that will probably not be soon.
NOTE: This probably goes without saying but this is alpha quality software, and
even if it wasn't it still would have absolutely positively no warranty. Use at
your own risk. Dont blame me if your computer turns into a heap of gelatinous
Attachment #62548 - Attachment mime type: application/octet-stream → application/x-xpinstall
Note: To install the xpi you will have to save it locally with a .xpi extension
and then open it.  There is a small bug in the XP Installer that prevents
loading it from a bugzilla attachment.  Soory for any inconvenience that this
may have caused.
The install of attachment #62548 [details] works as you described (download, then drag
onto browser). But man, does the spellchecker cause mozilla to crash *often* -
whew. Nice work though. :) woohoo

BTW. When the checker reaches my last name (Lairo) it suggests "Lairo o" (with a
space!). What's with that? Maybe you could add my last name to the dictionary? ;)
You should be able to add your name to the personal dictionary. That is what it
is for.
I dont get 'Lairo o', I do get 'Lair o' both of which are recoginized as valid
english words.  Improving the suggestion algorithm is
Can you find a reproducable crash.  I have not found Moz to be appreciably less
stable with the spell checker, but then I haven't been running without it.
I really am concerned.  If you could post some talkback ID's we could get the
Netscape people to get stack traces.  A reproducible crash would be better.
Talkback IDs: TB804128X, TB804073Q

Reproduce:    compose, pase some text, load speller, click "Edit..."

After i rebooted my PC , it no longer crashes, tho - sorry.

I'm using build 2001-12-20, win98.

PS. RE comment #89 - I mistyped. I meant *it suggests "Lair o"*. Is that a valid
word? It's really *two* words! [OT] What is a "Lair"? [/OT]

PPS. Would you please consider rearranging the "Change" and "Ignore" buttons as
per my suggestion in comment #73?
a lair is like a cave.

can we please not complain about the spellchecker ui in this bug? everyone here 
knows how to file new bugs, please do so for things which are not specific to 
implementing a spellchecker backend.
Assignee: rcassin → Deinst
After installing the spellchecker with a win32 build from December 22, mozilla
freezes when I try to click on my newsgroup server in the folder pane.  No
talkback is sent because it freezes up good and I have to use task manager to
end it.
Blocks: 116672
*** Bug 117646 has been marked as a duplicate of this bug. ***
The spellchecker seems to work fine on win98. Any chance of it getting into the
trunk for more widespread testing. Also, MANY users will appreciate this
much-requested feature :)

If not soon; any approx ETA?
This was posted to the aspell-announce mailing list.  Would those interested in
following the development of the new Aspell please subscribe to by going to
Unfortunately, it seems that the win32myspell.xpi file no longer installs
correctly as of January 6th nightlies.  Upon restarting after installing the
file, I get an error dialog with this message:
Title: XPCOM:EventReceiver: mozilla.exe - Entry Point Not Found
Message: The procedure entry point ?ToLowerCase@nsString@@QAEXXZ could not be
located in the dynamic link library xpcom.dll.

I was kind of hoping the spellchecker would get checked into the trunk soon; it
seems to work great for me and I have had no crashes.  Is there a status on
that?  In any case, the contributors so far rock!  I'd also like to note that my
previous report of crashing caused by the spellchecker was a mistake.
I'll try to make a new .xpi tonight.  I have a slightly better idea of what
could be improved with the last one.

I should have a new interface capable of handling multiple spell checkers,
hopefully integrated with aspell possibly by next week.
In doing this, I would like to widen the nsISpellChecker and
nsIEditorSpellChecker interfaces. What is the policy on doing this?
Attached file win32myspell.xpi (obsolete) —
This works on my machine, it has not been heavily tested though.  On my win2000

machine you no longer need to restart mozilla after installing.
Attachment #62548 - Attachment is obsolete: true
Attached file spellcheck.tar.gz (obsolete) —
Code updated to use I18N code for capitalization, not nsString.  Sorry about
Blocks: 16409
Blocks: 23421
Summary: Editor needs spell checking → Mozilla needs spell checking
I've just come up with a problem.  I have "spell check before sending message"
turned on in my preferences.  So I write up a message, hit send, and
spellchecker pops up.  Then I notice that I wrote a word incorrectly.  It's
spelled right, but I would like to edit the letter.  So I'm sitting here with
the spellchecker open and doing its business, and I'm looking at this word that
I'd really like to change, but the only way for me to do so is to hit "done" in
the spellchecker and really quickly hit Cancel on the normal "message sending"
dialog.  If my connection/pc is too fast, the message will be sent because I
won't have time to his the Cancel button.  

This seems like a real shame.  It would be great to be able to cancel the send
from the spellchecker UI, but it seems like this might be asking too much. Thoughts?
Ben:  What you describe is bug 52679 (moved to bugscape 3581).  

QA: Should bug 52679 be reopened dependant on this bug?
No longer blocks: 16409, 23421, 116672
OS: other → All
Hardware: Other → All
Summary: Mozilla needs spell checking → connect a spellchecker engine for Mozilla
Personally I would prefer that all the issues with spellcheck on send be
thrashed out in one bug.  As Bug 86296 is still active that seems like a good
place to do it.
If a workable spec can be produced for the semantics of spellcheck on send that
does not produce objections from the mozilla or netscape people, I would be glad
to implement it.
Blocks: 119232
Comment on attachment 62536 [details]
Just to join the pieces together.

Obsoleted by the attachment 63885 [details]
Attachment #62536 - Attachment is obsolete: true
RedHat RPMs of Mozilla 0.9.7 release with the latest spellchecker (from
attachment 63885 [details]), listbox patch (attachment 62299 [details] [diff] [review]) and yet another small patch
(attachment 40536 [details] [diff] [review] from bug 86116) can be found at

They should work on RedHat 7.2 and are likely to work on 7.1. Not sure about
other versions of RedHat and other distros.
I can reliably crash the spellchecker with Mozilla 0.9.7 on Linux.

To reproduce:
1) Compose a message using english and cyrillic words
2) Set Charset to KOI8-R
3) Press send

Moilla always crashes right after that.

For some reason I can not get anything useful from gdb

Thank you Aleksey.  
I think that I know what your crash is. Laziness again, I'll bet.  I should have
a fix tonight, or maybe tomorrow.
More on this crash:
- Step 2 is unnecessary - it will crash if I type any cyrillics in the message,
no charset change necessary
- It will crash from both "send" and "Check" buttons
- The best I was able to get out of gdb is:

(gdb) bt
#0  0x41d7ba60 in NSGetModule () from /usr/lib/mozilla/components/
#1  0x41d7a26e in NSGetModule () from /usr/lib/mozilla/components/
#2  0x41d79f81 in NSGetModule () from /usr/lib/mozilla/components/
#3  0x41d68a9d in NSGetModule ()
   from /usr/lib/mozilla/components/
#4  0x41d68976 in NSGetModule ()
   from /usr/lib/mozilla/components/
#5  0x41d47120 in png_pass_dsp_mask ()
   from /usr/lib/mozilla/components/
#6  0x401710b2 in XPTC_InvokeByIndex () from /usr/lib/
[... the other 92 frames omited ...]
OK, I think that I have fixed Aleksey's bug.  The source is now at  I will soon put the .xpi's there as well so that
installation can become a one-step process.
I'm sorry for the lack of speed, but I'm somewhat busy
I've been running the latest version from for a while
now and its looking really good. I would say it's definitely ready to be
included in 0.9.9.

I've also filed the following RFE's: "<name> wrote:" quotation line should
not be checked Quoted text should not be checked. Spellchecker does not know how to
deal with all-caps words.

(I filed them with and not since it's not clear when this
code might be included into Mozilla).
Keywords: mozilla0.9.9
David's win32myspell.xpi spell checker consistently crashes on win32 build
2002012503 whenever clicking the Spell button in Composer or when clicking the
Send button, if the auto check spelling feature is enabled.

I tried sending a Talkback report, but the Feedback Agent consistently says it
cannot connect to

Detailed error message follows:

MOZILLA caused an invalid page fault in
module MSVCRT.DLL at 0167:78002f3e.
EAX=0064c7d4 CS=0167 EIP=78002f3e EFLGS=00010206
EBX=039aa82c SS=016f ESP=0064c7c0 EBP=0064c7e0
ECX=0000003f DS=016f ESI=ffffffff FS=4257
EDX=00000002 ES=016f EDI=0000003f GS=0000
Bytes at CS:EIP:
8a 01 41 84 c0 74 3e f7 c1 03 00 00 00 75 f1 05 
Stack dump:
60fd27c6 0000003f 0064c888 039aa82c 00000004 0000003f 00000000 00000000 0064c960
60fd2768 0000003f ffffffff 039aa800 021c236f 0000003f 60fd2f18 
I've also found that the win32myspell.xpi crashes when running (either when
clicking spell or when sending when spell checking is on) on all 20020125/26
builds on win2k.
Ok, I am on the road keeping the world safe for my continued employment until
the middle of next week.  Some interface has obviusly changed in a recent build,
probably in i18n.  I will look at it Thursday, but if someone else can build the
spell checker and figure out where it is breaking before then I'd certainly
appreciate it.
Will we be able to get all the spell checker code including what was passed on 
to us into the tri licnece of MPL/GPL/LGPL?

That would be best for all involved.
Comment on attachment 62299 [details] [diff] [review]
Patch to fix the listbox problem

This listbox problem is now fixed - see bug 112951
Attachment #62299 - Attachment is obsolete: true
Updated the configure and patch to apply cleanly to the current
Attachment #62214 - Attachment is obsolete: true
Attachment #62427 - Attachment is obsolete: true
I've compiled BuildId 2002012619 on RedHat Linux (get the RPMs at ) with the latest
spellchecker from and it works fine without any
crashes. So indeed I would guess that the problem of the win32 .xpi crashing
could be solved by recompiling it...

Attached file win32myspell.xpi (obsolete) —
I recompiled the dll's and it seems to work with 2002013103.  There is also a
fix making it possible to spellcheck words taht are in all caps.  I'll put this
xpi on mozdev sometime tomorrow, which should make a one step install possible.
Attachment #63881 - Attachment is obsolete: true
David: It appears that attachment 67305 [details] crashes win32 build 2002020103 :(.
Attachment 67305 [details] crashes for me too (build 2002-02-04, winNT & win98) - bummer.

I have also been unable to *download* the xpi file for later use - any hints?

I'll use the speller in attachment 63881 [details] for now (hope it works...).
I don't know why you cannot download the new spell checker.  

The problems with the recent ones is that the Mozilla string classes are in a
bit of a flux, (possibly even fluxed up).  Hopefully this will settle down in
the push for 0.99. 
I finally got it to download. It offers to save "attachment.cgi" (which I then
renamed to "win32myspell.xpi"). This is a major bug in bugzilla. :(
Attached file win32myspell.xpi (obsolete) —
This works with build 2002020603 (on my machine, this morning, etc...) The
string classes seem to be sttling.
Attachment #67305 - Attachment is obsolete: true
RedHat RPMs of Mozilla 0.9.8 with spellchecker ar available at (source RPM is at )
Blocks: 123569
The latest win32 attachment crashes when I do this in 2002-02-06-03:
Default/New Profile
File, New, Message
Click in the message body
Click Spell checker toolbar button
Click Edit Personal Dictionary in the dialog
Before any new dialog shows up, Moz crashes
Talkback IDs: TB2589198X, TB2589085W

This build has improved somewhat, though.  Before, It would crash spell checking 
the empty message for me. :)
   As soon as I finish rebuilding Moz I will update the xpi.  This bug has been
around for a while.
Attached file win32myspell.xpi
Ok this fixes the crash on editing a nonexistent Personal Dictionary.

Aleksey: If you rebuild for 0.98 from the sources on Mozdev you will need to
back out the change on line 190 of myspAffixmgr.cpp, or the spellchecker will
behave strangely.
Attachment #68142 - Attachment is obsolete: true
Thanks, my 0.9.8 RPMs were built with the previous code and work perfectly.
Blocks: advocacybugs
This is a spellchecker that should work with 0.98.  Do not use it with a recent
nightly unless you enjoy wierd xpcom errors.
Sorry for such a question, but I couldn't figure this out.
I want to compile the spellchecker and test it. I've checked out the sources of
Mozilla and the spellchecker, but I don't know how to combine the 2 of them. 
Where should I put the spellchecker sources inside the mozilla source tree? How
do I make the general make compile it?
Or do I have to compile it seperatly?

I use linux (SuSE 7.1 if it makes any difference).

To get the spellchecker to compile, get the latest sources from into the /mozilla/extensions/spellcheck directory, get
Aleksey's changes to the to level buld system, then do the ./configure and make
as usual.
For those of you interested in perpetrating unamerican activities, here are some
instructiona on spellchecking other languages.

Get a dictionary from
and unzip it into the components myspell dirctory.

Rename the files to change the underscore to a minus, for example change
en_GB.aff to en-GB.aff and en_GB.dic to en-GB.dic .  Do _both_ files. 

On the first line of the .aff file change ISO8859-1 to ISO-8859-1

restart mozilla.

Most of the major [*] western european languages are available, and it looks
like Russian is coming soon.  

I will probably not be distibuting any dictionaries other than the en-US, but I
will attempt to make the installation of other dictionaries simpler.

[*]  If your patriotic spirit is rankled by the implied classification, give
Kevin a dictionary.  
(I'm ignoring the status whiteboard's command, because I am naughty and
unpleasant to be with.)

First of all, this looks like a _great_ extension.  I've only scanned the code,
but it seems to be well put-together, nicely modular (yay!) and generally smells
of flowers and honey.  So, from that perspective, and the obvious user demand,
it'd be great to have for 1.0.

My concern is that there's a fair bit of code here, and our review resources
(especially super-review) are already strained.  I'm not sure what to do, to be
honest.  For now, I'm taking it off my list of orphaned-with-patch bugs, with a
heavy heart.  If we can get a solid review from some righteous volunteer, there
should still be time.  Otherwise, there's always the XPI!
No longer blocks: 123569
Will this work with Mac OS Classic/X?
I have RPMs of 0.9.8 as well as a few recent trunk RPMs
I have made some major changes to the code on mozdev so that the spell checker
works, or will eventuall work better with non english languages.  I would
appreciate it if those of you who build your own play with it for a week or so,
and if there are no major complaints I will make an xpi for the hoi polloi.
Sorry if this is a rather basic question, but you could somebody provide some
instructions for building under Windows please?  As I understand it, Aleksey's
 patch only works for Linux.  In fact, I managed to build it under Linux, but
that doesn't help me much as I don't spend much time there.  I'm new to this
source tree, and my brain has been addled by too much Developer Studio and its
graphical build environment leaving me having makefile comprehension problems -
can somebody tell me how to change the makefile rules, or whatever it takes?  I
am "interested in perpetrating unamerican activities", although only with en_GB.
 Apologies if this question is inappropriate as a comment, but I saw somebody
else ask too.
Instructions for building on windows.

1) Get the latest sources from

2) put the sources in the mosilla/extensions/spellcheck directory.  (For
reference, just so you grab the correct section of the mozdev tree, this
directory will contain

3 Add spellcheck to the DIRS variable in mozilla/extensions/

4 cd to mozilla/extensions/spellcheck and do a 
nmake -f
I've compiled RedHat 7.x RPMs of this morning's build with the latest
spellchecker. Browse my Mozilla RPMs at (clicking on
attachment 69858 [details] will take you there as well) or download directly from

P.S. Haven't really tested the most recent changes yet (and I am still waiting
for ru_RU dicts to appear on
I have a problem with the personal dictionary - for some reason it do not
remember words I add. It did remember few, but for most words it simply keep
asking about them everytime I open mozilla and compose a mail. If I compose more
them one mail at the same session of mozilla, then words I add are remembered
after the first time I add them. This hold only till I close mozilla.

Where is the personal dictionary saved?
The personal dictionary is stored in persdict.dat.
The personal dictionary is (or at least should be) written to disk on Mozilla
shutdown. What kind of machine are you using?
I work on Linux machine.
I've rechecked it, and looked at the dictionary file. Now it worked (and I
didn't change a thing). I guess I was doing something wrong (or maybe mozilla
crached the other times I've tried).

Why isn't the dictionary written every time a word is added, or at least every
time a spell session is ended?
Ilan: Or, maybe you're running into 826?

("Persistent personal-dictionary through build updates")
*** Bug 127220 has been marked as a duplicate of this bug. ***

I just tried w32spellchecker_098.xpi on Win95. Spellchecking in US English seems
to be working fine. However, I was more after en_GB and de_DE, so I gave the
files provided by OpenOffice a go. I put them into the myspell directory and
replaced '_' with '-' in the filenames. Unfortunately, it didn't work. The new
languages can be selected in the spellchecker dialog but US English is always
used. I removed the en-US files from the myspell directory which led to all
words being accepted as correct. Also I tried to cheat and just renamed the
de-DE.* files into en-US.* which didn't work either.

It would be fantastic if other languages could be used as well for the spellchecker.

As a wishlist thing, it would be next to unreal if OpenOffice, Mozilla and
Evolution could use the same dictionaries.
Yes, I think that the language handling in the old xpi's.  You can switch
languages by choosing the language, exiting mozilla, and re-entering.  The
recent sources have these bugs fixed.  I will make a new xpi availble for the
recent dailies soon, once I add a pref for saving the personal dictionary after
each session.  Thank you for your patience.
Ok, Malcolm Ferguson <> pointed out to me that he had
to replace 'SET ISO8859-1' with 'SET ISO-8859-1' (i.e. add '-' between 'ISO' and
'8859') in en-GB.aff to get things to work.

This does indeed work for en_GB which is great! en_DE proved immune to this
procedure, though.


PS: David, thanks a lot for working on this!
Attached file win32myspell.xpi
This is yet another win32xpi.  It should work with a recent nightly, and with
luck 0.99.

Non en-US languages should be better supported.  You should be able to switch
languages on the fly, though I'm not sure why you would want to do that.  The
only modification to the OO dictionaries that is needed is to change the
underscore in the filenames to hyphens, and this is not mandatory, it just lets
mozilla automatically recognize the language and country for the combo box

A pref "spellchecker.savePDEverySession" has been added.  If it is true, then
the personal dictionary will be saved after each spell checking session.

I thank you all for your support.  If you have issues with the spellchecker
feel free to report them to Your comments are
In <a href="">#148</a>
David Einstein wrote:

> Non en-US languages should be better supported.  You should be able to switch
> languages on the fly, though I'm not sure why you would want to do that.

If somebody, like me, writes often in two or more languages. About 50% of my
emails are in english and the rest are in italian and being able to quickly
switch from one to the other is a real plus for me. I don't know wheter the
other mailers allow to do that so easily, if they don't this would a real point
of Mozilla against the competitors.
I have just posted a new windows .xpi at
This fixes a bug with spell checking non ISO-8859-1 languages.

Using mozdev should make life easier on all of us, using the attachement is a
horrid kludge.  Plus I can count you :)

Out of curiousity, has anyone built this on anything other than Windows, Linux,
or Solaris?  Reports of success, or detailed reports of failure would be
*** Bug 130313 has been marked as a duplicate of this bug. ***
*** Bug 131290 has been marked as a duplicate of this bug. ***
FYI - I just downloaded the code and built it in my 099 tree on OpenVMS. One
small compile problem. In mozAffixMod.cpp the first arg is of type "const char
*const" while in the header file its prototyped as "const char *". My compiler
didn't like that. But I fixed that and linked it, copied the files to my
installation tree, it worked!
In comment 153 I meant to say "the first arg of addMod..."
Just a quick question, before I install and help test this.
Is this another one of those add ons like calendar that will
have to be reinstall every time I put in a new browser (once a week)


Mozilla 0.9.9+
Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.9+) Gecko/20020323

SVG-Mathml zips.

Steve: Yes, it is.
Hi  Alex "Rembrandt" Bischøff 
Okay, got one installed and downloaded a backup.
 An xpi for post 0.99 nightlies.

First thing, after clicking on Download More in the language box, it lead to a
blank browser window, 

Expected result was to go to either:

Was wanting to put in German also.

First impression, works fine but I not sure if it is catching the added
words. I'll have to test it a little more.
Steve: I'm not actually the Spellchecker maintainer, merely a satisfied user :). 

So, if you have any questions about installing or using Spellchecker, please see or e-mail David about it (
*** Bug 133572 has been marked as a duplicate of this bug. ***
Google has released a web API package which allows to use Google functions from
stand-alone applications. Among the various possible Google functions usable
from the API there's the spellchecker one, I was wondering wheter it was
possible to implement the infamous Mozilla spellchecker using this API.
Cute, but no. First, that'd require you to be connected (and have good
connectivity to Google) for it to work. Second, everyone would have to create a
personal-use account. And third, it's limited to 1000 queries a day.
I've tried to add the spellcheker to the 1.0RC1 source tree and compile. 
The patch that is posted fails for configure and, but this is
easily fixed manually.

When I use the spellchecker to correct a word in a mail message, mozilla craches
immidiatly when pressing the "replace" button.
Comment on attachment 63885 [details]

This is really old, please use the sources from instead.
Attachment #63885 - Attachment is obsolete: true
*** Bug 140963 has been marked as a duplicate of this bug. ***
*** Bug 141128 has been marked as a duplicate of this bug. ***
*** Bug 144808 has been marked as a duplicate of this bug. ***
*** Bug 146240 has been marked as a duplicate of this bug. ***
*** Bug 146801 has been marked as a duplicate of this bug. ***
Current builds (at least 2002052408 and RC3) no longer work with the .xpi files
on mozdev.  The ones I tried were:

Philip: Right, that's a bug in the Spellchecker XPI:

In fact, the XPI hasn't worked with the nightlies for the past two weeks :(.
*** Bug 149004 has been marked as a duplicate of this bug. ***
Hi All 
Mozilla 1.0.0+
Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.0+) Gecko/20020603
and M1 RC3

It seemms to bea working okay noow
It seems to be working okay now

The above was a copied from an email using spellchecker. The newest for Rc3 is
also working fine in a newer trunk, as stated above.

I even have added a German Dic and it works also.
Now that 1.0 is out, when is this code going to land in the main trunk?
I created an installation page for Beonex Communicator - it should also work for
Mozilla 1.0. I also created XPI packages for some popular language dictionaries,
for "2-click-install".

The spellchecker itself there is copied from mozdev and Win32 only, because
there's no Linux xpi on mozdev (that I could find), only Redhat RPMs, which are
not of much use for me. Maybe I'll compile it myself later.

Feel free to link to the page (no bandwidth problems expected, thanks to
ibiblio), copy it or the packages, assuming proper credit.

Will this spellchecker be compatible with Mozilla on Mac OS X?
Keywords: mozilla1.1, patch, review
Any idea when the spellchecker will land in the Mozilla tree? The current method
is a problem at best. I find it difficult to test the latest nightlies when the
spellchecker keeps getting hosed. I don't have the resources to compile the CVS
versions of the spellchecker so that leaves me with sticking with an earlier
build or no spellchecker...
Alias: spellchecker
Just checking, any idea on when a new release will be out that works on mozilla 1.1 daily builds?
The last one from here;
is working for me on

Mozilla 1.1b
Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1b) Gecko/20020722
All works on NightBuild 2002080807
But what about using several dictionaries at same time ?
If i select to use for example Russian lang. it ask me about all english words
to correct them ... this is a little annoying.
Anton: It may be more fruitful to report feature-requests at the Spellchecker
XPI's website:
I'm adding an attachment for Mac spellchecker. Attachment is a bin archive that
contains the following:

--spellcheckIDL.xml : xml version of MetroWerks project that generates headers
for mac spellchecker
--spellcheck.xml : ditto for generating spellchecker.shlb
--myspell.xml : ditto for generating myspell.shlb
--MANIFEST_IDL : text file to be placed in directory that contains IDLs
--add to : text file of instructions to be added to Mac
perl build script
--mozCStr2CStrHashtable.cpp : source file containing two changed lines
necessary for myspell.shlb to link. Lines 68 & 86, both with comments; should
not affect other builds
xpi file includes install.js, 3 libs, and 2 dictionary files. Mac carbon build.
tested on Mac OS X and 9.x and it works.
Blocks: majorbugs
Just wanted to mention in case some of you haven't heard ... aspell just became
an official gnu package:
Is the spellchecker going to be integrated to the source tree soon? 
We already have Mozilla 1.1 which doesn't include it, while the target milestone
was mozilla 1.0.1
Ilan: Mozilla 1.0.1 is on a different branch that 1.1. Hence the funny fact,
that 1.1 has already been released while 1.0.1 has only a RC2 release.

Which does not mean that the bug will be resolved before 1.0.1. Certainly not,
as the 1.0 branch does not accept anything risky. Actually, the target should be
changed to something on the trunk (like 1.2 alpha or 1.2 beta) rather than the
1.0 branch (meaning not 1.02 or 1.03 etc.)
Well, 1.1 is released and 1.2 will be frozen in four days time. I'd suggest
assigning the target to 1.3 or landing the patch _now_.

Please land the patch! The two key features Mozilla is missing to be considered
seriously are a spell checker and a calander/task manager. Let's get at least
one of these into 1.2.
Please land the patch! The two key features Mozilla is missing to be considered
seriously are a spell checker and a calander/task manager. Let's get at least
one of these into 1.2.
Updated keywords to get it on the radar for Moz 1.2.

Also, comment #185 is right - this would go in the trunk, not 1.0.1 - setting
the target to reflect this fact.
Whiteboard: Please do no add comments unless you want to implement (code) something → Please do no add comments unless you wanent (code) somethingt to implement (code) something
Target Milestone: mozilla1.0.1 → mozilla1.2alpha
Whiteboard: Please do no add comments unless you wanent (code) somethingt to implement (code) something → Please do not add comments unless you want to implement (code) something
Can this still be added for 1.2 beta?  Nominating for nsbeta1.
Keywords: nsbeta1
Target Milestone: mozilla1.2alpha → mozilla1.2beta
What is holding this patch up??
Nothing is holding it up, except that the code needs to be reviewed (the latest
code should be available at

P.S. I am not sure whether nsbeta nomination in meanigful since Netscape already
has its own closed-source spellchecker (that's probably more mature that what
we've got so far).
So would the next stage be to get the module owner of Composer
(Editor/Composer), which is Akkana Peck (, involved? Should
the patch be posted in here or is it alright to have it on mozdev?
I, at least, would like to see a patch here, or if on mozdev, at least as a
.diff. I am not sure if a diff is available on mozdev...

or does spellchecker only consist of new files?
Regarding comment #192, one possibly hold-up is that the Spellchecker is
currently broken with the nightly builds. See also mozdev bug 2034:
Yeah, it's basically been hosed since 1.1.. that's why I keep hoping that it 
will make it into the tree so that it gets more attention..
The code consists mainly out of new files. In addition to being in the mozdev
CVS, it is also in the Beonex Communicator branch, which lives in the CVS. BEONEX_0_8_BRANCH (based on Moz1.0 branch), BEONEX_0_9_BRANCH
(based on Moz1.1 branch), directory extensions/spellcheck/. Spellchecker in 0.8
works fine (apart from a few crashers), 0.9 is untested.
The current spellchecker does not work unless you are willing to compile it
yourself.  It appears that Mozilla is going through a bit of a flux, small 
interface changes, nsAVLtree dissappearing etc.  My past experience has
indicated that it is not worth my while to attempt to track these changes
until things settle down.
That said, if the powers that be are willing to integrate it, I would be more than
glad to bring it compliance with the modern mozilla.
note from experience:  I'm using current RC3 release of spell-checker with
v1.0.1 release (#2002082606).   The Spell-checker was _very_ unstable until I
selected a default language of "English/United States".   Upon my install, the
checker did not have a default language.  After select, it's been quite stable
(30-50 emails/day .. english).
Depends on: 124182
*** Bug 170408 has been marked as a duplicate of this bug. ***
We (IBM) want this.

So I'll take the banner here.

If we can get the code to a current level. I will take the lead to have my team
review it
I Have downloaded the source for the spellchecker and integrated it with the
Mozilla 1.1 Source. I no problems with building Mozilla 1.1 with the
spellchecker code added to the source, so the code isn't too out of date.

Would it be possible to check this into the tree, but leave it out of the
nightly builds for now, like Calendar. This would give people the option of
Building Mozilla with the Spellchecker, and would make it easier to find any
problems that may be in the latest code.
Michael: You can find the current spellchecker-XPI (and its source) here:

However, that code hasn't cooperated with the Mozilal nightlies since about
August 30th:
Comment on attachment 66755 [details] [diff] [review]
Changes to top-level make system (Linux)

The patch to top-level make files now lives on mozdev spellchecker CVS:
Attachment #66755 - Attachment is obsolete: true
Please be aware: as part of ongoing removal of the deprecated editorshell class,
I have a patch in bug 168999 which splits the implementation of
nsIEditorSpellCheck out of nsEditorShell into its own class (nsEditorSpellCheck,
which lives in libcomposer and is created via CreateInstance rather than a QI on
the editorshell).  We are hoping to land this soon, before 1.2beta goes out.

I don't think this will break anything in the mozdev spellchecker -- I didn't
have to change anything in the ns spellchecker -- but I'm not sure how to test
the mozdev spellchecker.  Timeless has pointed me to a comment in bug 142182,
and I've done cvs update -d -rBEONEX_0_9_BRANCH extensions/spellcheck, but I'm
not sure how to get the right mozAVLTree code that extensions/spellcheck needs.
 If someone can post current build instructions, I'd like to test this; or,
failing that, can someone who does have the spellchecker building please test
the patch in bug 168999 and ensure that it doesn't break anything?  Thanks!
Akkana: Err, isn't the mozdev spellchecker already broken? (comment #203)
> isn't the mozdev spellchecker already broken

No, that was fixed couple of weeks ago.
It is sort of broken.  The cvs code should build, the spell checker works on my
machine :-)  There are know error handling problems which I hope to get to soon.
I doubt that Akkana has broken anything drasticaly, and will try to make things
right this weekend.  I thank her profusely for notifying me that things will break.
Now if I can only keep the cvs server from losing interest while
updating my mozilla sources.
where's the latest installer on mozdev?  spellcheck's been busted for me for
weeks with no updated installer available for nightly builds.
I pulled the spellchecker from mozdev CVS and built it (without the patch, since
the patch didn't apply) and ran it with my nsEditorSpellChecker changes.  Basic
spell checking works, but Recheck Document crashes in mozAVLTree code (which I
doubt is related to my changes).  I'm going to go ahead with the editor changes
(assuming I get approval), and will keep on top of this bug to make sure I
didn't break anything once the AVLTree stuff gets sorted out.
*** Bug 175421 has been marked as a duplicate of this bug. ***
I downloaded and istalled spellchk.xpi from Netscape.  It worked well in Mozilla
1.1.  It does NOY work in 1.2a or b.  Can anyone tell my why ...and how to get a
spellcheck that works with mail client in Mozilla 1.2b?  Thanks.
Dusty: Normally, you'd just download the Spellchecker.xpi from, but that hasn't worked since late August.
(comment #203).

For people without a compiler (which is most of us), I know of no spellcheckers
that are available for 1.2 or the nightlies.
First comments from reviewing:

67:: Why is "mPersonalDictionary->Save()" commented out?
**:: No spaces after commas, especially in function calls;
     makes reading code difficult

65:: Both "en" and non-english languages return mozEnglishWordUtils
Hi All,

    I just had to upgrade a customer's (small) business from 1.1 to 
1.2b to solve a problem with one of their web sites.  Worked
great, except "no spell checker".   You can only imagine the amount
of embarrassment this caused.   

    Spell Checker needs to be added to the general tree as soon as
practical and remain there in all new releases.  That being said,
I am added myself to the Cc: list.

   Thanks for letting me grumble.

Many thanks,
More comments from review:


Provide an explanation for 
kFirstDirSize = 8

in SetDictionary and GetLanguage

There really can't be like a de dictionary? en is the only two char dictionary?

Isn't *aDictionary = '\0' a failing case as well?


explain FIXME

explain complainloudly
*** Bug 178417 has been marked as a duplicate of this bug. ***
I've given up in frustration trying to install on Linux. So, in effect, I've
lost the ability to have a spellchecker.  And I can't update my clients either
without the same fear.

The spellchecker itself is great -- if there is anyone willing to work on
installation & version-matching issues, many many more people could take
advantage of it.

recent nightly + spellchecker from netscape 7 = works great!

so don't break sweat trying to get the mozdev spellchecker working. Enjoy the
netscape spellchecker until they break it again. fyi, it works only on Linux,
doesn't work on Windows.
*** Bug 178666 has been marked as a duplicate of this bug. ***
The target milestone should be updated and, hopefully, to a realistic one: it's
been slipping since when I started looking at this bug (more than 18 months).
Recompiled version (for 1.2 and trunk builds) is available on MozillaCafe:

Login and password are required to download the file :-(
Attached file win32myspell
fresh binary for 1.2 and trunk builds
Isn't this the bug that would allow the spellchecker to get checked into the
tree?  Why isn't that happening?
Blizzard:  See comment #214 and comment #216.  We (Kaply, myself, and J. Blanco)
reviewed the spellchecker code and had some questions for the original
developers.  We were hoping to have these answered prior to the code being
checked into the tree, but we have yet to hear from the developer (David
Einstein).  So, what is our next course of action?
I am very close to having the new interfaces working, just one or two more
issues before a review is needed.
Wait, what?  New interfaces?  Where has all this secret work been done?
I have only one wish so far.  Can the Hot Key for the spell checker activation
be changed from Ctrl-K to F7.  I have gotten very used to OpenOffice and I like
the F7 key for the spell checker.  This also seems to be a fairly common
standard (F7 as the Hot Key for spell check).
Hello -- primary request focus is keyboard shortcuts and/or "hotkeys" should
_not_ be hard-coded and customizable by end-user.  -GA
F7 is already taken, hit it and you will see.

blizzard: that interface work seems to be done in bug 180346 and bug 129704
Can someone please compile a version for the 1.3a nightly builds for win32.
Hi Brook,

   If you meant 1.2a, check out comment #224

I know David is aware, but I just put up a patch for that provides the new
SpellCheck interfaces and the new "glue" code for enabling external
spellcheckers to work with Mozilla.

This work is pending reviews, but should be very close to what will be checked in. 

Currently the "glue" is part of Netscape's commercial tree and is closely tied
to our "internal" spellchecker. This patch breaks that apart and moves the more
"generic" glue code over into the public tree. See Bug 180346
Hi All,
    OH NO!  The spellchecker download on comment 222 & 224 no longer
works with on w2k-p, sp3.  :-(   Last one I got it
to work with was

Works for me on 20021121 (from zip, not exe), win2k, sp3.  Clean installs, not
copied over prior versions.  I reinstall spellcheck each time I download the
nightly....  Actually, I'm posting from 20021118, winxp, sp1.
Hi All,

  On Michael's (eMailed) recommendation to me, I renamed my Mozilla directory 
to Mozilla.000 and reinstalled.  I then copied my searchplugins and plugins 
into the new Mozilla directory, reloaded comment 224 of the spell checker, and it
worked.  :-)

Note that the component plug-in changed names.  The old one was spellcheck.dll
while the new is spellchk.dll, you may have had the older one in there causing
*** Bug 181554 has been marked as a duplicate of this bug. ***
*** Bug 183063 has been marked as a duplicate of this bug. ***
*** Bug 183423 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.2mozilla1.3
The spellchecker pretty consistently crashes the latest mozilla nightly (zip)
when spell check is run.  My build info is:Mozilla/5.0 (Windows; U; Windows NT
5.0; en-US; rv:1.3a) Gecko/20021211 .  I'm running MozSpell_1.2f_w32.xpi .
Agree.  I had to rollback to 202121004 (win32).
Thanks for pointing this out! It's crashing in editor.dll, in 
nsTextServicesDocument::GetCurrentTextBlock. I'll have a look at it tonight.
Are you using an old binary, or a recompiled one? I am pretty sure that bug
173046 commit would have changed things sufficiently to break backwards
compatibility with spellchecker binaries.
same troubles with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a)
Gecko/20021211 and the spellchecker 1.3a nightly from the install page.
Please do not add comments of the form "old spellchecker binary does not work
with a new Mozilla binary" - they have nothing to do with Mozilla, and only
means that there is a need for spellchecker volunteers to compile fresh
binaries. Those complaints belong on the mozdev Bugzilla and mozdev mailing list.

> ... and the spellchecker 1.3a nightly from the install page

there is no such thing - there are spellchecker binaries for 1.2/1.2.1 that
happen to also work with 1.3a nightlies. As soon as 1.3a branched off and the
1.3b cycle started, the bug 173046 code was checked in and (I believe) the
binary compatibility was broken.

In short, recompile the spellchecker yourself or wait until somebody does it for
There is now a new spellchecker 1.3a binary (for Windows only right now) on the installation page.  In addition, all of the other
Windows binaries have been updated (working on new binaries for other platforms)
with some bug fixes.

Hopefully the new spell checking interface work will land in the Mozilla tree
soon so that things will become easier.
*** Bug 178702 has been marked as a duplicate of this bug. ***
Hey, before we finish this off, i think we should also add a grammar checking
interface too. it should be almost the same interface as the spell chacker but
it should be seperate enough to be able to use one person's spell checker and
annother one's  grammar checker, rather than forcing them to be the same
component. also for the interface aware of the markup it should atomaticly
ignore/switch grammer/spell checkers (at user preference) for those tags that
label their contents as a language other than the default. Of course if a person
has a spell checker installed for EN it should be used on all the dialects such
as EN-US, but a spell checker set up for EN-US should not nessisarily be usede
for EN (user preference) and certainly not used for EN-UK etc.
*** Bug 193174 has been marked as a duplicate of this bug. ***

Is this the correct place to point out that messenger subjects are not
spellchecked?  If not, could someone either report it to who needs to know, or
email me please? I'm not on this bug...


Keywords: mozilla1.3
Target Milestone: mozilla1.2beta → ---
*** Bug 202794 has been marked as a duplicate of this bug. ***
adt: nsbeta1-
Keywords: nsbeta1nsbeta1-
Flags: blocking1.4b?
Flags: blocking1.4b? → blocking1.4b-
As I can see no sign of the spellchecker on the 1.4 RC1
Mail toolbar, does this mean it won't make it (compiled)
into the 1.4 Final release? :(

No doubt there'll be a release to work with
1.4, but it would have been nice to see it integrated.
No, this will not be in 1.4.   It is marked as nsbeta1- indicating it will not
be in the next Netscape release, which is to be based on the 1.4 branch.    As
far as  a version being available -- the Mac OS X build for 1.4b
still hasn't been released and we are already on to 1.4 release candidate 1.
that is not quite correct... nsbeta1- just means that netscape employees will
probably not work on this bug (afaik); but if someone else were to get this
checked in on the 1.4 branch, it would end up in a netscape release.
Thank you for the clarification. :-)
Given that the API is supposedly static now, perhaps we can get this in 1.4 final?
Flags: blocking1.4?
I don't think that this going to happen (spellchecker in 1.4 that is), but
Thunderbird already features a spellchecker, so it seems that with 1.5 this bug
will be finally fixed.
I'm sorry for the delays, but I haven't had time to work on this. I hope to be 
able to land the spell checker on the 1.4 branch, but the code has to go 
through an approval process and I wanted to see, if we could salvage some of 
Rod Spears' work as well. He was working on landing Netscape's spell checker 
glue code.

I don't think that Netscape would be interested in this spell checker; they 
would probably turn the extension off in their build process.
1.4 is supposed to be a long lived useful stable branch, so getting a
spellchecker into it is important.

it appears that thunderbird is indeed using the spellchecker in question so i
have to wonder why the people who used it there haven't helped land it on trunk.
*** Bug 208677 has been marked as a duplicate of this bug. ***
Stop over-optimizing.  I don't know about the mail/news guys but I would suggest
that we get the spellchecker in now and worry about interface changes later.
Flags: blocking1.4? → blocking1.4-
*** Bug 209075 has been marked as a duplicate of this bug. ***
I take it this isn't going to make 1.4 :-(

It's a shame.  This far, and still no spell checker.
Switch to Thunderbird, spellcheck is in and working good for the most part..
Yes there is.  Go get it.
Here are the review notes I took while looking at the current set of sources
for spellchecker. There are some potential leaks, some cases where
we are checking the wrong pointer for null, and perhaps the need for more error
checking during allocation of memory, but nothing major that I have noticed
that should prevent this from landing in the mozilla/extensions directory.

As long as drivers give approval, I'm willing to give an
for the landing as long as the issues pointed out in these notes get addressed
either before or after the landing.
There is still no Mac OS X spellchecker available (since 1.4a).
*** Bug 211871 has been marked as a duplicate of this bug. ***
*** Bug 212980 has been marked as a duplicate of this bug. ***

Spellchecker is in but not turned on.

I need to incorporate kin's review comments.
Assignee: Deinst → mkaply
Mike, thanks a lot for landing this in mozilla. I was also in the process of
landing it in the near future and am happy to see this happen. Question, when I
started looking into doing this, I did some research on the license for the
myspell engine. After discussions with staff, we decided the myspell
stuff needed to go into mozilla\other-licenses. I didn't see this as part of the
checkin. Did you find something else out about the licensing issue? That's one
of the main reason why I had not gotten around to landing this. 
*** Bug 214491 has been marked as a duplicate of this bug. ***
*** Bug 214495 has been marked as a duplicate of this bug. ***
Should this be marked fixed as the spell checker is now enabled in default builds?
Marking Fixed, although Comment #274 might change that (or cause a new bug).
Closed: 17 years ago
Resolution: --- → FIXED
I have both v1.5a and 1.4.  Both do not have Spell Check enabled in Preferences

Please advise.
This was not checked in until after the release of v1.5a. If you download a
current nightly build, they will have the spellchecker.
Blocks: 209075
*** Bug 207100 has been marked as a duplicate of this bug. ***
Keywords: relnote
No longer blocks: majorbugs
You need to log in before you can comment on or make changes to this bug.