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)
Tracking
(Not tracked)
RESOLVED
FIXED
Thunderbird1.1
People
(Reporter: mscott, Assigned: mscott)
Details
(Keywords: fixed1.8.1, verified1.8.1.3)
Attachments
(3 files)
746 bytes,
patch
|
dbaron
:
superreview+
|
Details | Diff | Splinter Review |
29.70 KB,
image/png
|
Details | |
51.45 KB,
image/png
|
Details |
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.
Assignee | ||
Updated•19 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → Thunderbird1.1
Assignee | ||
Comment 1•19 years ago
|
||
The call to disableEditableFields before we send: http://lxr.mozilla.org/mozilla/source/mail/components/compose/content/MsgComposeCommands.js#182 is causing this behavior.
Assignee | ||
Comment 2•19 years ago
|
||
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...
Assignee | ||
Comment 3•19 years ago
|
||
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
Assignee | ||
Comment 5•19 years ago
|
||
Thanks Kurt.
Assignee | ||
Comment 6•19 years ago
|
||
I'm no longer seeing this in a debug build from today. I wonder if something fixed this.
Assignee | ||
Comment 7•19 years ago
|
||
I take it back, its still there.
Assignee | ||
Comment 8•19 years ago
|
||
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.
Assignee | ||
Comment 9•19 years ago
|
||
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)
Comment 10•19 years ago
|
||
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+
Assignee | ||
Updated•19 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Comment 12•19 years ago
|
||
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
Comment 13•19 years ago
|
||
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.
Comment 14•19 years ago
|
||
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??
Comment 15•19 years ago
|
||
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 → ---
Comment 16•19 years ago
|
||
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.
Comment 17•19 years ago
|
||
Still happens with TB version 1.5 (20051113)
Comment 18•19 years ago
|
||
Still happens with TB version 1.5 RC2 (20051201)
Comment 19•18 years ago
|
||
I think this is a different maifestation of bug 336679 which is currently fixed on trunk. Can you reproduce with a new trunk build?
Comment 20•18 years ago
|
||
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
Assignee | ||
Comment 21•18 years ago
|
||
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 ago → 18 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
Comment 22•17 years ago
|
||
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.
Description
•