Spell Checker does not always identify misspelled words

VERIFIED FIXED in mozilla1.9.1b2

Status

()

P1
major
VERIFIED FIXED
11 years ago
10 years ago

People

(Reporter: peng.thinkblue, Assigned: cpearce)

Tracking

({regression, verified1.9.1})

Trunk
mozilla1.9.1b2
regression, verified1.9.1
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.1 +
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 3 obsolete attachments)

(Reporter)

Description

11 years ago
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

Comment 1

11 years ago
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).
(Reporter)

Comment 2

11 years ago
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.

Comment 3

11 years ago
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

Comment 4

11 years ago
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/)
(Reporter)

Comment 5

11 years ago
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.

Comment 6

11 years ago
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.

Comment 7

11 years ago
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.
Keywords: regression

Comment 8

11 years ago
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

Comment 9

11 years ago
Regression from bug 389933. If I comment the added if block in nsHTMLEditRules.cpp the issue 2) above is gone.
Blocks: 389933

Updated

11 years ago
OS: Linux → All
Hardware: PC → All

Comment 10

11 years ago
Created attachment 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.

Comment 11

11 years ago
(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

Updated

11 years ago
Duplicate of this bug: 448677
Assignee: mscott → nobody
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
Flags: blocking1.9.1?
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)

Comment 15

10 years ago
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/)
Keywords: testcase-wanted
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.
Created attachment 345091 [details] [diff] [review]
backing out the problematic part of Bug 389933

I'm not sure what to do with this, especially because I don't know which
assertion this code was fixing.
(Assignee)

Comment 21

10 years ago
(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.
(Assignee)

Comment 23

10 years ago
(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.
(Assignee)

Comment 24

10 years ago
Created attachment 345324 [details] [diff] [review]
Backout + Mochitest

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.
Assignee: nobody → chris
Attachment #345091 - Attachment is obsolete: true
Attachment #345324 - Flags: review?(peterv)
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.
Attachment #345324 - Flags: superreview+
Attachment #345324 - Flags: review?(peterv)
Attachment #345324 - Flags: review+
(Assignee)

Comment 26

10 years ago
Created attachment 345514 [details] [diff] [review]
Backout + Mochitest with tabs

Same as above with tabs. r/sr+ peterv
Attachment #345324 - Attachment is obsolete: true
Attachment #345514 - Flags: superreview+
Attachment #345514 - Flags: review+
(Assignee)

Updated

10 years ago
Keywords: checkin-needed
Comment on attachment 345514 [details] [diff] [review]
Backout + Mochitest with tabs

Test file is missing
Keywords: checkin-needed, testcase-wanted
Attachment #345514 - Flags: superreview+
Attachment #345514 - Flags: review+
(Assignee)

Comment 28

10 years ago
Created attachment 345637 [details] [diff] [review]
345514: Backout + Mochitest with tabs + testcase
[Checkin: Comment 29]

With testcase...
Attachment #345514 - Attachment is obsolete: true
Attachment #345637 - Flags: superreview+
Attachment #345637 - Flags: review+
(Assignee)

Updated

10 years ago
Keywords: checkin-needed
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
Last Resolved: 10 years ago
Flags: in-testsuite+
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.1b2

Comment 30

10 years ago
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).

Comment 31

10 years ago
That seems to be a separate issue, what Phil describes in comment 17.
Sylvain, can you file a separate bug to track that?  Thanks!

Comment 33

10 years ago
(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).

Comment 34

10 years ago
This landed before 1.9.1 branched
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P1
(In reply to comment #34)
> This landed before 1.9.1 branched

Adding fixed1.9.1
Keywords: fixed1.9.1
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
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.1 → verified1.9.1

Updated

10 years ago
Depends on: 497511
You need to log in before you can comment on or make changes to this bug.