Closed
Bug 432225
Opened 16 years ago
Closed 16 years ago
Spell Checker does not always identify misspelled words
Categories
(Core :: Spelling checker, defect, P1)
Core
Spelling checker
Tracking
()
VERIFIED
FIXED
mozilla1.9.1b2
People
(Reporter: peng.thinkblue, Assigned: cpearce)
References
Details
(Keywords: regression, verified1.9.1)
Attachments
(2 files, 3 obsolete files)
21.75 KB,
image/png
|
Details | |
4.63 KB,
patch
|
cpearce
:
review+
cpearce
:
superreview+
|
Details | Diff | Splinter Review |
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.
Updated•16 years ago
|
Assignee: nobody → mscott
Component: General → Spelling checker
Product: Firefox → Core
QA Contact: general → spelling-checker
Version: unspecified → Trunk
Comment 1•16 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•16 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.
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•16 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•16 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.
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•16 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•16 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•16 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•16 years ago
|
OS: Linux → All
Hardware: PC → All
Comment 10•16 years ago
|
||
The first two instances of "Lapham" are highlighted/underlined as misspelled. The third use of "Lapham" is not, however.
Comment 11•16 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•16 years ago
|
Assignee: mscott → nobody
Comment 13•16 years ago
|
||
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?
Comment 14•16 years ago
|
||
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•16 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
Comment 16•16 years ago
|
||
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).
Comment 17•16 years ago
|
||
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".
Comment 18•16 years ago
|
||
(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
Comment 19•16 years ago
|
||
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.
Comment 20•16 years ago
|
||
I'm not sure what to do with this, especially because I don't know which assertion this code was fixing.
Assignee | ||
Comment 21•16 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
Comment 22•16 years ago
|
||
With the patch gmail+spellchecker does seem to work here (on linux) - with or without richtext-formatting.
Assignee | ||
Comment 23•16 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•16 years ago
|
||
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 25•16 years ago
|
||
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•16 years ago
|
||
Same as above with tabs. r/sr+ peterv
Attachment #345324 -
Attachment is obsolete: true
Attachment #345514 -
Flags: superreview+
Attachment #345514 -
Flags: review+
Assignee | ||
Updated•16 years ago
|
Keywords: checkin-needed
Comment 27•16 years ago
|
||
Comment on attachment 345514 [details] [diff] [review] Backout + Mochitest with tabs Test file is missing
Updated•16 years ago
|
Keywords: checkin-needed,
testcase-wanted
Updated•16 years ago
|
Attachment #345514 -
Flags: superreview+
Attachment #345514 -
Flags: review+
Assignee | ||
Comment 28•16 years ago
|
||
With testcase...
Attachment #345514 -
Attachment is obsolete: true
Attachment #345637 -
Flags: superreview+
Attachment #345637 -
Flags: review+
Assignee | ||
Updated•16 years ago
|
Keywords: checkin-needed
Comment 29•16 years ago
|
||
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]
Updated•16 years ago
|
Status: NEW → RESOLVED
Closed: 16 years ago
Flags: in-testsuite+
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.1b2
Comment 30•16 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•16 years ago
|
||
That seems to be a separate issue, what Phil describes in comment 17.
Comment 32•16 years ago
|
||
Sylvain, can you file a separate bug to track that? Thanks!
Comment 33•16 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•15 years ago
|
||
This landed before 1.9.1 branched
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P1
Comment 35•15 years ago
|
||
(In reply to comment #34) > This landed before 1.9.1 branched Adding fixed1.9.1
Keywords: fixed1.9.1
Comment 36•15 years ago
|
||
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
You need to log in
before you can comment on or make changes to this bug.
Description
•