Closed
Bug 76003
Opened 24 years ago
Closed 24 years ago
bidi: rendering context's state corrupted
Categories
(Core :: DOM: Editor, defect)
Core
DOM: Editor
Tracking
()
VERIFIED
FIXED
mozilla0.9.1
People
(Reporter: erik, Assigned: ftang)
Details
(Whiteboard: patch sr . wait green tree to check in)
Attachments
(1 file)
1.35 KB,
patch
|
Details | Diff | Splinter Review |
Subject: nsCaret::DrawCaret (IBMBIDI #ifdef)
Date: Thu, 12 Apr 2001 19:41:47 -0400 (EDT)
From: "L. David Baron" <dbaron@fas.harvard.edu>
To: erik@netscape.com
CC: dbaron@fas.harvard.edu
I was just looking at nsCaret::DrawCaret and happened to notice what
seems to be a bug in the |#ifdef IBMBIDI| part of the function.
Within the ifdef-ed part, there is a |return| statement. This is bad
because it's between |mRendContext->PushState()| and
|mRendContext->PopState()| -- it would mess up the state stack for
all the callers.
I'm also wondering if:
* the condition for the |return| should be |NS_FAILED| rather than
|NS_SUCCEEDED|
* the error condition should be propagated by making |DrawCaret|
return |nsresult| rather than |void|.
-David
L. David Baron <URL: http://www.people.fas.harvard.edu/~dbaron/ >
Mozilla Contributor <URL: http://www.mozilla.org/ >
Invited Expert, W3C CSS WG <URL: http://www.w3.org/Style/CSS/ >
Comment 1•24 years ago
|
||
Comment 2•24 years ago
|
||
NS_SUCCEEDED is the correct condition for the early return. If the language is
changed while the caret is between two characters with different directionality,
the caret will have to move to reflect where the next character typed is going
to appear. For example if I have
english|WERBEH
with a right-to-left caret, the logical position of the caret is after the W. If
the next character typed is Hebrew, it should appear to the left of the W, since
that is "after" it in Hebrew terms, but if it is English, it should appear to
the right of the whole Hebrew section. So when the language changes to English
the caret needs to jump to the right of the H.
Without the early return the caret will blink off and on once in the old
position and then reappear in the new position, which makes the program seem
unresponsive.
In the patch I've added a call to |mRendContext->PopState| before returning,
plus a comment which (I hope) clarifies what's going on.
Assignee | ||
Updated•24 years ago
|
Whiteboard: need review from dbaron@fas.harvard.edu
Assignee | ||
Comment 4•24 years ago
|
||
need code review
Assignee | ||
Comment 5•24 years ago
|
||
ask review from dbaron@fas.harvard.edu 2001-05-08 02:51
Whiteboard: need review from dbaron@fas.harvard.edu → need review from dbaron@fas.harvard.edu 2001-05-08 02:51
r=dbaron ... although I wonder if this logic really belongs somewhere else
(perhaps outside of the drawing functions entirely, or perhaps just earlier in
|DrawCaret|.)
Whiteboard: need review from dbaron@fas.harvard.edu 2001-05-08 02:51
Comment 7•24 years ago
|
||
dbaron: I had the same thought as you, and tried moving this earlier, but it
didn't work. If we leave |DrawCaret| before mCaretRect gets updated, it leaves a
ghost caret in the old position.
Assignee | ||
Comment 9•24 years ago
|
||
kin -can you sr this one ?
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.1
Comment 10•24 years ago
|
||
Assignee | ||
Updated•24 years ago
|
Whiteboard: patch wait for sr → patch sr . wait green tree to check in
Assignee | ||
Comment 11•24 years ago
|
||
fixed and check in
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 12•24 years ago
|
||
Frank can you verify this and mark verified-fixed? thanks...
You need to log in
before you can comment on or make changes to this bug.
Description
•