User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008050504 Minefield/3.0pre Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008050504 Minefield/3.0pre I'm finding that text fields in Minefield are not always spell checked, despite having the Check Spelling box checked. Some times it works but much of the time it doesn't. I'm especially noticing this behavior on my WordPress.com blog but the behavior is certainly not restricted to that site. Reproducible: Always Steps to Reproduce: 1. Enter some text in a text box that includes misspelled words 2. Right click inside the text box and verify that the Check Spelling box is checked 3. Look for indications that words are identified as misspelled Actual Results: No words are shown as misspelled and right clicking on a known misspelled word does not offer any spelling alternatives. Expected Results: As words are typed with misspellings the built-ion spell checker should flag them as being misspelled and a right click on a misspelled word should reveal other possible spellings as well as an option to add the spelling to the dictionary I am running Minefield 3.0pre nightly from Mozilla, not from Ubuntu's repositories.
Assignee: nobody → mscott
Component: General → Spelling checker
Product: Firefox → Core
QA Contact: general → spelling-checker
Version: unspecified → Trunk
There is a limit in the number of misspellings reported in a text box. Maybe you're hitting this limit? The following testcase can demonstrate this: Open this URL: data:text/html,<textarea cols="100" rows="100"> Cut and paste a long non-english wikipedia article in that textarea. Only the first first 500 misspellings on top of the textarea are reported (default built-in configuration).
This definitely isn't what I'm seeing. I have much less than 50 errors in a post, even counting words that I've added to the dictionary. Could it be a bug in WordPress.com's rich text editor? Although I also get the behavior when using their plain text editor so I'm not sure that would be the case.
I've discovered the same aggravating bug, also while using Wordpress. The version of Firefox I'm using is: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5
I don't have a Wordpress installation to try to reproduce this bug. Do you know about a public page where this can be reproduced? Otherwise, you could try to save the wordpress editor page (File > Save Page As ...> Web Page, complete) and attach it there (with the required .css/.js files) if you can reproduce the issue on the saved page. Another useful thing would be to try with a nightly to see of the issue has been fixed since beta 5 (http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/)
Nightlies are what I use so no, it hasn't been fixed since b5. The bug still exists in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008051204 Minefield/3.0pre ID:2008051204 I'm unable to save the page properly for what you need, but I have a blog on wordpress.com, not a local installation of WP.
Same for me, I create/edit my blogs using the rich text editor embedded into wordpress.com. I doubt this issue has to do with wordpress itself, as the problem only occurs while using the beta edition of Firefox.
ok, I created an account there. Wordpress is using TinyMCE for the blog editor. I could reproduce the issue on the simple TinyMCE example: http://tinymce.moxiecode.com/example.php?example=true Only the first misspelled word is detected.
I'm seeing two different issues with spell checking and the TinyMCE editor, one of which regressed but not the other. 1) Only the first misspelled word is underlined when spell check is enabled on an editor: * Open http://tinymce.moxiecode.com/example.php?example=true * By default the editor won't have spell checking enabled * Type some incorrect words in the editor * Now right click the editor and select "Check spelling" * Actual result: only the first incorrect word is underlined * Expected: all incorrect words are underlined This issue exists since Firefox 2 2) New typed text in the editor is not checked for spelling errors * Open http://tinymce.moxiecode.com/example.php?example=true * right click the editor and select "Check spelling" * Enter some incorrect words * Actual: newly typed incorrect words are not underlined * Expected: all newly typed incorrect words are underlined This second issue regressed during the range: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-12-18+04%3A00%3A00&maxdate=2007-12-19+04%3A00%3A00&cvsroot=%2Fcvsroot
Status: UNCONFIRMED → NEW
Ever confirmed: true
Regression from bug 389933. If I comment the added if block in nsHTMLEditRules.cpp the issue 2) above is gone.
The first two instances of "Lapham" are highlighted/underlined as misspelled. The third use of "Lapham" is not, however.
(In reply to comment #10) > Created an attachment (id=322187) [details] > Spellchecker missed on instance of unknown word > > The first two instances of "Lapham" are highlighted/underlined as misspelled. > The third use of "Lapham" is not, however. > I'm not sure if this attachment is related or not, but I found that in Firefox 3.0b5 this text box in Google's Gmail pages (editing rich-text) did not underline all instances of the same mispelled word. As this is only a short passage, I don't see the max limit of highlighted words being reached. This is on: Firefox 3.0b5 Linux 2.6.24-16-generic #1 SMP Thu Apr 10 12:47:45 UTC 2008 x86_64 GNU/Linux Gnome 2.22.1 Distro: Ubuntu 8.04
This is a pretty serious regression for both Thunderbird and Firefox; requested blocking-1.9.1. cpearce, is this something you could take a look at, since it appears to have been caused by your checkin?
No longer blocks: 429118
So is there a minimal testcase for this? Or how to reproduce? Spell checker works ok for me on this bugzilla textarea and I also tested writing a rich text mail in gmail. (Will test TinyMCE)
Looks like a minimal testcase is missing here. I tried the steps from comment 8: The TinyMCE url is not valid any more. I used this new one: http://tinymce.moxiecode.com/examples/simple.php I couldn't reproduce issue 1) with Firefox 2 or an old trunk build, so I guess something in TinyMCE changed which does not trigger the issue any more. Issue 2) is still present (which is what this bug is about). I would rather describe the steps as: * Open http://tinymce.moxiecode.com/examples/simple.php * right click the editor and select "Check spelling" * Go to the end of the text area, press return * Type "badword badword", notice that only the first incorrect word is underlined. * Press return * Notice that first underlined word of the previous line is not underlined any more * Type "hello badword", notice that the incorrect word is not underlined. I couldn't reproduce it in the gmail editor or the midas demo (http://www.mozilla.org/editor/midasdemo/)
Hard to tell, since both this and bug 429118 seem to have described different behaviors at different times (starting with "nothing" or "one word" and moving toward "a dozen" so my guess is it regressed really badly for a while, then settled into the current behavior), but the one simple test that I know currently exists is: 1. Load http://www.mozilla.org/editor/midasdemo/ 2. Start typing nonsense like sldkjlksj sljdflks 3. Note that you stop getting things marked after a dozen words, not the 500 it should be There's also some discussion of the range changes introduced by a newline in bug 429118, that might explain Sylvain's comment 15 results (to someone who understands them, they might, anyway).
Hmm, and apparently there's a difference between typing and loading, since data:text/html,<div contentEditable="true">sdk sdkj</div> is a pretty minimal testcase for "only the first misspelled word is checked".
(In reply to comment #16) > 1. Load http://www.mozilla.org/editor/midasdemo/ > 2. Start typing nonsense like sldkjlksj sljdflks > 3. Note that you stop getting things marked after a dozen words, not the 500 it > should be This I can reproduce easily
Chris, in which case did you get the assertion you mention in the 2nd paragraph in Bug 389933 comment 2? It is the fix for that which causes this bug.
I'm not sure what to do with this, especially because I don't know which assertion this code was fixing.
(In reply to comment #19) > Chris, in which case did you get the assertion you mention in the 2nd paragraph > in Bug 389933 comment 2? It is the fix for that which causes this bug. That was almost a year ago, but IIRC I was just banging random text into a gmail compose message box. If I apply attachment 345091 [details] [diff] [review] I get misspelt words in the gmail compose box not being flagged, so there's something more sinister going on. The "assertion" I *probably* meant was the NS_ENSURE_TRUE here: http://mxr.mozilla.org/mozilla-central/source/extensions/spellcheck/src/mozInlineSpellChecker.cpp#779
With the patch gmail+spellchecker does seem to work here (on linux) - with or without richtext-formatting.
(In reply to comment #21) > If I apply attachment 345091 [details] [diff] [review] I get misspelt words in > the gmail compose box not being flagged My apologies, I must have screwed up somehow, because now I see that your patch does fix it. I don't see any other errors raised, so it the patch it probably ok. I'll look at it again tomorrow. We should get some tests for the spell checker too, so that this can't happen again.
This patch backs out the code which breaks the spell checker, and adds a mochitest which creates a designMode iframe and adds 100 misspelt and 100 correctly spelt words, and verifies that the spellchecker has picked up only the misspelt words. The back out removes code that causes the bug. I originally added that code to prevent an error, but no errors now occur without that code. All editor mochitests pass on Linux and Windows with this patch.
Comment on attachment 345324 [details] [diff] [review] Backout + Mochitest >diff --git a/editor/libeditor/html/tests/Makefile.in b/editor/libeditor/html/tests/Makefile.in > test_bug456244.html \ >+ test_bug432225.html \ Use tabs.
Same as above with tabs. r/sr+ peterv
Comment on attachment 345514 [details] [diff] [review] Backout + Mochitest with tabs Test file is missing
Comment on attachment 345637 [details] [diff] [review] 345514: Backout + Mochitest with tabs + testcase [Checkin: Comment 29] http://hg.mozilla.org/mozilla-central/rev/5587400a222e NB: I reordered the tests in the Makefile.
Attachment #345637 - Attachment description: 345514: Backout + Mochitest with tabs + testcase → 345514: Backout + Mochitest with tabs + testcase [Checkin: Comment 29]
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.1b2
This problem seems not to be resolved in all cases (with the firefox-3.1b2pre 10-Nov-2008 05:22 nightly). Here is a really simple test where you can see the problem : http://data.kelis.fr/files/sys/spellCheckTest/editor.html Click on "Make editable" link, and you will see only the first word in error. I think that the problem and the solution is describe here : https://bugzilla.mozilla.org/show_bug.cgi?id=366682 I use this patch since one year in my soft (http://scenari-platform.org) and it works fine. The Xpi version of Scenari suffer of this bug since one year. It would be a great thing for us if it was resolved in Firefox. (sorry for my poor english).
That seems to be a separate issue, what Phil describes in comment 17.
Sylvain, can you file a separate bug to track that? Thanks!
(In reply to comment #32) > Sylvain, can you file a separate bug to track that? Thanks! The other Sylvain ;-) has filed that issue as bug 366682 (I added Phil's testcase there).
This landed before 1.9.1 branched
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P1
Verified fix on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090226 Minefield/3.2a1pre and Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090226 Shiretoko/3.1b3pre Ubiquity/0.1.5
You need to log in before you can comment on or make changes to this bug.