Closed Bug 58612 (inlineSpell) Opened 23 years ago Closed 18 years ago

Need realtime spellchecking mechanism for mailnews

Categories

(MailNews Core :: Composition, enhancement, P2)

Product:
MailNews Core
Component:
Composition
Type:
enhancement

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: kinmoz, Assigned: enndeakin)

References

Details

Attachments

(4 files)

Screen Shot
81.75 KB, image/png
Details
Inline spellchecking patch from Linspire
159.25 KB, patch
Details | Diff | Splinter Review
review thoughts
26.24 KB, text/plain
Details
Error in In-Line SpellChecker v0.4.72 extension with TB fr-FR win98
36.60 KB, image/jpeg
Details 
The editor needs a mechanism that will allow us to do realtime spellchecking. 
(Spellchecking as you type.)
*** Bug 60310 has been marked as a duplicate of this bug. ***
moving to future
Severity: normal → enhancement
Priority: P3 → P5
Target Milestone: --- → Future
Not in preview mode.
*** Bug 6795 has been marked as a duplicate of this bug. ***
Blocks: 119232
removing myself from the cc list
*** Bug 181888 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Target Milestone: Future → mozilla1.3alpha
taking
Assignee: kin → rods
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Priority: P5 → P2
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
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
IEditorSpellCheck:CheckCurrentWord.

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!
*** Bug 229357 has been marked as a duplicate of this bug. ***
Summary: RFE: Need realtime spellchecking mechanism. → Need realtime spellchecking mechanism.
Assignee: rods → nobody
Status: ASSIGNED → NEW
Component: Editor: Core → Spelling checker
QA Contact: sujay → core.spelling-checker
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.

Tasks:
- 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
There are some guy who actually has made a working extension of the realtime
spellchecking mechanism.

http://forums.mozillazine.org/viewtopic.php?p=500923#500923
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 
   settings.

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

*** 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.
*** 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
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.
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
http://forums.mozillazine.org/viewtopic.php?t=63506&postdays=0&postorder=asc&postsperpage=15&start=0
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.
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.
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.


*** Bug 252562 has been marked as a duplicate of this bug. ***
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.
Attached image 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.
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.
Blocks: eudora
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.
(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 :-)
FWIW, there is already an extension that addresses this, written by AusDilecce
at the following URL:

http://www.supportware.net/mozilla/

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

Erick
Assignee: sspitzer → enndeakin
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.
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.
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 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))
>+#else
>+#define IS_NBSP_CHAR(c) (((unsigned char)0xa0)==(c))
>+#endif
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);
range.selectNodeContents(doc.body);

>+        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);
Might as well use PREF_ENABLEREALTIMESPELL

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

    
    

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

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.

    
    

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


    
    

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

    
    

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

http://kb.mozillazine.org/index.phtml?title=Thunderbird_:_FAQs:_Inline_Spell
http://www.supportware.net/mozilla/#ext8

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

    
    

    
  
I have tested the extension mentioned in my last 2 comments with the following
results:

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


    
    

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

    
    

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

    
    

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

http://robert.accettura.com/archives/2004/10/12/nvu-050-released/

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.

    
    

    
  
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.

    
    

    
  
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.
Status: NEW → ASSIGNED

    
    

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

    
    

    
  
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.

    
    

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

    
    

    
  
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.

    
    

    
  
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.

    
    

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

    
    

    
  
see Bug 278310 and Bug 278312 for further work

    
    

    
  
Absolutely neccesary for modern eMailing.

    
    

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

    
    

    
  
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 on attachment 164452 [details] [diff] [review]
Inline spellchecking patch from Linspire

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

    
    

    
  
How is this patch coming along?

    
    

    
  
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

    
    

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

    
  
Blocks: majorbugs

    
  
No longer blocks: majorbugs

    
    

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

    
    

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

    
    

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

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

    
    

    
  
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. 

    
    

    
  
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

    
    

    
  
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.

    
    

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


    
    

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

    
    

    
  
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.

Status: ASSIGNED → RESOLVED
Closed: 18 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.
Status: RESOLVED → VERIFIED
Product: Core → MailNews Core

          You need to log in
          before you can comment on or make changes to this bug.