646382 - Caret moves down a line after entering a LTR character in a RTL textarea (and the opposite)

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect)

Description

[dror3go]

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: 

When typing a RTL character in a LTR textarea - the caret moves down a line, even though a second line doesn't exists. The same happens when typing a LTR character in a RTL textarea.

Reproducible: Always

Comment 1

[Simon Montagu :smontagu]

Regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f7016571b472&tochange=5947e95a21d1

Comment 2

[dror3go]

Also, deleting the character requires 2 clicks on the backspace button - the first click does nothing.

Comment 3

[Tomer Cohen :tomer]

Attachment: Screencast

I was able to reproduce only after explicitly setting bidi.browser.ui to true.

Comment 4

[Simon Montagu :smontagu]

It looks as this bug is only reproducible when bidi.browser.ui is set to true

Comment 2 is not part of this bug, and the behaviour can be changed by setting bidi.edit.delete_immediately to true (see bug 328834

Comment 5

[Anas Husseini [:linostar]]

Ehsan should be able to throw some light on this, since he was dealing and submitting patches to many caret issues. Bugs relevant in the range specified are: bug 607584, bug 542317, bug 542116 and bug 389321.

Comment 6

[(no longer active)]

So, here is what's happening here.  Our bidi handling code attaches the caret to the BR frame at the end of the textarea.  But the BR frame is positioned 720 points below where it's supposed to be (see this frame dump for example: http://pastebin.mozilla.org/1195321)

roc: do you think that's the expected place for the BR frame to show up after a reframe?

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

It's zero height and width, so I guess we're just placing it at the baseline, so that seems OK right?

Comment 8

[(no longer active)]

(In reply to comment #7)
> It's zero height and width, so I guess we're just placing it at the baseline,
> so that seems OK right?

Right, ok, just wanted to confirm.  I guess we need to special case the BR frame the same way as inline frames then.

Comment 9

[(no longer active)]

Attachment: Patch (v1)

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

It seems to me that GetCaretBaseline and GetBaseline should normally be constrained to be within the frame's content-box. So I think a better fix might be to make nsBRFrame::GetBaseline clamp the computed baseline to the content-box.

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

The same might be true for inline frames.

Comment 12

[(no longer active)]

Attachment: Patch (v2)

Comment 13

[Benjamin Stover (:stechz)]

Pushed http://hg.mozilla.org/mozilla-central/rev/a7056f19b2aa