Bug 58612 (inlineSpell)

Need realtime spellchecking mechanism for mailnews



18 years ago
5 years ago


(Reporter: kinmoz, Assigned: enndeakin)


(Blocks: 1 bug)

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(4 attachments)



18 years ago
The editor needs a mechanism that will allow us to do realtime spellchecking. 
(Spellchecking as you type.)

Comment 1

18 years ago
*** Bug 60310 has been marked as a duplicate of this bug. ***

Comment 2

18 years ago
moving to future
Severity: normal → enhancement
Priority: P3 → P5
Target Milestone: --- → Future
Not in preview mode.

Comment 4

17 years ago
*** Bug 6795 has been marked as a duplicate of this bug. ***


17 years ago
Blocks: 119232

Comment 5

17 years ago
removing myself from the cc list

Comment 6

16 years ago
*** Bug 181888 has been marked as a duplicate of this bug. ***


16 years ago
Target Milestone: Future → mozilla1.3alpha

Comment 7

16 years ago
Assignee: kin → rods


16 years ago
Priority: P5 → P2

Comment 8

16 years ago
Dear all,

I strongly recommend having a feature of spell checking. I don't mind if it
works while typing or before sending, but there should be this features.

Especially if you go to use Mozilla in a business environment, you have to have
it. And you have to have it with all languages ( I need it with English and German).

Cheers - gl

Comment 9

15 years ago
I'd be interested in energising this bug, but don't quite know which way to go.
Here is a very quickly hashed together start ...

The Task
In the editor (and the mail/news compose version), when typing and <SPACE> is
hit, traverse back and grab the last typed word. It is straightforward after
that I think because you can just hand the word off to

The Possible Solution
1) Hook up another function (passing event) to the <editor> onkeypress handler.
2) Sniff out SPACE ... do nothing for all other chars typed:
if (event.keyCode == event.DOM_VK_SPACE) {
  // get the word
3) Use one of the DOM Range interfaces to get the word. Which one, I am not sure
(nsIDOMRange ...). Or use the editor document interface and adapt the code in
editor.js/EditorSetSelectionFromOffsets. But I need to get the ranges first. 

Thoughts and some more informed analysis would be appreciated!

Comment 10

15 years ago
*** Bug 229357 has been marked as a duplicate of this bug. ***


15 years ago
Summary: RFE: Need realtime spellchecking mechanism. → Need realtime spellchecking mechanism.


15 years ago
Assignee: rods → nobody
Component: Editor: Core → Spelling checker
QA Contact: sujay → core.spelling-checker


15 years ago
Target Milestone: mozilla1.3alpha → ---
It is not as easy as comment 9 suggests. pasting text needs to work, moving the
cursor out of a word should trigger the word to get checked, loading a document
should check the entire doc etc.

What i think is needed is to listen for all changes of the document. Then all
words that haven't been checked or are modified need to get checked. Except the
word that is currently being typed. That would be the word with the cursor on it.

- split the document into words (where te<b>se</b> is a word, te<br>st are two)
- remember if a word has been checked
- find out if a word is changed
- listen to all changes (load, paste, cursor moves, keys, more?)
- Doing all this in the background. Checking a large loaded document can take
some time.
- UI (styling, context menu, prefs)
- non-sucky spellcheck api's

Comment 12

15 years ago
There are some guy who actually has made a working extension of the realtime
spellchecking mechanism.


Comment 13

15 years ago
A counter-argument, and a possible way of keeping both sides happy...

I don't have any problems with the idea of a real-time spelling checker
*extension*, but I would hate to see it in the core build.

I really like the idea of an ultra-fast, slimline mail client, and spelling
checkers are definitely included in my definition of "bloat". They don't catch
common word substitutions (e.g. "their" versus "there", "hear" versus "here",
etc.), there are issues with regional spelling differences, and they are
hopeless when you use a lot of industry-specific terminology.

