Closed
Bug 336679
Opened 19 years ago
Closed 19 years ago
the text/lines disappears, related to inline spellchecking.
Categories
(Core :: Layout, defect, P1)
Core
Layout
Tracking
()
RESOLVED
FIXED
People
(Reporter: bugmozz, Assigned: brettw)
References
()
Details
(Keywords: fixed1.8.1)
Attachments
(1 file)
1.18 KB,
patch
|
roc
:
superreview+
roc
:
approval-branch-1.8.1+
|
Details | Diff | Splinter Review |
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•19 years ago
|
||
Reliable steps to reproduce please (I haven't seen this yet with casual testing). And does is also occur in safe mode ?
(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•19 years ago
|
||
I also saw this bug but I haven't found steps to reproduce it reliably, yet.
Comment 4•19 years ago
|
||
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(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.
Assignee | ||
Comment 7•19 years ago
|
||
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.
Assignee | ||
Comment 8•19 years ago
|
||
Assignee | ||
Updated•19 years ago
|
Attachment #221023 -
Flags: review? → review?(dbaron)
Assignee | ||
Comment 9•19 years ago
|
||
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
Assignee | ||
Updated•19 years ago
|
Attachment #221023 -
Flags: review?(dbaron) → review?(roc)
Comment on attachment 221023 [details] [diff] [review] Patch Heroic effort Brett :-)
Attachment #221023 -
Flags: superreview+
Attachment #221023 -
Flags: review?(roc)
Attachment #221023 -
Flags: review+
Updated•19 years ago
|
Severity: normal → major
Flags: blocking-firefox2?
Updated•19 years ago
|
Comment 11•19 years ago
|
||
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.
Assignee | ||
Updated•19 years ago
|
OS: Windows XP → All
Priority: -- → P1
Hardware: PC → All
Target Milestone: --- → Firefox 2 alpha3
Assignee | ||
Updated•19 years ago
|
Whiteboard: check in on trunk
Assignee | ||
Comment 12•19 years ago
|
||
Fixed on trunk, leaving open for branch checkin later assuming nothing breaks.
Whiteboard: check in on trunk → baking on trunk
Updated•19 years ago
|
Component: General → Layout: Misc Code
Flags: review+
Flags: blocking-firefox2?
Product: Firefox → Core
QA Contact: general → layout
Target Milestone: Firefox 2 alpha3 → ---
Version: unspecified → Trunk
Updated•19 years ago
|
Flags: blocking1.8.1?
Reporter | ||
Comment 13•19 years ago
|
||
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•19 years ago
|
||
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•19 years ago
|
||
(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.
Assignee | ||
Comment 17•19 years ago
|
||
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.
Attachment #221023 -
Flags: approval-branch-1.8.1?(roc)
Attachment #221023 -
Flags: approval-branch-1.8.1?(roc) → approval-branch-1.8.1+
Assignee | ||
Comment 18•19 years ago
|
||
Fixed on branch.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
Whiteboard: baking on trunk
Comment 20•19 years ago
|
||
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.
Assignee | ||
Comment 21•19 years ago
|
||
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.
Assignee | ||
Updated•18 years ago
|
Flags: blocking1.8.1?
Updated•6 years ago
|
Product: Core → Core Graveyard
Updated•6 years ago
|
Component: Layout: Misc Code → Layout
Product: Core Graveyard → Core
You need to log in
before you can comment on or make changes to this bug.
Description
•