Closed Bug 282506 Opened 19 years ago Closed 18 years ago

Inline spell check words go blank while message is being sent

Categories

(Thunderbird :: Message Compose Window, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird1.1

People

(Reporter: mscott, Assigned: mscott)

Details

(Keywords: fixed1.8.1, verified1.8.1.3)

Attachments

(3 files)

1) Enter some misspelled words in the compose window with inline spell check
enabled.

2) send the message

3) while the message is being sent, the words with the red underlines have their
font color changed to white and you can't see them.

4) once the message has been sent, the words are visible again.
Status: NEW → ASSIGNED
Target Milestone: --- → Thunderbird1.1
The call to disableEditableFields before we send:

http://lxr.mozilla.org/mozilla/source/mail/components/compose/content/MsgComposeCommands.js#182

is causing this behavior.
which is really weird because the only thing that method does is disable the
subject box, and the autocomplete widget text boxes. It doesn't do anything with
the editor window at all! But commenting out that call makes the problem go away...
ah it has nothing to do inline spell check selection at all.

Any selection in the editor shell when it gets disabled is having its font color
turned white. 

Just selected some text and click send....

I don't see any changes in the last week to mozilla\editor and nothing in
mozilla\layout or mozilla\content that looks suspicious.
this bug is present since before the 2/02 build, I tested every build from 2/16
all the way back to 2/02 build and its present in every build...so look into
from before there
Thanks Kurt.
I'm no longer seeing this in a debug build from today. I wonder if something
fixed this. 
I take it back, its still there. 
Attached patch the fixSplinter Review
When editor disables text, layout hides the current standard selection.
However, if we are talking about spell check selection, we want to make sure we
still show the spell check selection (it is treated differently from standard
selection).

displaySelection is going to be set to true by GetTextInfoForPainting if the
selection is a spell check selection and we should continue to paint it even if
we are hiding standard selection.

I'm a little nervous about what kind of side effects this could have as I'm not
very familiar with this code. In particular, there are other situations where
displaySelection could get set to true in GetTextInfoForPainting.
Comment on attachment 175991 [details] [diff] [review]
the fix

David, are you familiar with this nsTextFrame code at all? My fix looks simple,
but I'm worried about unanticipated side effects. Read my comment above for
more details.
Attachment #175991 - Flags: superreview?(dbaron)
FWIW, this effect seems to happen at times other than when a message is sent.  I
have seen a partial "white out" of the content of a forwarded message when the
compose window is first displayed.  There seems to be some "general wierdness"
with text being "hidden" when inline spell check is enabled.  In all cases,
selecting the text with the mouse causes it to reappear normally.

version 1.0+ (20050308) winxp sp 2
Comment on attachment 175991 [details] [diff] [review]
the fix

I don't understand any of this code (and it doesn't look easy to understand),
but sr=dbaron.
Attachment #175991 - Flags: superreview?(dbaron) → superreview+
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
This behavior still happens intermittently when sending messages composed in
HTML format.  Unfortunately I can't figure out a reliable way to reproduce it. 
I see the entire line that contains a spelling error go blank, not just the
word(s).  The behavior is much improved since this bug was "fixed" but it still
happens sometimes.  It doesn't seem to happen any longer for messages composed
in plain text.

version 1.0+ (20050321) Win XP SP2
The attached image shows lines that are blank in the compose window when
forwarding an email.  The blank lines have spelling errors, indicated by the
red dotted lines under the misspelled words that aren't shown.	If any of the
text on the hidden lines is highlighted with the cursor, the full line appears.
 I have no consistent way to reproduce this issue.
This bug is clearly not fixed.	This screenshot was taken while sending with
"version 1.0+ (20050328)".  As you can see, the first line of the message is
hidden.  The red underline of a misspelled word is still visible though.  

Can somebody reopen this bug??
I'm seeing this with seamonkey 2005052706 - any line with a dotted word in it is
blank while submitting.
Despite this bug being assigned to thunderbird, the patch suggests that the code
is Core, and together with the previous comment, that's enough for me to go out
on a limb here and reopen.

Please don't smite me too hard if I'm wrong about that. :)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I'm seeing this with TB version 1.5 (20051025).

It happens almost all the time when the message is being sent.

It also happens sometimes when I hit Ctrl-M to write a new message: my signature contains some text (names) which is found to be mispelled, and the underlined words do not appear. I need to change the size of the window to make it appear.
Still happens with TB version 1.5 (20051113)
Still happens with TB version 1.5 RC2 (20051201)
I think this is a different maifestation of bug 336679 which is currently fixed on trunk. Can you reproduce with a new trunk build?
I rechecked this issue:

With Thunderbird 1.5.0.2 reproducible error
With Thunderbird 1.5.0.4 (from FTP) reproducible error
With Thunderbird 3.0 (Latest Trunk) NO reproducible error (At least not in my short Test)

But I'm confused on Version Numbering. Does that mean, that this bug will not be fixed in TB 1.5 Series, or at least 2.0?  Waiting for 3.0 would mean, that users have to wait a very long time for this fix...

Sincerely, Claus Berghammer
http://www.cb-computerservice.at
Claus, it means this is going to be fixed for Thunderbird 2 and Thunderbird 3. Thanks to brett for fixing this issue.

I'm going to close this bug out based on Claus' testing and some testing I did this morning.
Status: REOPENED → RESOLVED
Closed: 19 years ago18 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
verified fixed 1.8.1.3 using Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.0 ID:2007032620 and the steps to reproduce from comment #0
Keywords: verified1.8.1.3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: