some of the message text vanishes if message direction is set to RTL

RESOLVED WORKSFORME

Status

()

defect
RESOLVED WORKSFORME
15 years ago
8 years ago

People

(Reporter: eyalroz, Unassigned)

Tracking

({regression, rtl})

Trunk
x86
Windows XP
Points:
---
Bug Flags:
blocking1.8a6 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

15 years ago
In recent builds, messages which, upon loading, have their messages set to RTL
direction (e.g. due to the use of BiDi Mail UI - http://bidiui.mozdev.org/mail/)
are displayed with some of the text wiped out (screenshot to follow). I have not
experienced this happening otherwise. In 1.8a2  (I think) and backwards this
does not happen. It also does not happen with tbird 0.8 or 0.9 .

BTW - There is a possibility this also happens with the browser, I just haven't
tried setting dir=RTL on page load there.
(Reporter)

Comment 1

15 years ago
there should be more text to the right of the displayed text, in most of the
lines.

Note that selecting the missing text causes it to appear.
(Reporter)

Updated

15 years ago
Keywords: mail4
Product: MailNews → Core
(Reporter)

Comment 2

15 years ago
Although this bug can be worked around - selecting the text and de-selecting it,
or scrolling down and back up - this bug is of extremely high visibility for
users who read RTL mail, therefore I suggest blocking 1.8a6 .
Flags: blocking1.8a6?
(Reporter)

Comment 3

15 years ago
As per David Glazman's suggestion, cc'ing dbaron.
(Reporter)

Comment 4

15 years ago
as per David Barron's request, attached the text of the message in the
screenshot. Encoding should be Windows-1255.
Attachment #169529 - Attachment mime type: text/plain → text/plain; charset=windows-1255
(Reporter)

Comment 6

15 years ago
I was hoping this would be fixed before I would have to type in this
dependency...  :-(
Blocks: 240501
Attachment #169531 - Attachment mime type: text/plain; charset=windows-1255 → message/rfc822

Comment 7

15 years ago
Eyal, can you help us identify the day of the regression by looking through
nightly builds at http://archive.mozilla.org/pub/mozilla/nightly/ and finding
the build where it broke? This may help us identify the problem checkin faster. 

If it worked in 1.8a2 then it would be a pretty easy binary search between the
July 14 nightly build and when you reported this bug (November 9).
(Reporter)

Comment 8

15 years ago
Unfortunately, not right now, since I am about to be offline for a long while
due to various problems I won't go into... but I'll try to get this done within
a few days, maybe a week. Mano, Prog: if you can reproduce this, please oblige
Asa instead of me...

Comment 9

15 years ago
too late for 1.8a6. blocking-
Flags: blocking1.8a6? → blocking1.8a6-
(Reporter)

Comment 10

15 years ago
Not seeing the bug with 1.8a4, i.e. with build 2004-08-17 09.
(Reporter)

Comment 11

15 years ago
Seeing the bug with a build from November 1st.

Also, I've found a sure way to reproduce the bug (with BiDi Mail UI installed):

1. Open MailNews
2. Set the composition prefs to compose HTML messages (rather than text messages)
3. Set the BiDi Mail UI prefs so that the default composition direction is RTL
4. Open a new message composition window
5. Enter the text "abc" (it should be aligned to the right since the direction
is RTL)
6. Press Ctrl+Shift+X to change the direction to LTR
7. The "abc" vanishes, and the cursor appears at the left part of the window, as
at the position it should appear at after entering "abc".
8. Use the arrow keys to move left and right - the text remains invisible but
the cursor movement is appropriate
9. Switch to another window, then switch back. The text is now visible again.

Note that if instead of step 6 you change the paragraph dir using the dir
buttons in the formatting bar, the bug won't manifest itself.
Mass-assigning the new rtl keyword to RTL-related (see bug 349193).
Keywords: rtl

Updated

11 years ago
Component: MailNews: BiDi Hebrew & Arabic → Layout: Text
QA Contact: giladehven → layout.fonts-and-text
Assignee: mozilla → nobody
(In reply to Eyal Rozenberg from comment #11)
> Seeing the bug with a build from November 1st.
Is this issue still relevant?
(Reporter)

Comment 14

8 years ago
Not seeing this any longer (using TB 7.0b).
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.