Closed Bug 646382 Opened 9 years ago Closed 9 years ago

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

Categories

(Core :: DOM: Editor, defect)

defect
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: ogirtd, Assigned: ehsan)

References

(Depends on 1 open bug, )

Details

(Keywords: regression, rtl)

Attachments

(2 files, 1 obsolete file)

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
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression, rtl
Component: Layout: View Rendering → Editor
QA Contact: layout.view-rendering → editor
Also, deleting the character requires 2 clicks on the backspace button - the first click does nothing.
Attached video Screencast
I was able to reproduce only after explicitly setting bidi.browser.ui to true.
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
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.
Assignee: nobody → ehsan
Blocks: 389321
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?
It's zero height and width, so I guess we're just placing it at the baseline, so that seems OK right?
(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.
Attached patch Patch (v1) (obsolete) — Splinter Review
Attachment #523816 - Flags: review?(roc)
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.
The same might be true for inline frames.
Attached patch Patch (v2)Splinter Review
Attachment #523816 - Attachment is obsolete: true
Attachment #523816 - Flags: review?(roc)
Attachment #524798 - Flags: review?(roc)
Pushed http://hg.mozilla.org/mozilla-central/rev/a7056f19b2aa
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Flags: in-testsuite+
Depends on: 657461
You need to log in before you can comment on or make changes to this bug.