Last Comment Bug 336679 - the text/lines disappears, related to inline spellchecking.
: the text/lines disappears, related to inline spellchecking.
Status: RESOLVED FIXED
: fixed1.8.1
Product: Core
Classification: Components
Component: Layout: Misc Code (show other bugs)
: Trunk
: All All
: P1 major with 3 votes (vote)
: ---
Assigned To: Brett Wilson
:
Mentors:
http://wiki.mozilla.org/index.php?tit...
: 291393 336712 360822 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-05-04 18:40 PDT by pal-moz
Modified: 2006-11-18 09:57 PST (History)
12 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Patch (1.18 KB, patch)
2006-05-05 18:20 PDT, Brett Wilson
roc: superreview+
roc: approval‑branch‑1.8.1+
Details | Diff | Review

Description pal-moz 2006-05-04 18:40:39 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060504 BonEcho/2.0a1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060504 BonEcho/2.0a1 ID:2006050415

since Bug#335306 check-in was landed,
if focus is not on text area, the line disappear.
this happens on any lines/sites at random.

screen shot : http://img79.imageshack.us/img79/3540/spellcheck4rc.jpg

Reproducible: Sometimes
Comment 1 Nick Thomas [:nthomas] 2006-05-05 00:55:49 PDT
Reliable steps to reproduce please (I haven't seen this yet with casual testing). And does is also occur in safe mode ?
Comment 2 pal-moz 2006-05-05 01:34:32 PDT
(In reply to comment #1)
> Reliable steps to reproduce please (I haven't seen this yet with casual
> testing). And does is also occur in safe mode ?
> 

click on page, not in text area.
screen shot (example) : http://img72.imageshack.us/img72/4690/text2yi.jpg

this happens, but not always/not every time.
Comment 3 Adam Kowalczyk 2006-05-05 04:35:10 PDT
I also saw this bug but I haven't found steps to reproduce it reliably, yet.
Comment 4 Adam Kowalczyk 2006-05-05 06:57:29 PDT
This happens when the text contains non-English characters.

Steps to reproduce:
1. Paste these characters in a text area: ä ö å ą ł ń ź.
2. After they are underlined as misspelled, click outside the area.

Results: the line containing these characters disappears.
Comment 5 Adam Kowalczyk 2006-05-05 07:08:39 PDT
*** Bug 336712 has been marked as a duplicate of this bug. ***
Comment 6 pal-moz 2006-05-05 07:35:23 PDT
(In reply to comment #4)
> This happens when the text contains non-English characters.
> 
> Steps to reproduce:
> 1. Paste these characters in a text area: ä ö å ą ł ń ź.
> 2. After they are underlined as misspelled, click outside the area.
> 
> Results: the line containing these characters disappears.
> 

[Addition]
containing Japanese language, too.

example : commentt 小泉

maybe the line including non-English words or phrases disappears.
Comment 7 Brett Wilson 2006-05-05 11:11:18 PDT
It seems that spans in textareas containing non-ASCII characters AND words marked as misspelled don't paint properly. It doesn't have to be any specific language, even the copyright symbol causes this problem. Typically, the span will correspond to a line, but may have a smaller range in some cases.
Comment 8 Brett Wilson 2006-05-05 18:20:41 PDT
Created attachment 221023 [details] [diff] [review]
Patch
Comment 9 Brett Wilson 2006-05-05 18:24:28 PDT
The ASCII case is working, I duplicated the condition on this line:
  http://lxr.mozilla.org/mozilla1.8/source/layout/generic/nsTextFrame.cpp#3627

In the unicode version, the conditions that cause the text not be drawn are:
  displaySelection && isSelected && hideStandardSelection

Here is where we start testing thest flags:
  http://lxr.mozilla.org/mozilla1.8/source/layout/generic/nsTextFrame.cpp#2602

Watch out, the indentation is off in one of the nested ifs
Comment 10 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2006-05-08 02:45:18 PDT
Comment on attachment 221023 [details] [diff] [review]
Patch

Heroic effort Brett :-)
Comment 11 Christophe Jacquet 2006-05-15 04:21:21 PDT
Confirming the problem with Bon Echo 2.0a2. This is very annoying when editing European text with diacritics, as lines disappear very often.

Isn't this bug related to bug #282506 targeting Thunderbird? The screenshots of this one seem to show the same behavior.
Comment 12 Brett Wilson 2006-05-15 12:20:31 PDT
Fixed on trunk, leaving open for branch checkin later assuming nothing breaks.
Comment 13 pal-moz 2006-05-15 18:42:51 PDT
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060515 Minefield/3.0a1 ID:2006051517 [cairo]

confirmed.
WFM
Comment 14 ourasi 2006-05-17 06:26:37 PDT
There is a bug: 

If first character in line is misspelled (and thus underlined) you cannot move caret backwards to preceding line. It is very easy to test, just change something in the beginning so that it comes misspelled and try to go backwards. Caret stops at the end of preceding line.
Comment 15 ourasi 2006-05-17 07:36:56 PDT
(In reply to comment #14)
Sorry I forgot my build id:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060517 Minefield/3.0a1 - Build ID: 2006051703

This kind of nonsense text shows clearly the bug:

asd fasd fasdf asdf sd fasd asdf sadf asd asda sfasaf asd fasd fasdf asdf sd fasd asdf asdf asdds sadf asd asda sfasaf asd fasd fasdf asdf sd sad fasd asdf sadf asd asda sfasaf.
Comment 16 Brett Wilson 2006-05-17 08:45:44 PDT
oruasi: please file a new bug & CC me, thanks.
Comment 17 Brett Wilson 2006-05-17 12:46:48 PDT
Comment on attachment 221023 [details] [diff] [review]
Patch

I haven't heard of any problems with the patch, and it seems to have also resolved longstanding Thunderbird an Seamonkey bugs.
Comment 18 Brett Wilson 2006-05-22 12:07:28 PDT
Fixed on branch.
Comment 19 Brett Wilson 2006-05-24 10:08:58 PDT
*** Bug 291393 has been marked as a duplicate of this bug. ***
Comment 20 Christophe Jacquet 2006-06-20 14:19:34 PDT
I am still observing this bug.

User agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a2) Gecko/20060519 BonEcho/2.0a2

Very simple testcase: in Bugzilla, type "é" in the "additional comments" text area, and then a carriage return. "é" gets underlined because it is not a valid word. Then, click outside of the text area. The "é" disappears.

I think that this bug should be reopened, because it does not appear to be fixed on branch.
Comment 21 Brett Wilson 2006-06-20 14:32:41 PDT
You(In reply to comment #20)
> I am still observing this bug.
> 
> User agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a2)
> Gecko/20060519 BonEcho/2.0a2

It was fixed in a3.
Comment 22 Mike Cowperthwaite 2006-11-18 09:57:07 PST
*** Bug 360822 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.