But the biggest problem with real-time spelling checkers is the amount of extra
processing required. Far too many mail clients don't keep up with fast typing
anyway, or don't respond quickly enough when you apply or adjust formatting:
having them perform "unnecessary extras" makes them unbearable and unuseable.

*  Not everybody has a nice, powerful computer.

*  Some people who do have nice computers run a large number 
   of applications concurrently, and individual application 
   performance is therefore degraded.
*  People might like to use the same, familiar mail client 
   wherever they are, regardless of how good or bad the 
   hardware at those various locations is.
*  Even in corporate environments, spending on computer 
   hardware and software has been way down for years. You 
   can't automatically assume corporate users have access to 
   up-to-date computers. (In my case, I've got the nice 
   computers at home, and the nasty ones at work!)

However, if at the general release stage (rather than technology preview)
features of this kind ares IMPLEMENTED as extensions but PRESENTED as "standard"
options, both points of view ("do everything" versus "lean and mean") should be
able to be satisfied.

Off the top off my head, I envisage something like the following:

*  The downloadable install set could place a bundle of 
   popular extensions into an "available extensions" 
   subdirectory under the application's home directory.

*  Some sort of file naming convention or a standard internal 
   content element would allow a user-friendly name and/or 
   description to be extracted from the individual extension 
   files *without* installing them.

*  In Thunderbird's Options screen, there would be a section 
   that basically listed the user-friendly name/description 
   of everything in the "available extensions" subdirectory, 
   each with an adjacent checkbox. The checkboxes would both 
   display the status of each "feature" (i.e. extension), and 
   enable the user to activate or deactivate them:
   -  To activate a feature, the user would tick the 
      checkbox, which would install and enable it.
   -  To deactivate a feature, the user would untick the 
      checkbox, which would disable and uninstall it.
   You'd actually probably want to store the initial state of 
   each feature, and then do your installing and enabling (or 
   disabling and uninstalling) when the user chose OK to 
   accept their option changes. This would be more efficient, 
   and more helpful for a user friendliness improvement 
   mentioned below.

*  To access the settings that some extensions have, you 
   could either have a button adjacent to each extension's 
   name/description, or a single button outside the list of 
   features/extensions which when clicked displayed the 
   settings for the feature/extension selected in the list. 
   Either way, the button(s) would be disabled for "features" 
   that weren't activated, and features that didn't have any 

This approach wouldn't handle the extension state of installed but disabled, but
personally I think it's too fine a distinction for the typical end user to be
bothered about anyway. (It certainly is for much of the audience I develop
software for!)

