Closed Bug 422982 Opened 16 years ago Closed 2 years ago

Contractions like Couldn't are shown as misspelled in rich-text editing (until you change line)

Categories

(Core :: Spelling checker, defect)

Product:
Core
Component:
Spelling checker
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: lrombes, Unassigned)

References

Details

Attachments

(1 file)

Screenshot of Firefox failing spell checking with Rich Text Editor
43.83 KB, image/png
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008031405 Minefield/3.0b5pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008031402 Lightning/0.6a1 Thunderbird/3.0a1pre ID:2008031402

When typing in a message a contraction word is listed as spelled incorrectly.  I even have the add-ons United States English Dictionary 3.01 installed.  Which didn't make a difference?  Firefox does not demonstrate this problem, such as entering text in this message?

Reproducible: Always

Steps to Reproduce:
1. Type any contraction word, for example
2. Couldn't
3. Isn't 

They will show up as incorrectly spelled in the document.



Thunderbird 2.0 works fine with contraction words.
Yes, I see this, but once you hit enter and go to the next line, the red underlining goes away.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Summary: Contractions → Contractions like Couldn't, isn't marked as spelling errors (until you change line)
Assignee: nobody → mscott
Component: Message Compose Window → Spelling checker
Product: Thunderbird → Core
QA Contact: message-compose → spelling-checker
Version: unspecified → Trunk
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
Not a dup of bug 344596.  Bug 344596 is only a problem until you finish typing the word.  This is more severe.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Wow!  I can't believe we are shipping Firefox 3 with this bug.

Scott--do you think this is a bug in the dictionary or the spell check engine?
I believe most users aren't seeing this bug.  For it to even be possible for us to fix the problem for you, you guys will have to figure out what's different about your systems, or help us debug the issue on your systems :/
There is a very easy to reproduce test case in bug 432666, but it's not Firefox.

Ahh, this happens with rich-text editing but not with plain-text editing.  I can reproduce the bug in Firefox with

data:text/html,<body contenteditable="true" style="border: 1px inset black">
I think you're right about rich-text editing. I was using rich-text editing in Gmail when I saw the red underlines. When I switched to plain text, they didn't appear when I typed contractions.
Summary: Contractions like Couldn't, isn't marked as spelling errors (until you change line) → Contractions like Couldn't are shown as misspelled in rich-text editing (until you change line)
Okay so I'll clarify all of the details here.

1. Yes, the real issue is with the rich text entry only.
2. It doesn't affect all contractions. Here are the rules:
  - the spelling check occurs when the apostrophe is typed
  - if at that time the word to the left is a valid word in itself then there is no problem (e.g., "I'd"--"I" is a word, "We'd"--"We" is a word, "Don't"--"Don" is a word, etc.)
  - if at that time it isn't a valid word, then you get a squiggly line (e.g., "Isn't"--"Isn" isn't a word, "Shouldn't"--"Shouldn" isn't a word, etc.)
3. Now here's the important part. Both plain text and rich text are initially affected (i.e., you get the squiggly). However, with plain text it immediately un-squigglies when you finish the contracted word. With rich text, it does not.
4. With rich text, the squiggles go away if:
  - you press enter
  - you backspace to the end of the offending word and press space again
5. Regardless, it is ONLY the left hand side of the contraction that is marked as misspelled.

I have to assume that the problem is related to some kind of performance tweak implemented to speed up the rich text editing OR some validation logic that made it into the text inputs but not into the contenteditable body control. Regardless, it should be easy to track down with this detail.
Same problem. I've added a screen shot, though I'm sure it won't help track down the problem. Again, WYSIWIG editor on a forum. vBulletin 3.7.2 to be specific. http://www.vbulletin.com/forum/ is an example forum.

I'm on Mac OSX 10.5.2, no additional dictionaries used except for what Firefox shipped and/or decided to use. Latest and greatest Mac Book Pro 15", 2.6Ghz, 4GB RAM, 200GB 7200rpm Hard Drive.

I can disable all add-ons and have the same issue. Though the add-ons I normally use are: Adblock Plus 0.7.5.5, Firebug 1.1.0b12, Greasemonkey 0.8.20080609.0, LiveHTTP Headers 0.14, Menu Editor 1.2.6, UserAgent Switcher 0.6.11. The only current Greasemonkey script installed/running is the one to change all mailto: links to Google Mail links.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1
Assignee: mscott → nobody
Status: REOPENED → NEW
I've found this same bug by using Italian, English and French dictionaries on Windows Vista Home Premium in the following recent Mozilla applications whose spell checker is based on the Hunspell component:

Firefox 3.0.3
Seamonkey 2.0a1
Thunderbird 3.0a3

In Seamonkey and Thunderbird the bug is present even if I write an email in plain text without using the rich text format.

Thunderbird 2.0.17 that has a spell checker based on MySpell doesn't show this issue.

Here:

https://bugzilla.mozilla.org/show_bug.cgi?id=417379

it's suggested a workaround (to set layout.spellcheckDefault to 1 in about:config) that in my case didn't work.

I've asked other people to test Firefox 3.0.3 and OpenOffice.org 2.4.1 and 3.0 RC that is based on the same Hunspell component. Here are the results:

OOo 2.4.1: OK
OOo 3.0RC: OK
Firefox 3.0.3 on another installation of Windows Vista HP: OK
Firefox 3.0.3 (Iceweasel?) on Debian Linux: OK

I suppose is something related to the parsing of text paragraph made by the spellchecking component because the words included in the dictionaries are correctly *not* underlined when the "Enter" key is pressed.

In addition to this fact, I've found that the elision is not always considered a "word breaker", because in several Italian words like

"col'albero" (compound word that doesn't exist in Italian, while "col" and "albero" are correct words in my language included into the dictionary)

the whole compound word is correctly underlined as wrong.
This drives me nuts in Yahoo Mail since I keep thinking I've spelled something wrong, but of course I haven't.  I've come to ignore "spelling errors" if they contain apostrophes which sometimes results in real errors getting through.

I have a feeling if bug 344596 was fixed, this would go away because the circumstances it occurs under would no longer apply.
I have encountered this decade-old bug just now, though I am having trouble reproducing it. The spellcheck-before-send flagged

download's

in the phrase

the download's signature

as an error. However, creating new, test e-mails containing the phrase, and sending them, does not trip the spell checker. So the fault is intermittent or somehow context-dependent.

I just had it happen when composing an email. It flagged wasn in wasn't as a misspelled word.

I'm on a Macbook. Thunderbird is 60.8.0.

It seems this is not reproducible anymore. Please comment if anyone still has repro steps.

Status: NEW → RESOLVED
Closed: 16 years ago → 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: