336679 - the text/lines disappears, related to inline spellchecking.

Status: RESOLVED FIXED

(Core :: Layout, defect, P1)

Description

[pal-moz]

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] (UTC+12)]

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]

(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]

I also saw this bug but I haven't found steps to reproduce it reliably, yet.

Comment 4

[Adam Kowalczyk]

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]

*** Bug 336712 has been marked as a duplicate of this bug. ***

Comment 6

[pal-moz]

(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]

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]

Attachment: Patch

Comment 9

[Brett Wilson]

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) (email my personal email if necessary)]

Comment on attachment 221023 [details] [diff] [review]
Patch

Heroic effort Brett :-)

Comment 11

[Christophe Jacquet]

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]

Fixed on trunk, leaving open for branch checkin later assuming nothing breaks.

Comment 13

[pal-moz]

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]

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]

(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]

oruasi: please file a new bug & CC me, thanks.

Comment 17

[Brett Wilson]

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]

Fixed on branch.

Comment 19

[Brett Wilson]

*** Bug 291393 has been marked as a duplicate of this bug. ***

Comment 20

[Christophe Jacquet]

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]

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]

*** Bug 360822 has been marked as a duplicate of this bug. ***