The main resulting problem is the need to exit and restart the application after
changing some of these "features", when you wouldn't if you were simply enabling
and disabling installed extensions. So you'd be faced with a useability
trade-off decision. In my area it seems that it's generally the more
technology-savvy users that look for and fiddle with options, so the need to
exit and restart might not be too big a problem. But it could probably also be
made more user-friendly anyway. For example, instead of giving you multiple
restart warning pop-ups for each feature/extension changed, there could be a
single warning pop-up when you used OK to accept option changes (along the lines
of "Note: Some of the changes you made will not take effect until you exit and
restart Thunderbird").

Comment 14

15 years ago
*** Bug 242675 has been marked as a duplicate of this bug. ***
Most users have a powerfull enoguh computer. For most users, spellcheck is nice.
So just an option (pref, menu, whatever) to turn it off will do.

Comment 16

15 years ago
*** Bug 245568 has been marked as a duplicate of this bug. ***
taking, for now until the person who has a patch takes over.
Assignee: nobody → sspitzer
Component: Spelling checker → Composition
Product: Browser → MailNews

Comment 18

15 years ago
I remember rods sending me an email with lots of situations to handle for
realtime spellchecking. I'll see if I can dig through my mail archive to find
it. Also I believe he also started implementing realtime spellchecking ... for
HTML, not just plaintext, but I think it was all tangled up with the
"spellchecker re-write" code he posted to one of the open spellchecker bugs.

Comment 19

15 years ago
If rods has some skills valuable for the realtime spellchecking mechanism he
should really try to help out Ausdilecce since he almost have a fully functional
extension availible.
More info on that subject exist in the mozillazine-forum
and the extension can be downloaded from
http://www.supportware.net/mozilla/#ext8. It seems like a better idea that rods
check it out before starting to work on an own solution.

Comment 20

15 years ago
Please excuse me in advance if my question does not make any technical sense (I
am not familiar with the mozilla code), but wouldn't it be possible to simply
use the gtkspell library?  (http://gtkspell.sourceforge.net)  I use logjam
(http://logjam.danga.com), which uses it, and it's a real wonder.

Comment 21

15 years ago
We already have a Mozilla implementation that is based on GTKSpell
functionality. We don't use GTKSpell but the functionality is the same.

We hope to get a patch for this code posted to this bug soon.

Comment 22

15 years ago
*** Bug 252562 has been marked as a duplicate of this bug. ***

Comment 23

15 years ago
I see this as a very important feature - one that my mom says makes Thunderbird
feel inferior to old Eudora Pro.  Perhaps some as-you-type spell checking code
can be borrowed from KMail (http://kmail.kde.org/)?  They do a nice job of
highlighting words (not underlining) that are misspelled and providing
suggestions upon a right-click.

Comment 24

15 years ago
Created attachment 154200 [details]
Screen Shot

This we hope to contribute to Mozilla soon. It has been implemented for some
time now for Lindows and is available in their next distro to be release in

Comment 25

15 years ago
Just to echo the KMail comment.  I actually use KMail now, over Thunderbird for
two reasons:
1) it has spell-as-you-go
2) its taskbar icon notifies you of *how many* new email you have, which is
incredibly handy.

I'd go back to Thunderbird if the spell-as-you-go was implemented, which is why
I continue to track its progress.  

Added to this, a friend of mine who is having problems with Outlook finally
heard the gospel and tried Thunderbird last week.  He ditched it within a day
only because of the lack of spell-as-you-go.  

So, hopefully it will be implemented soon as it's a definite "must have" feature
for many people.


15 years ago
Blocks: 213562
Advocacy comments are not usefull at all (except to drive away developers).
Nobody is denying this would be a cool feature.
Code from other projects can't just be intergrated, because other toolkits are
used, other licenses and maybe even other languages.

Comment 27

15 years ago
(In reply to comment #24)
> Created an attachment (id=154200)
> Screen Shot
> This we hope to contribute to Mozilla soon. It has been implemented for some
> time now for Lindows and is available in their next distro to be release in
> August.

That's great news! If you guys already have this implemented, then doesnt this
basically solve the bug? 

Of course, i still dont know whether mozilla would accept the code, what with
licensing issues, etc.

I hope they do, and i must say, the screenshot looks good :-)

Comment 28

15 years ago
FWIW, there is already an extension that addresses this, written by AusDilecce
at the following URL:


It's very much a work-in-progress, but in the spirit of not having effort
duplicated, I thought I'd pass it along...

I haven't used this extensively enough to have any real comments on how well it
works, so I can neither endorse it nor pan it....



14 years ago
Assignee: sspitzer → enndeakin

Comment 29

14 years ago
It would be very nice to check spelling as I type.
As I recall Daniel Glazman has been doing this for Nvu... perhaps after 0.50...
he'll donate some of that code for recycling purposes ;-)

(In reply to comment #30)
> As I recall Daniel Glazman has been doing this for Nvu... perhaps after 0.50...
> he'll donate some of that code for recycling purposes ;-)

I did nothing. The code is Neil Deakin's. I just added a few lines of chrome
to make it work in Nvu and recently based the red underline color of the mispelled
words on a pref. All the credit for this feature should go to Neil. He is working
on a patch that will be attached here soon. Stay tuned.

Comment 32

14 years ago
Created attachment 164452 [details] [diff] [review]
Inline spellchecking patch from Linspire

This is the big patch for inline spellchecking as it appears in Linspire
Internet Suite 1.6, ported to the Mozilla 1.8 trunk. It's a big patch and
touches numerous modules, though mostly editor, extensions/spellcheck, text
frame drawing and selection. I could provide a split up version if desired.

It implements the red underline under mispelled words for things that use the
editor widget. Currently enabled for message compose (plaintext and html), page
composer and html multi-line textareas.
Neil - thank you very very much. I just tried out the patch and it works really
well and here comes the but... I found that changing the pref in about:config
while there was a textarea in another tab caused a crash. I was able to
reproduce it by hitting refresh a couple of times with the tab with the textarea
active, switching to the tab with about:config open, and toggling the pref.
ns_if_addref(nsPresContext * 0xdddddddd) line 114 + 9 bytes
nsTypedSelection::GetPresContext(nsPresContext * * 0x0012d760) line 6585 + 24 bytes
nsTypedSelection::RemoveAllRanges(nsTypedSelection * const 0x032f9d38) line 5546
+ 32 bytes
mozRealTimeSpell::EnableRealTimeSpell(mozRealTimeSpell * const 0x032fadc8, int
0x00000000) line 217
mozRealTimeSpell::Observe(mozRealTimeSpell * const 0x032fadd0, nsISupports *
0x00b8e080, const char * 0x011eb108, const unsigned short * 0x0012d908) line 96
+ 20 bytes

Also, I expect that you already know that the word breaker stops on apostrophes
and then underlines the first half of contractions as misspelled.

Besides that, all I can say is wow and thank you.

Comment 34

14 years ago
This code was implemented on the 1.6 Branch.

I can't reproduce the crasher on the los build of Mozilla. So it must have
something to do with the port to 1.8.

Same goes for the contraction issue. Contractions work fine on 1.6 los build. 

I doubt it has anything to do with the fact that we are using Aspell as our
default spelling engine.

Comment 35

14 years ago
Comment on attachment 164452 [details] [diff] [review]
Inline spellchecking patch from Linspire

>+  if (!(editorFlags & nsIPlaintextEditor::eEditorSingleLineMask) &&
>+      !(editorFlags & nsIPlaintextEditor::eEditorReadonlyMask) &&
>+      !(editorFlags & nsIPlaintextEditor::eEditorDisabledMask)){
!(editorFlags & (nsIPlaintextEditor::eEditorSingleLineMask |
                 nsIPlaintextEditor::eEditorReadonlyMask |
                 nsIPlaintextEditor::eEditorDisabledMask))) {

>+    nsCOMPtr<mozIRealTimeSpell> rts;
Not used.

>+    mEditor->EnableRealTimeSpell(PR_TRUE,NULL);
>+  }
>+  else if (enableRTS == 0){
>+    mEditor->EnableRealTimeSpell(PR_FALSE,NULL);
>+  }
Is multiply enabling/disabling real time spell that expensive?

>         nsAutoString mozQuote;
>         if (NS_SUCCEEDED(content->GetAttr(kNameSpaceID_None, mMozQuoteAtom,
mozQuote))) {
>           *_retval = mozQuote.LowerCaseEqualsLiteral("true");            
>         }
>+        nsAutoString className;
>+        if (NS_SUCCEEDED(content->GetAttr(kNameSpaceID_None, mClassAtom,
className))) {
>+          *_retval = className.EqualsIgnoreCase("moz-signature");
>+        }
else in between? I suppose a quote is unlikely to have a class name...

>-  if (NS_FAILED(rulesRes)) return rulesRes;
>-  return res;
>+  return rulesRes;
This doesn't actually mean the same thing...

>+// Spellchecker code has this. See bug 211343
>+#ifdef XP_MAC
>+#define IS_NBSP_CHAR(c) (((unsigned char)0xca)==(c))
>+#define IS_NBSP_CHAR(c) (((unsigned char)0xa0)==(c))
Although a bug comment suggest it doesn't apply to Unicode strings...

>     if (aTopic == "obs_documentCreated")
>     {
>       var editor = GetCurrentEditor();
>-      if (editor && GetCurrentCommandManager() == aSubject)
>+      if (editor && GetCurrentCommandManager() == aSubject){
>         gMsgCompose.initEditor(editor, window.content);
>+        RealTimeSpell.Init(editor, true);
>+        RealTimeSpell.checkDocument(window.content.document);
>+      }
>     }
How likely is it that new documents need spellchecking?

>+    if (!this.editorRTS) return null;
JS Strict warning: function does not always return a value

>+    var docelem = doc.body;
>+    range.setStartBefore(docelem);
>+    range.setEnd(docelem,docelem.childNodes.length);

>+        if (!suggestion.length) break;
if (!suggestion) would suffice.

>+        var editor = this.target.editor;
More JS strict warnings (unless you only ever context click textareas)...

>+    prefBranch->GetBoolPref(NS_LossyConvertUTF16toASCII(aData).get(), &enable);

+    res = EnableRealTimeSpell(enable);
So, if you change the pref, suddenly everything gets spellchecked?

Comment 36

14 years ago
Created attachment 164987 [details]
review thoughts

Comment 37

14 years ago
Timeless->Josh I read some of your odious comments in the patch. I must say they
exemplify precisely why someone would *never* want to contribute code to Mozilla.

I think this type of attitude is poisonous, anti-productive, repellent, and

If you have a problem with the patch

a. offer some constructive comments/collaboration
b. fix it yourself
c. remove your email from this bug

Otherwise no one wants to hear this type of drivel.

Comment 38

14 years ago
I don't understand.  Are you referring to the review in attachment 164987 [details]?  It
looks entirely relevant and appropriately polite, with the possible exception of
the reference to 'sucky code' which AFAICT is explicitly referring to the old
code being moved/touched, not the new contributed code (and is also a valid
point to bring up in a review, since any touched lines of code, even
rearragements and whitespace changes, will have 'cvs blame' thenceforth point to
whoever checks in the patch).

Comment 39

14 years ago
*** Bug 268676 has been marked as a duplicate of this bug. ***

Comment 40

14 years ago
Found this extension for TB, haven'nt tested it (!):


I had filled a bug specifically for TB (see 268676 ) but it was marked a dupe of
this one.

Comment 41

14 years ago
Created attachment 165576 [details]
Error in In-Line SpellChecker v0.4.72 extension with TB fr-FR win98

(see next comment)

Comment 42

14 years ago
I have tested the extension mentioned in my last 2 comments with the following

 - Windows XP, TB 0.9 fr-FR (release from Mozilla Europe), english and french
dictionaries, works for me, but requires existing c:\AutoCorrect.txt example
file  to be present (separate download from same site)
 - Windows 98, TB 0.9 fr-FR (release from Mozilla Europe), english or french
dictionaries, works for me.

Comment 43

14 years ago
Sorry - last comment should have been "Win98 - does not wok for me"

Comment 44

14 years ago
the extension is not near as stable and fast as the solution from linspire is.

Comment 45

14 years ago
I'll use it fo rthe next few days an report back. Unfortunately I don't use the
Mozilla suite and I don't see this making it to TB anytime soon (meaning in time
for 1.0), so I'll take what's available and WFM.
(In reply to comment #44)

> the extension is not near as stable and fast as the solution from linspire is.

Correct. Neil's code is included in Nvu 0.50, and we estimate the number of
users of Nvu 0.50 to 150,000. We have not a single negative feedback, I repeat
*not a single* negative feedback about this feature in the *thousands* of emails
we received since Nvu 0.50 release.

We only got one comment that requires an answer : the underlining is red is not
"accessible" to color-blind people and this should be configurable. I agree and
it's something I am going to add to Nvu.
(In reply to comment #46)
> Correct. Neil's code is included in Nvu 0.50, and we estimate the number of
> users of Nvu 0.50 to 150,000. We have not a single negative feedback, I repeat
> *not a single* negative feedback about this feature in the *thousands* of emails
> we received since Nvu 0.50 release.

One by blog ;-)


I still think there needs to be more of a delay.  

Just try typing "welcome to my website" in NVU.  The red lin flashes during
writing welcome, and website.  IMHO it shouldn't start until the word (as
defined by a " " after a series of alpha characters is entered.

Comment 48

14 years ago
Daniel: Some czech user note that wavy underline (~~~~~~~) in MS Word is great.
Maybe something like border-bottom:1px -moz-wavy #C00 should be solution.

Comment 49

14 years ago
I have both Nvu 0.5 and Thunderbird 0.9 with the In-Line SpellChecker v0.4.72
extension installed on my machine.

I have to agree that as I use Nvu I find the flashing red line is distracting
and I miss the auto-correction feature of Thurderbird extension. My machine is
pretty fast so I can't comment on differences in speed between the two
implementations but I can say I haven't noticed any stability issues with either.

Neil's may every well be the better implementation, but I would like to see it
expanded to use 1) the extension's wavy underline, 2) an option to use the
extension's delayed spell-check-on-word-break, and 3) the extension's
auto-correction feature.

Comment 50

14 years ago
mozilla@pottinger.ca: why did you select assigned? are you working with neil?

Comment 51

14 years ago
Maybe the devs should consider adding spellchecking as you type to the
richtext/textbox widget instead. This will not only allow tb to do realtime
spellchecking, but it will also allow fx and sb to do the same.

Comment 52

14 years ago
*** Bug 270960 has been marked as a duplicate of this bug. ***
Product: MailNews → Core

Comment 53

14 years ago
The In-Line SpellChecker v0.4.72 extension is really a poor solution. It has numerous irritating bugs. 
And the extension does not work under TB 1.0. Probably some sort of versioning problem.

I'm very disappointed that this feature did not make it into TB 1.0 proper. I had come to rely on the Mac 
OS X Mail.app's inline spell checker. Moving to TB has made me change the way I work and dumped me 
twenty years in the past where spell checking was a modal process.

Comment 54

14 years ago
Any chance to implement the inline spell checker that's built into the Mac? The other platforms should 
be able to use whatever spell checker their manufacture provides. That would be the best solution for 
all platforms.
(In reply to comment #54)
> Any chance to implement the inline spell checker that's built into the Mac?
The other platforms should 
> be able to use whatever spell checker their manufacture provides. That would
be the best solution for 
> all platforms.

Yes, I'd love to have the Grammar & Style checker on Windows, inline or not, but
the one which is used by Microsoft Office. Nonetheless, is it technically and
legally possible to integrate this feature? I think that I've dealt with one
small, non-commercial programme (some plug-in for Far Manager, to be exact) that
uses the Microsoft Office spell-checker, so it should be possible to code it one
way or another. 

P.S. I have to admit that right now I am copying and pasting everything
(including the mail) into Microsoft Word in order to make sure that everything
looks okay. And I think, I am not alone in this. :-)
Alias: inlineSpell
Can we move the discussion about what you all want to somewhere else, and
concentrate on the actual patch? Complaining that an extension isn't good enough
for you doesn't help geeting the patch reviewed and all.

Comment 57

14 years ago
*** Bug 267147 has been marked as a duplicate of this bug. ***

Comment 58

14 years ago
see Bug 278310 and Bug 278312 for further work

Comment 59

14 years ago
Absolutely neccesary for modern eMailing.

Comment 60

14 years ago
Comment on attachment 164452 [details] [diff] [review]
Inline spellchecking patch from Linspire

>Index: editor/libeditor/base/nsEditor.cpp

>   mEditorObservers = 0;
>+  if (mRealTimeSpell){
>+    mRealTimeSpell->Destroy();
>+    mRealTimeSpell = nsnull;
>+  }

This is a very bad thing to do. mRealTimeSpell is refcounted, and you don't
know who is holding references to it outside of editor (like JS, for example).
You should just release your owning reference here.

If Destroy() needs to called to clean up state, then call it here, but ensure
that the orphaned mRealTimeSpell object won't crash if any of its methods are


14 years ago
Blocks: 151040

Comment 61

14 years ago
Doh, scratch that last comment. I see that Destroy() does not delete. I would
suggest, however, that Destroy() is renamed to Cleanup() or something. It
doesn't actually destroy the object.

Comment 62

14 years ago
Comment on attachment 164452 [details] [diff] [review]
Inline spellchecking patch from Linspire

How about we strive to look intelligent by not misspelling "misspelled"?

Comment 63

14 years ago
How is this patch coming along?

Comment 64

14 years ago
Scott used this patch as a basis for his back end work in bug 278312. Note that
Thunderbird trunk builds support inline spell checking since February.

Thunderbird's front end was fixed by bug 278310 and a couple of follow-ups.
That was just ported to Seamonkey by bug 291799.

I'm still missing inline spell check in <textarea>s though.
Depends on: 278310, 278312, 291799

Comment 65

14 years ago
We don't have spellcheck in Suite's web page editor yet either.


14 years ago
Blocks: 163993


14 years ago
No longer blocks: 163993

Comment 66

14 years ago
This would be a killer feature - Konq already does it, and IE doesn't :-)

Comment 67

13 years ago
Can this patch be cleaned up, and targeted for Gecko 1.9?

Comment 68

13 years ago
The patch here is already available in cleaned up form in Gecko 1.8. The only
extra piece needed for textarea spelling is the nsTextControlFrame.cpp changes
and the UI changes in xpfe/communicator.

The patch here doesn't include any page composer support, although it is also
just UI changes similar to the browser part.

I plan to provide an updated patch for inline spell in textareas for Firefox at
some point.
*** Bug 305865 has been marked as a duplicate of this bug. ***


13 years ago
Summary: Need realtime spellchecking mechanism. → Need realtime spellchecking mechanism for <textarea>s and editor

Comment 70

13 years ago
Has there been any work on inline spellcheck for textareas in firefox-1.5? This is the only bug I find. Are there any pointers to info or bugs. 

Comment 71

13 years ago
Firefox 1.5 has already been released, and I assume this feature would be too big a change for the maintenance releases. It is slated to be in Firefox 2.0, though.

However, if you want to get spellchecking in 1.5, check out the Aspell extension (disclaimer: I've never tried it myself). http://forums.mozillazine.org/viewtopic.php?p=1977210

Comment 72

13 years ago
See bug 302050 and its dependencies, which is fixed on trunk. It needs to be ported to the 1.8 branch for Firefox 2.0, see bug 329668.

Comment 73

13 years ago
(In reply to comment #70)
> Has there been any work on inline spellcheck for textareas in firefox-1.5? This
> is the only bug I find. Are there any pointers to info or bugs. 

Probably the best/most popular spell check extension is SpellBound which can be installed from http://spellbound.sourceforge.net/install.

Comment 74

13 years ago
Though I've been using the 'development' spellbound from http://forums.mozillazine.org/viewtopic.php?t=351130
on both Windows and Linux for months now with no issues - features in-line text area red-squiggle underlines, ctrl-left click to select alternative spellings.
Now editor has inline spellchecking (nsIInlineSpellChecker interface), textbox has it too since it has property 'editor' that returns nsIEditor interface. What about is the bug?

I guess the current problem only is that textbox context menu doesn't contains items for spellchecking support (f.x. I think context menu should have item for suggested words).

Comment 76

13 years ago
This bug, about implementing inline spell in Mail Compose has been fixed for a while. Other bugs, like 338318 are about inline spellcheck in other areas.
Last Resolved: 13 years ago
Resolution: --- → FIXED
Summary: Need realtime spellchecking mechanism for <textarea>s and editor → Need realtime spellchecking mechanism for mailnews
Verified FIXED.  This has, like Neil said, been in--even in SeaMonkey--for quite a while now.

Build 2006-08-13-06 of SeaMonkey trunk under Windows XP.
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.