Closed Bug 295142 Opened 20 years ago Closed 20 years ago

Crash when using option(ctrl)-left arrow at the end of RTL textarea [@nsFrame::PeekOffset]

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: uriber, Assigned: ginnchen+exoracle)

References

()

Details

(Keywords: crash, regression, rtl)

Crash Data

Attachments

(3 files)

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050522 Firefox/1.0+ Steps to reproduce: 1. Go to http://oren.gomen.org/mozilla/bug_207186.html 2. Place the caret in the first textbox, on the last line containing text, to the left of the leftmost period (i.e. at the end of the RTL row). 3. Press option-right arrow (ctrl-right arrow on PC) 4. Crash I'll attach a mac crash dump soon. TB Incident ID is TB6042636Y. I'm seeing this on OS X, but it's likely All/All (con someone confirm?)
Attached file crash log
Infinite recursion in nsFrame::PeekOffset / nsTextFrame::PeekOffset. Notice the similarity to bug 256835.
Keywords: crash
Summary: Crash when using option(ctrl)-left arrow in certain bidi case → Crash when using option(ctrl)-left arrow in certain bidi case [@nsFrame::PeekOffset]
Adding regression keyword since this does not happen in Gecko 1.7 (FF 1.0).
Keywords: regression
Attached file minimal testcase
Place the caret in the (empty) textarea and hit option-left arrow => Crash.
Flags: blocking1.8b3?
Summary: Crash when using option(ctrl)-left arrow in certain bidi case [@nsFrame::PeekOffset] → Crash when using option(ctrl)-left arrow at the end of RTL textarea [@nsFrame::PeekOffset]
*** Bug 292301 has been marked as a duplicate of this bug. ***
OS: MacOS X → All
Comment 0 set 3 should read "Press option-LEFT arrow (ctrl-LEFT arrow on PC)". I really should be more careful. Matti, did you reproduce this on a PC? If so, please provide a User-Agent string and set the "Hardware" field to "All" as well. Thanks.
no, i didn't reproduce this
Hardware: Macintosh → All
I reproduced it on both Linux and Mac OS X. But I can't reproduce it on Windows.
It's something like Bug 274857. Actually, if we move the #ifdef block out of 'if (aPos->mDirection == eDirNext)', it won't crash. if (aPos->mDirection == eDirNext) { aPos->mPreferLeft = (PRBool)!(aPos->mPreferLeft);//drift to other side -#ifdef IBMBIDI - if (lineIsRTL) - aPos->mAmount = eSelectNoAmount; -#endif } +#ifdef IBMBIDI + if (lineIsRTL) + aPos->mAmount = eSelectNoAmount; +#endif But the Option+Left behaviour is still wrong, caret goes to the end of the next line. I suggest we fix some issues in bug 207186 first, otherwise we're causing more regressions.
Assignee: aaronleventhal → ginn.chen
(In reply to comment #8) > But the Option+Left behaviour is still wrong, caret goes to the end of the next line. Oops, it should be correct to go to next line if it is RTL. I'm not quite sure about it.
The dupe is from win32
> (In reply to comment #8) > > But the Option+Left behaviour is still wrong, caret goes to the end of the > next line. > > Oops, it should be correct to go to next line if it is RTL. > I'm not quite sure about it. It goes to the RIGHT of the next line (which is the beginning of the line, if you're writing in an RTL script - the more common case for an RTL textbox). This is not exactly the correct behaviour - the caret should go to the end (LEFT) of the first (RIGHTMOST) word in the next line - i.e. the mirror image of what happens when you do an option-right at the end of a line in an LTR textbox. It's still much better than crashing, though. So unless you're sure that some serious work will be done on bug 207186 before the next release, IMHO the solution/workaround in comment #8 should be checked in.
this patch is much like bug 274857. I don't think we can fix all the BiDi bugs before next release. So just avoid crash first. The patch is safe.
Attachment #184562 - Flags: review?(roc)
Attachment #184562 - Flags: approval-aviary1.1a2?
Comment on attachment 184562 [details] [diff] [review] patch to avoid crash a=chofmann
Attachment #184562 - Flags: approval-aviary1.1a2? → approval-aviary1.1a2+
Checking in nsFrame.cpp; /cvsroot/mozilla/layout/generic/nsFrame.cpp,v <-- nsFrame.cpp new revision: 3.564; previous revision: 3.563 done
Status: NEW → RESOLVED
Closed: 20 years ago
Flags: blocking1.8b3?
Resolution: --- → FIXED
Mass-assigning the new rtl keyword to RTL-related (see bug 349193).
Keywords: rtl
Crash Signature: [@nsFrame::PeekOffset]
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: