154632 - Text in SELECT widgets with dir=rtl overlaps the pop-up control

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect, P3)

Description

[Shoshannah Forbes]

in a <select> element, if it has dir=rtl applied, the text in the select over
laps the control.

Comment 1

[Shoshannah Forbes]

This is with chimera 0.3.0

Comment 2

[Shoshannah Forbes]

Attachment: Testcase with dir

Comment 3

[saari (gone)]

neat, select control text rendering needs a little patching

Comment 4

[Mike Pinkerton (not reading bugmail)]

over to bryner

Comment 5

[Greg K.]

Confirmed using Chimera/20020625.

Comment 6

[Steve Smart]

We're rendering this in the same place as Mozilla; Mozilla assumes that the
arrow is on the left, whereas ours is on the right, so the text needs to be
offset by however big the arrow widget is.

Comment 7

[Greg K.]

Can the Cocoa widgets be drawn in the other direction as the XUL widgets are in
Mozilla?

Comment 8

[Shoshannah Forbes]

Re comment #7: As far as I understand, yes- but only under 10.2

Comment 9

[Ludovic Hirlimann [:Usul]]

still true under 2003082402

Comment 10

[Greg K.]

*** Bug 197742 has been marked as a duplicate of this bug. ***

Comment 11

[Shoshannah Forbes]

still true under the latest nightlies

Comment 12

[Asaf Romano (gone)]

Simple workaround:

Add the following style-definition to your userContent.css:

select
{
    direction: ltr;
}

Using text-align makes better sense, but it is a bit buggy with some pages (e.g.
all phpbbheb forums)

Comment 13

[Jasper]

I can confirm that adding the "direction; ltr;" to the select style in
platform-forms.css fixes the issue is solved. Looks like a solid fix to me.

Comment 14

[Mike Pinkerton (not reading bugmail)]

landed.

Comment 15

[Shoshannah Forbes]

>Looks like a solid fix to me.

Umm.. not really- it messes up widgets that have both Hebrew and English in them
(or parentasis)

Comment 16

[Asaf Romano (gone)]

(In reply to comment #15)
> >Looks like a solid fix to me.
> 
> Umm.. not really- it messes up widgets that have both Hebrew and English in them
> (or parentasis)

There is no way yto implement what you are asking for, OS X doesn't support BiDi
widgets.
Even in the previous status, if you opened the menu, it become broken.

Close again...

They could use "text-align: left" instead of direction, but it doesn't work
always, and bring up some very strange issues in phpBBheb 

Comment 17

[Asaf Romano (gone)]

(In reply to comment #15)
> >Looks like a solid fix to me.
> 
> Umm.. not really- it messes up widgets that have both Hebrew and English in them
> (or parentasis)

By the way, we are talking ONLY about select-boxes not every widget

Comment 18

[Jasper]

Could somebody provide a test case that shows that this isn't fixed yet because
the current testcase is WFM.

Please update.

Comment 19

[Shoshannah Forbes]

Still broken with latest nightly: 2004102908 (v0.8+)

Comment 20

[Shoshannah Forbes]

Attachment: updated testcase

Comment 21

[Shoshannah Forbes]

Attachment: screen shot of the overlap

BTW, when the widget is open, the contents are not aligned to the right as they
should for a RTL widgest. I am opening another bug for that.

Comment 22

[Shoshannah Forbes]

The alignment issue in the open control is now reported as bug #266846

Comment 23

[Uri Bernstein]

This affects CocoaFox as well. Moving to Core/Widget:Cocoa.

Comment 24

[Behnam Esfahbod [:zwnj]]

Same problem for GTK2 backend: Bugzilla Bug 316748 - [RTL] [GTK] dropdown arrow is on the wrong side.

Note that the GTK2 problem doesn't exist in fx1.0.

Comment 25

[Uri Bernstein]

Now that bug 175279 landed, this affects regular Firefox trunk builds.

Comment 26

[Asaf Romano (gone)]

Uri, could you actually reproduce this on Fx trunk? This looks fine in my build.

Comment 27

[Uri Bernstein]

Yes, I'm seeing this with:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a5pre) Gecko/20070526 Minefield/3.0a5pre ID:2007052604 [cairo]

(which is what drove me to make the comment here).

Comment 28

[Asaf Romano (gone)]

Weird, I cannot reproduce it with the testcase here, maybe one of the regressions fixed after the initial landing broke that?

Comment 29

[Uri Bernstein]

What are you seeing? Is the blue section with the little arrows on the left? Or is the text just shifted to the left so that it doesn't overlap the control?

I would be surprised if this was fixed and re-broken, but I guess you can verify by trying today's nightly. 

Comment 30

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I think it was "fixed" and re-broken, because I looked at it the other day (in looking at something else) and went, "hey, that bug is fixed," but it's definitely broken in today's Minefield and the CmTrunk I built last night.

Maybe the "selects have extra padding" bug made this look fixed, and josh checked in a fix for that bug in the last day or so.

Comment 31

[Josh Aas]

My patch in bug 382043 should fix this again.

Comment 32

[Josh Aas]

Fixed on trunk by bug 382043.

Comment 33

[(no longer active)]

Mass-assigning the new rtl keyword to RTL-related (see bug 349193).