The default bug view has changed. See this FAQ.

regression: In RTL text, can't move caret using arrow keys past point where text wraps

RESOLVED FIXED in mozilla1.8beta5

Status

()

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

People

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

Tracking

({fixed1.8, regression, rtl})

1.8 Branch
mozilla1.8beta5
fixed1.8, regression, rtl
Points:
---
Bug Flags:
blocking1.8b5 +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Assignee)

Description

12 years ago
In an RTL textarea where a line wraps to the next line (e.g. the upper textarea
in https://bugzilla.mozilla.org/attachment.cgi?id=128682), the caret is stuck
when you try to use left-arrow to move beyond the wrapping point (i.e. from the
first line to the second one). The same happens when you try to use right-arrow
to go back from the second line to the first one.

This regressed due to the patch for bug 305083, and is now both on the trunk and
on the 1.8 branch.

Needless to say, this is very major, and must be fixed for beta 2.
(Assignee)

Updated

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

Updated

12 years ago
Summary: regression: In RTL text, can't move using arrow keys past point where text wraps → regression: In RTL text, can't move caret using arrow keys past point where text wraps
Flags: blocking1.8b5? → blocking1.8b5+
(Assignee)

Comment 1

12 years ago
Created attachment 195610 [details] [diff] [review]
patch

Only "unflip" the hint when we know the inner call might want to flip it
itself.

I actually explained why this is necessary back in bug 207186 comment #28
(describing this regression if it's not done), but then forgot about it when
reviewing the patch  for bug 305083.
Assignee: eyalroz → uriber
Status: NEW → ASSIGNED
Attachment #195610 - Flags: superreview?(roc)
Attachment #195610 - Flags: review?(eyalroz)

Comment 2

12 years ago
Comment on attachment 195610 [details] [diff] [review]
patch

I'll take your word for it, I can't really do any serious reviewing. 

It would of course be more easy to understand if every mAmount could accept the
original unmodified mPreferLeft and change it according to whatever logic it
employs, but the whole thing can't be made simple and understandable anyway, so
let it be as the patch suggests.

Sorry for not having caught this either.
Attachment #195610 - Flags: review?(eyalroz) → review+
Comment on attachment 195610 [details] [diff] [review]
patch

rubber-stamp.

This code has to be rewritten on trunk.
Attachment #195610 - Flags: superreview?(roc) → superreview+
(Assignee)

Updated

12 years ago
Attachment #195610 - Flags: approval1.8b5?
Checking in nsTextFrame.cpp;
/cvsroot/mozilla/layout/generic/nsTextFrame.cpp,v  <--  nsTextFrame.cpp
new revision: 1.525; previous revision: 1.524
done
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED

Updated

12 years ago
Attachment #195610 - Flags: approval1.8b5? → approval1.8b5+
(Assignee)

Updated

12 years ago
Target Milestone: --- → mozilla1.8beta5
1.8 Branch:
Checking in nsTextFrame.cpp;
/cvsroot/mozilla/layout/generic/nsTextFrame.cpp,v  <--  nsTextFrame.cpp
new revision: 1.513.4.5; previous revision: 1.513.4.4
done
Keywords: fixed1.8
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.