Closed Bug 307533 Opened 19 years ago Closed 19 years ago

[FIX] Caret drawn at incorrect position after typing a single LTR character in a blank RTL input field (or vice versa) while caret is visible

Categories

(Core :: Layout: Text and Fonts, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: uriber, Assigned: MatsPalmgren_bugz)

References

Details

(4 keywords)

Attachments

(4 files)

Steps to reproduce:
1. Place the caret in a blank RTL input field or textarea
2. While the caret is visible (i.e. during the "on" half of the caret blink
cycle), type a single LTR (English) character.
3. The caret will appear to the left of the typed character, instead of to its
right.
4. Deleting this character will now require two presses of "backspace".

The same happens when typing a single RTL (Hebrew) character into a blank LTR
input field or textarea.
This does not happen if the character is typed while the caret is not visible
(i.e. during the "off" half of the blink cycle).

This regressed between 2005-08-10 and 2005-08-11, probably due to the checkin
for bug 296464.
Attached file input boxes
Input boxes (RTL and LTR) for reproducing the bug.
Blocks: 296464
Is this something important enough we want it fixed on branch?
(In reply to comment #2)
> Is this something important enough we want it fixed on branch?

I wasn't sure before, but I just found out that this happens not only in a blank
field, but also every time a first reverse-direction character is typed
following a sequence of paragraph-direction text. So this will actually happen
quite often.

It's still not major, but it is yet another annoyance to bidi editing. I've been
trying to get rid of this kind of bugs, and seeing new ones appear is somewhat
frustrating. So I would very much like to see this fixed on the branch, unless
the fix is especially complicated or risky.
Flags: blocking1.8b5?
I didn't realize that the calculation of the frame position was depending
on the bidi level state which could change between draw and erase time...
Assignee: mozilla → mats.palmgren
OS: MacOS X → All
Hardware: Macintosh → All
Attached patch Patch rev. 1Splinter Review
Save the bidi level that was used to when we draw the caret and use that when
we erase.
Attachment #195325 - Flags: superreview?(bzbarsky)
Attachment #195325 - Flags: review?(uriber)
I have only tested the RTL input. I don't know how to input a Hebrew character
on my keyboard. Uri, can you test that bit please?
Summary: Caret drawn at incorrect position after typing a single LTR character in a blank RTL input field (or vice versa) while caret is visible → [FIX] Caret drawn at incorrect position after typing a single LTR character in a blank RTL input field (or vice versa) while caret is visible
Attachment #195325 - Flags: superreview?(bzbarsky) → superreview+
Comment on attachment 195325 [details] [diff] [review]
Patch rev. 1 (diff -w)

The patch looks good.
I wonder why the caret bidi level is computed inside DrawAtPositionWithHint()
and not passed into it like the other parameters - but that's probably outside
the scope of this bug (I might want to change it for bug 305798).

I tested this with the LTR and RTL cases and it works in both of them.

Thanks for the quick fix, Mats. Given that this is relatively simple, I suggest
that you request approval1.8b5.
Attachment #195325 - Flags: review?(uriber) → review+
Checked in to trunk at 2005-09-10 04:14 PDT
Keywords: testcase
Comment on attachment 195325 [details] [diff] [review]
Patch rev. 1 (diff -w)

low risk fix for a regression
Attachment #195325 - Flags: approval1.8b5?
Could this be a possible cursor glitch caused by this fix?

After entering text (LTR) into either field, and then moving the cursor to the
left or right of the said text, a small ~2 pixel artifact appears near the top
of the I-Bar (See the attatchment). This does not seem to happen on boxes that
are not tagged with specific LTR or RTL properties.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050910
Firefox/1.6a1
(In reply to comment #11)
>  ... a small ~2 pixel artifact appears near the top of the I-Bar ...

That's the bidi marker and it should be there.
Attachment #195325 - Flags: approval1.8b5? → approval1.8b5+
Flags: blocking1.8b5? → blocking1.8b5+
Checked in to MOZILLA_1_8_BRANCH at 2005-09-13 20:41 PDT

-> FIXED
Status: NEW → RESOLVED
Closed: 19 years ago
Keywords: fixed1.8
Resolution: --- → FIXED
Mass-assigning the new rtl keyword to RTL-related (see bug 349193).
Keywords: rtl
Component: Layout: BiDi Hebrew & Arabic → Layout: Text
QA Contact: zach → layout.fonts-and-text
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: