[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

RESOLVED FIXED

Status

()

Core
Layout: Text
RESOLVED FIXED
12 years ago
9 years ago

People

(Reporter: Uri Bernstein (Google), Assigned: mats)

Tracking

(4 keywords)

Trunk
fixed1.8, regression, rtl, testcase
Points:
---
Bug Flags:
blocking1.8b5 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments)

(Reporter)

Description

12 years ago
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.
(Reporter)

Comment 1

12 years ago
Created attachment 195293 [details]
input boxes

Input boxes (RTL and LTR) for reproducing the bug.
(Reporter)

Updated

12 years ago
Blocks: 296464
Is this something important enough we want it fixed on branch?
(Reporter)

Comment 3

12 years ago
(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?
(Assignee)

Comment 4

12 years ago
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
(Assignee)

Comment 5

12 years ago
Created attachment 195324 [details] [diff] [review]
Patch rev. 1
(Assignee)

Comment 6

12 years ago
Created attachment 195325 [details] [diff] [review]
Patch rev. 1 (diff -w)

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)
(Assignee)

Comment 7

12 years ago
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+
(Reporter)

Comment 8

12 years ago
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+
(Assignee)

Comment 9

12 years ago
Checked in to trunk at 2005-09-10 04:14 PDT
Keywords: testcase
(Assignee)

Comment 10

12 years ago
Comment on attachment 195325 [details] [diff] [review]
Patch rev. 1 (diff -w)

low risk fix for a regression
Attachment #195325 - Flags: approval1.8b5?

Comment 11

12 years ago
Created attachment 195532 [details]
Possible regression example

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
(Assignee)

Comment 12

12 years ago
(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.

Updated

12 years ago
Attachment #195325 - Flags: approval1.8b5? → approval1.8b5+

Updated

12 years ago
Flags: blocking1.8b5? → blocking1.8b5+
(Assignee)

Comment 13

12 years ago
Checked in to MOZILLA_1_8_BRANCH at 2005-09-13 20:41 PDT

-> FIXED
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Keywords: fixed1.8
Resolution: --- → FIXED
Mass-assigning the new rtl keyword to RTL-related (see bug 349193).
Keywords: rtl

Updated

9 years ago
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.