I received a request from IBM -- they would like to be able to invoke spell check from the browser window. The workflow scenario is this: They utilize a lot of forms, which consist of numerous text fields. They would like for the user to be able to fill in the form fields and then run spell check to ensure proper spelling. This makes a lot of sense especially if the data is being ported into a database of some sort. The underlying architecture is there, providing the access is where the work comes in, but that should be trivial I would think.
Summary: invoke spell check in browser window → [RFE] invoke spell check in browser window
QA Assigning to Sujay. (Spell check-issue.) Sujay: Do you know which engineer owns spellchecker and should receive this bug?
20 years ago
Assignee: don → karnaze
Component: Browser-General → HTML Form Controls
Since this is lying around in Browser-General, changing component to HTML Form Controls and reassigning...
Reassigning to Steve.
I could provide the hook for some controller to spell check a single text control, but is would be up to the browser team to write the code to enumerate all the text controls on a page and spell check them one at a time. Some extra work would be required to support things like "replace all" across multiple text controls. Here's my plan: 1) put in the underlying API to allow spell checking in a single text control. This is simple. 2) get a discussion started on the newsgroup with the editor and browser folks to find out what mechanisms are required to make multiple-textcontrol spell checking happen. 3) make sure all the infrastructure for this is in place. 4) work with beppe and don to prioritize the feature, maybe somebody from IBM would be interested in implementing it if we give them enough plumbing? Beth, want to cc your IBM contacts?
moving to m20 along with the other RFE's
*** Bug 20852 has been marked as a duplicate of this bug. ***
Reassigning to beppe (editor).
Assignee: buster → beppe
Status: ASSIGNED → NEW
assigning to Kin for review
Assignee: beppe → kin
Status: NEW → ASSIGNED
moving to future milestone
Assignee: kin → beppe
Status: ASSIGNED → NEW
moving back to previous owner
Assignee: beppe → kin
Status: NEW → ASSIGNED
adding help wanted keyword
This feature is also useful for web mail (and Bugzilla comment textareas :-)
*** Bug 63059 has been marked as a duplicate of this bug. ***
*** Bug 66109 has been marked as a duplicate of this bug. ***
It would also be useful to be able to right-click on a textarea and select "Spell check" to check a single form control.
An option for check spelling every textarea before submitting any form would be ideal. I use mozilla with a web server as a database administration tool for a web site (as many other do) and being able to submit the information without having to write it on a word processor would save a LOT of time.
If Editor has Spell Check, this would be a really cool feature!!!!
removing myself from the cc list
i'm very interested in working on this. could someone fill me in on status and direction for next steps?
CCing David in hope he would be able to answer Sid's question.
The bug to look at fixing is 129704. Once the spellchecker interface can take and arbitrary chunk of dom text, and check and modify it. Adding spellcheck to the form fields will be relatively easy. [As will not checking quoted text, and all of the other clunky features of the current checker.] The checking part is relatively easy -- look at nsFind and nsWebBrowserFind, the replacing is tricky -- look at nsTextServicesDocument.
*** Bug 138025 has been marked as a duplicate of this bug. ***
*** Bug 148703 has been marked as a duplicate of this bug. ***
beppe - Since IBM originally put in the feature request, is there any chance they'd be willing to dedicate the resources necessary?
I have no idea if they would or would not. But, I think this particular request is gathering interest from netscape folks.
is any work being done on this? Check out this nifty add-on for IE: http://www.iespell.com/ Could we perhaps target something similar, an xpi-based add-on to be distributed via Mozdev or other channels?
iespell is a third party add-on for IE, but this doesn't diminish the fact that it *is* a killer IE feature, for those who are familiar with it. Advocating Mozilla to these users is difficult at best. It blocks Bug 92997 "Bugs that make Mozilla advocacy harder" (although formally it doesn't yet). With mozilla I have to copy and paste the text to an external spell checker. Not nearly as user friendly. An iespell clone is where we should aim at, it has prefect design and implementation, IMO. Prog.
Is this bug asking for a spell cheacker for forms?
> Is this bug asking for a spell cheacker for forms? Basically, yes.
Summary: [RFE] invoke spell check in browser window (multiple form fields) → invoke spell check in browser window (multiple form fields)
Same comment as what I see everyone else has to say. IE has this as a killer feature. Spell checker is obviously available, just needs the hooks into the browser window. Anxious to see this one available! (Don't know about anyone else's thoughts, but why look for a plug-in if the capability is already available!)
*** Bug 184194 has been marked as a duplicate of this bug. ***
UI suggestion for TEXTAREAs: Put a small spellcheck button/icon in the upper-right of each textarea. Click to check spelling of that textarea. If the textarea has a vertical scrollbar, put the icon above and in line with the scrollbar. (I personally don't need to check spelling in one-line text INPUT widgets, and spellchecking everything on things like a Bugzilla form would be a hassle.) Having a Check Spelling item in the textarea's context menu would be OK, but the icon is the kind of cutesy thing that gets people's attention.
And I suggest it only show that little checkbox either, when you have your mouse over that field, or it is in focus.
I suggest that all misspelled words automatic get a red underline like in gnome-spell. And you get the spell checker interface by right clicking on the misspelled word. A option to underline all misspelled words in the entire web page would be good for web development.
There are three browsers at the moment that already offer this functionality: Microsoft IE6 (via ieSpell), OmniWeb 4.1.x for Mac OS X and the new public beta of Apples' own Safari browser. As time goes by, this will be a standard feature on all web browsers (as it is today on most word processing applications and email clients). Prog.
"As time goes by, this will be a standard feature on all web browsers (as it is today on most word processing applications and email clients)." I really don't think the devs care. It is my experience with this project that it takes an act of god to get any non-crash/non-critical bug fixed or feature added. But the time that becomes a standard feature it will take Mozilla devs another 4 years to catch up. Because implimenting inovative features (or *any* new version for that matter) is not something that I believe the Mozilla devs understand the concept of. They tend to like playing catch-up instead. I think they have a limit of a few unique/inovative things per every four years (TypeAhead Find, pop-up blocking, tabs). *sigh* All well, what can you do.
*** Bug 200877 has been marked as a duplicate of this bug. ***
*** Bug 200939 has been marked as a duplicate of this bug. ***
It seems like the author of ieSpell would be willing to implement this in Mozilla, but he does need some help. Here's a quote from ieSpell's forum: "Support for Mozilla would be possible if I can get my hands (or know where to anyways) on its DOM APIs! Any Mozilla gurus willing to offer a hand?" http://groups.yahoo.com/group/iespell/message/186 http://www.iespell.com/contact.htm Anyone? Prog.
>It seems like the author of ieSpell would be willing to implement this in Mozilla That would be great because I would be able to add words to user dictionary only once if I use IE and Phoenix. Of course, ieSpell would have to share the user dictionary for different browsers then. And rename to something more generic.
In my opinion, UI clutter such as red underlined text and icons within textareas are really, really bad ideas. Please, keep it simple. All you need is a right click menu item for individual forms and an upper menu item for the whole page. That being said, I think this enhancement is really important. Many non-technical people rely on web mail for their day-to-day correspondence and Scoop/Slash style dicussion boards are becoming more and more important news sources.
I agree with Mark the Ominous Squirrel. A right-click context menu is fine to start with. Get the functionality in there right away, then worry about the frills. (Yeah, I know I was yabbering about icons and such, but I'm more eager for the feature then it's appearance.)
A right click -> spellcheck would be a GREAT addition to Mozilla, even if it only checked the current field. This might actually be an advantage over IEspell, as it checks all form fields, including hidden ones (AFAIK)
Is there any activity being done to close this bug? Can anyone give an guidence on where to start. With IE not coming out with a new version until Longhorn, this is an excellent opportunity for the mozilla browser to leapfrog IE in features (again ;) ).
Sorry, should have check the related bugs... I noticed this: http://spellchecker.mozdev.org/ Looks like they have it implemented for mail and composer... What would it take to add it to Browser to check form fields?
Chris: see comment 24 and bug 129704. It looks like this is being held up by some spellchecker refactoring. Also, look at the mozex project on MozDev, which (among other things) allows you to use an external program to edit textareas.
Spell checking in forms would be a good thing to have for Firebird 1.0. A nice enhancement to have built in (and beat IE with). Especially good fur checking bugzilla posts. Good speling is esenteal wen riting bugs.
Is there any way to create a bounty for this bug that everyone who wants to see it done could chip in on?
I'm waiting for spell checker for forms by a long time... This bug report start in: 28/10/1999 Today is: 28/08/2003 Something was did since than? Now, how it is (1.4), i have to copy the form's text, create a new mail message, paste the text, use the spell checker, copy the checked text, than paste at the form. We just need to understand, that one browser is better than other because of the good features, just it. And form spell checking is a must have, like Tabs.
Henrique Sant'Anna, You should read this: http://bugzilla.mozilla.org/page.cgi?id=etiquette.html I suggest that you pay special attention to sections 1.1 and 1.2. Prog.
This would be useful even if the spellchecker only underlined mispelled words (as many word processors do). If that's substantially easier, it would make a great first step. The ability to check spelling would eliminate a lot of emberrasing mispellins that we all see too often. That, combined with the ability to call up an external editor for a TEXTAREA, would pretty much put us in form-based nirvana. (Keywords: TEXTAREA text input from spell spelling spellchecking spellchecker rfe feature underline mispelled words. See also Bug #23421 )
> That, combined with the ability to call up an external editor for a TEXTAREA, would pretty much put us in form-based nirvana. The mozex extension ( http://mozex.mozdev.org/ ) has this ability.
I've created a SourceSupport project for this bug at: http://sourcesupport.org/?project=43 Please Donate. Please Publicize. If we get enough donations, hopefully someone will fix this bug. Thank you.
Any idea how much time / cost it would take to do this? It would really be a great new feature now that spellcheck is in the trunk.
Be very cool to have :) even just an extension would be nice
Thanks to the work of Torisugari, it seems to be done! See http://forums.mozillazine.org/viewtopic.php?t=34799 and read the entire thread for news, info, and download links. Torisugari has versions available for the Mozilla Suite as well as for Firebird.
Is there an actual patch that could be tested and checked in?
Yes,Aleksey. Go to http://forums.mozillazine.org/viewtopic.php?t=34799 and you will find the links as you go through the messages. I have the Mozilla Suite Spellchecker Front End 0.3 extension installed and used it to spell check these postings. Torisugari has not posted the code to the Mozillazine Forums, naturally, but I would think that he would be happy to have you review his xpi installers and the code therein. I have posted a note for him in the MZ Forums. He has been quite active there lately, and I suspect he will see it soon.
Comment on attachment 136224 [details] [diff] [review] patch 1 Please change email@example.com to firstname.lastname@example.org (or e-mail him and ask him what e-mail address he'd prefer there). Does function Startup() have tabs in it? Please fix indentation to 2-spaces per level. Check throughout the function; lots of inconsistency on indenting. curLang = "" should not be necessary in the catch. fix this comment: ...see bug XXXXX In function FillSuggestedList, combine these if's: + if (count==0) + if (word.length > 0) It seems like Replace and ReplaceAll could be one function that takes a boolean parameter for "all"; is there some reason not to do that? In CheckWord, the assignment to null isn't necessary since you reassign it in the next line. In SelectSuggestedWord, add a semicolon after: var selectedItem In "Recheck", remove TODO comment unless you added it. Fix the license in browserSpellCheck.xul (I assume it should be changed to MPL). In browserSpellCheckOverlay.xul, add your own name as a contributor? Are there tabs in browserSpellCheckOverlay.xul? Add a blank line to the end of that file. ok, the above was just a high level scan at the patch. Here are some harder questions / issues: * Has this been tested with the browser's rich text editing ("Midas")? * Has this been tested with Composer and Mail Compose? Do they work as they should? * I have some reservations about all the new code (duplication?). I'd prefer to see a common spellchecker that Composer, browser, and mail all use. On a final note, I am *THRILLED* to see someone working on this; I can't wait to have it in my builds! Please clean it up a little so we can land it!
Attachment #136224 - Flags: review-
For what it is worth: I am currently doing some cleanup in the spellcheck code. With that, i was thinking about how to fix this bug. My idea was to create a new interface, mozIStringSpellCheck.idl, that just spellchecks a string. The value of a html for element is just a string, so that would work. This would also help spellchecking in chatzilla, or the subject of the email. I don't really like the copying of the XUL/js code. My idea was just to move it into extensions/spellcheck, and have some |if| statements depending on what is spellchecked. Also, the inconsitency between checking an email (replacing inline) and a form (text copied into a new window) is ehm, inconsistent :) But let all this not stop you, i am just telling you my ideas :) It would be really cool to have this working. About your patch: You have some inline styles, please remove them. You seem to read prefs for the font to use, you should remove that too. Why should the spellcheck dialog use a different font? You can remove install.js
I didn't test the patch, but using the beta extension, I did find a few problems: 1. Enable Wrap should IMHO be the default. It makes it much easier to use the spellchecker than having to scroll to read the context. 2. Sometimes, the highlighted word is displayed outside the textarea, requiring the user to scroll in order to see it. 3. It seems impossible to spellcheck text selections. 4. Since there are only two options in the menu, it might be better to cancel the menu and add two buttons instead. 5. If the menu is kept, there should be a separating line between it and the textarea, otherwise, the word "Menu" looks like the title of the textarea (at least when using the Modern theme) 6. The spellchecker should ideally ignore UPPERCASE and URLs. 7. "Completed spell checking" is displayed in the Misspelled Word field and is not visible enough for users who choose to view the main textarea instead. A message box with the same text would probably be easier to spot. Other than these minor issues, I'm very happy with the result. Thanks! Prog.
Shouldn't this bug be re-assigned to the email@example.com? Prog.
I'm thrilled to see this finally coming. I also agree that it would be wiser to have a universal spellchecker that the browser, mail and composer all use. It just makes more sense. Not to mention, when I "add word", it would carry across, thunderbird, firebird, etc. That way I don't add my last name "Accettura" (which sadly, isn't in the dictionary), 3 times. To me, I would like to see the following done in general to spell check (which applies to this: - Ability to select a word to spell check, rather than entire body of text - Ability to right click into a field in a form, and spell check (unless, just word, then above) More specific to this bug, I'm attaching an image, of what i would propose. Putting a mouse over the field, would bring up a menu, similar to the "Image Buttons" brought up by IE over an image. Containing some popular things (Copy, paste, spellcheck, perhaps undo/redo?). Do it perhaps transparent (Possible?), would look clean, and easy to use for end users. Hold mo End users, look for a features to be in their face, they don't like spending 20 minutes figuring out how to use things. Meaning, we need to put it in an easy to find place. A menu like above would make it cleanand simple for them. An option to disable may be needed. Anyway, that's my idea on implementation. Would be a nice smooth way to put the feature in the users grasp, without forcing them to look it up. My fear is that, another option in a menu, will go unnoticed, even by some longtime mozilla lovers. Same with using right click. Will get lost. The icons from cutemenu (http://cute.mozdev.org/index.html) might be a good icon base to use for such an implementation. A good question to ask, is should this bug also apply to text fields in XUL? Meaning every preference, extension's field gets spell checking? Perhaps in those cases, the menu would be off, and just use right click? Just thoughts, I'm sure some will disagree completely, but perhaps logic exists in madness. Pathetic childlike Mockup of my minddrippings coming.
Robert, I am a little uncertain about what your buttons would do. I like the idea (sort of) of a checkbox that shows when your spelling is correct, but let us be honest, the underlining method (a la Abiword or gnome spell as previously mentioned) is the best way of determining whether you've misspelled things. Any underline feature/pop-up on the form field as proposed in the screenshot should be optional and turned off by default. Why? I think Firebird--in order to be the super-IE-- needs to avoid confusing people. The underlining might be OK.. but popping up buttons isn't in my book. Again, options are fine-- c.f Firebird Manifsto.. I actually strongly support the implementation of underlining.. just questioning whether a browser should have this setting by default for the Last Name field--in the first place. --Sam
re Comment #67, Robert J. Accettura: please file a new bug asking for a pref for a personal dictionary path. the current code almost certainly sticks the personal dictionary into your profile directory which makes it per profile per application.
Thanks for the reviews. It seems that I have a lot of things to learn. I modified those other than wrapping replace functions and my name things. IMHO, this bug is not depend on redesign bug 129704, though i'm interested also in it. >Has this been tested with Composer and Mail Compose? No, but it's not difficult with patch 2. Please take a look at chatzillaSpellCheckOverlay.xul. Is it also blocking this bug?
Comment on attachment 136722 [details] [diff] [review] patch 2 You used a different UI then composer spellcheck. Instead of spellchecking the original, and changing words there, you seem to copy the text into the dialog. Is there a specific reason for that? Most app i know use the way composer does it.
>Is there a specific reason for that? 1) Simply because it's easier, though easy come may easily go away. 2) We don't have enough API to access textarea and input, in cross platform way, right? If possible, I would like to keep away from original DOM elements, because a web site developer might set some event handlers ( e.g. onselection event! ).
You might have a point on the technical issues, especially the dom event. But maybe at least some of them _should_ fire, because content is changed? I still think that UI wise editing the original element is better. You also don't have to worry about wrapping and such, because the author of the web page have taken care of that. But if it turns out the be too hard, too ugly, or even impossible to do that, you solution will work too. btw, what happens when you try to spellcheck 'contenteditable' (midas)? That is rich text. Do you copy that?
For anyone who isn't following the Mozillazine thread, new updates are available: http://forums.mozillazine.org/viewtopic.php?t=34799 Torisugari, where would you like to discuss suggestions and issues, in the aforementioned thread, or here in Bugzilla? Prog.
*** Bug 236283 has been marked as a duplicate of this bug. ***
*** Bug 240260 has been marked as a duplicate of this bug. ***
*** Bug 249531 has been marked as a duplicate of this bug. ***
*** Bug 256698 has been marked as a duplicate of this bug. ***
FYI, Firefox .9+ has spellchecker extension called SpellBound (http://spellbound.sourceforge.net/)
*** Bug 257659 has been marked as a duplicate of this bug. ***
Whiteboard: See above URL for a Firefox spellcheck extension
*** Bug 335103 has been marked as a duplicate of this bug. ***
This was implemented in bug 302050.
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
Are you sure about that? Bug 302050 is Firefox specific. This bug is targetted against core. If SeaMonkey doesn't have this, then this bug shouldn't be resolved as is...
Most of the code is in core: content, layout, extensions/spellcheck. The UI is in toolkit, which I guess seamonkey doesn't use yet, but they can copy the file (there's only one). There are a few hooks in browser.js to make it go. I would argue that this capability now exists in the core. Whether seamonkey uses it or not is up to them.
Filed Seamonkey specific bug 338318 as follow-up.
You need to log in before you can comment on or make changes to this bug.