Closed Bug 228156 Opened 21 years ago Closed 21 years ago

RTL textareas containing text originated in HTML code are misaligned [Regression]

Categories

(Core :: Layout: Text and Fonts, defect, P1)

Product:
Core
Component:
Layout: Text and Fonts
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.6final

People

(Reporter: bugzillamozilla, Assigned: dbaron)

References

(
URL
)

Details

(Keywords: fixed1.6, regression, rtl, Whiteboard: [patch])

Attachments

(3 files, 1 obsolete file)

Screenshot of the buggy textarea
14.55 KB, image/png
Details
Testcase
1.04 KB, text/html
Details
patch
6.37 KB, patch
roc
: review+
bzbarsky
: superreview+
chofmann
: approval1.6+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031208
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031208

This is a serious regression that prevents previewing RTL messages in forums and
webmail.

Reproducible: Always

Steps to Reproduce:
Open http://bugzilla.mozilla.org/attachment.cgi?id=134102&action=view or any
other page with an RTL textarea that already includes text.

Actual Results:  
The contained text does not align to the rightmost side of the textarea, but
rather starts at the middle (as if it was indented).


Expected Results:  
Text should be right-aligned.

Prog.
Shosh, can you reproduce (and confirm) this on other platforms?

Prog.
This bug also happens with Mozilla and Firebird under Linux.
More details here: http://mozillazine.org/talkback.html?article=4068#41

Prog.
OS: Windows XP → All
i didn't check this myself yet, but if true, this is a major problem for RTL
locales.
Flags: blocking1.6?
what i see is that the page is loaded with only two "words" visible, aligned to
the left, and then, when i move the caret, they align to the right normaly.

i'm using a nightly from last week: Mozilla/5.0 (Windows; U; Windows NT 5.1;
en-US; rv:1.6b) Gecko/20031208
Status: UNCONFIRMED → NEW
Ever confirmed: true
Yes, I am seeing this with Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O;
en-US; rv:1.6b) Gecko/20031129 Firebird/0.7+
Hardware: PC → All
Seeing this with build 2003-12-03-08 on WinXP. Could with what may be another
bug but may also be the same problem - the bungled-up editing of such text
(lines not selected properly, illogical cursor movement) - this makes not only
the previewing but the entire experience of using Hebrew webmail, webforums etc.
rather unpleasent.
illogical corsor (caret) movement is at bug 207186.
This was caused by:

http://bugzilla.mozilla.org/show_bug.cgi?id=217201

Since we know what caused this I'm going to mark this blocking hoping we can get
someone to look at it.
Flags: blocking1.6? → blocking1.6+
CCing Robert O'Callahan, as he is more familiar with the patch that introduced
this regression (in Bug 217201).

Prog.
This seems to be a view synchronization problem:

frames:
                        ScrollPortFrame(div)(-1)@0x91a7354 [view=0x91a7518]
next=0x91ae068 {0,0,4392,1872} [state=00c46004] [content=0x91a9b60] [sc=0x91aec1c]<
                          Area(div)(-1)@0x91a7260 [view=0x91a75e0]
{0,0,4392,1872} [state=00d06014] sc=0x91aec90(i=2,b=0)<

views:
      0x91a7518 {2808,132,4392,1872} z=0 vis=1 opc=1.000 tran=1
clientData=0x91a7354 <
        0x91a75e0 {-2352,0,4392,1872} z=0 vis=1 opc=1.000 tran=1
clientData=0x91a7260 <
        >
      >

Textarea on top is Mozilla 1.6 (20040108) - text is misaligned and much of it
is hidden.
Textarea below is 1.5 - text is properly right-aligned.

Prog.
Attached file Testcase — 
This is the same testcase that appears in the screenshot.

Prog.
The offset seems to be the size of the wrapped line of text -- as though the
text were displayed un-wrapped and then wrapped without repositioning its left edge.
Sprinkling nsContainerFrame::PositionChildViews calls in a few places didn't
seem to help...
Of course, that's unlikely to help with a scrolling view.

I think the real problem is that we're resizing the nsScrollBoxFrame, and it
doesn't know that the idea of keeping in position means keeping the right edge
of its contents in position rather than the left edge.
> Sprinkling nsContainerFrame::PositionChildViews calls in a few places didn't
> seem to help...

Try whatever Ctrl+Home calls. It resets alignment to the proper offset.

Prog.
Attached patch a sort of a patch (obsolete) — — Splinter Review 
This patch works.  However, it deletes something which is then accessed shortly
afterwards.  I'll need to figure out how to avoid that.
Attachment #138675 - Flags: superreview?(bz-vacation)
Attachment #138675 - Flags: review?(roc)
I'm not sure if this is really something I'd want to put in 1.6 at this point,
but...
Assignee: mkaply → dbaron
Priority: -- → P1
Whiteboard: [patch]
Target Milestone: --- → mozilla1.6final
Comment on attachment 138675 [details] [diff] [review]
patch

Yoiks. Well, I guess it makes sense.
Attachment #138675 - Flags: review?(roc) → review+
Keywords: regression
Comment on attachment 138675 [details] [diff] [review]
patch

sr=bzbarsky.  This is a lot less scary than it seemed at first glance... ;)
Attachment #138675 - Flags: superreview?(bz-vacation) → superreview+
Fix checked in to trunk, 2004-01-10 11:12 -0800.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Comment on attachment 138675 [details] [diff] [review]
patch

Requesting 1.6 approval, although it might be a good idea for this to bake on
the trunk for a few days.
Attachment #138675 - Flags: approval1.6?
I created a 1.6 branch build with this patch applied, and it works very well. I
don't see any difference with the way textareas behave with this build compared
to 1.5, and I even got to test all the caret issues from Bug 207186.

If anyone wants to test this build, you can download it from the following URL:
http://oren.gomen.org/mozilla/downloads/1.6/mozilla16_20040110.exe

Note that my bandwidth is limited, but I'll probably mirror this file in a few
hours, so that more users can test it.

Prog.
Comment on attachment 138675 [details] [diff] [review]
patch

a=chofmann for 1.6.  we need to get this checked in by monday morning to make
the 1.6 final candidate builds
Attachment #138675 - Flags: approval1.6? → approval1.6+
Comment on attachment 138675 [details] [diff] [review]
patch

a=chofmann for 1.6
Fix checked in to MOZILLA_1_6_BRANCH, 2004-01-11 09:47 -0800.
Keywords: fixed1.6
Mass-assigning the new rtl keyword to RTL-related (see bug 349193).
Keywords: rtl
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.

Attachment

General

Creator:
Created:
Updated:
Size: