Closed Bug 154632 Opened 20 years ago Closed 15 years ago

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

Categories

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

PowerPC
macOS
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: xslf, Assigned: jaas)

References

(Blocks 3 open bugs)

Details

(Keywords: intl, rtl, testcase)

Attachments

(2 files, 1 obsolete file)

in a <select> element, if it has dir=rtl applied, the text in the select over
laps the control.
This is with chimera 0.3.0
Attached file Testcase with dir (obsolete) —
neat, select control text rendering needs a little patching
Assignee: saari → pinkerton
over to bryner
Assignee: pinkerton → bryner
Confirmed using Chimera/20020625.
Keywords: intl, testcase
Summary: combo boxes with dir=rtl have text overlap the control → Text in SELECT widgets with dir=rtl overlaps the pop-up control
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.
Can the Cocoa widgets be drawn in the other direction as the XUL widgets are in
Mozilla?
Re comment #7: As far as I understand, yes- but only under 10.2
still true under 2003082402
*** Bug 197742 has been marked as a duplicate of this bug. ***
still true under the latest nightlies
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)
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.
landed.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
>Looks like a solid fix to me.

Umm.. not really- it messes up widgets that have both Hebrew and English in them
(or parentasis)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(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 
(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
Could somebody provide a test case that shows that this isn't fixed yet because
the current testcase is WFM.

Please update.
Still broken with latest nightly: 2004102908 (v0.8+)
Attached file updated testcase
Attachment #89419 - Attachment is obsolete: true
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.
The alignment issue in the open control is now reported as bug #266846
Assignee: bryner → pinkerton
Status: REOPENED → NEW
Priority: -- → P3
QA Contact: winnie
Target Milestone: --- → Camino1.1
Component: Page Layout → HTML Form Controls
QA Contact: form.controls
Assignee: mikepinkerton → nobody
Target Milestone: Camino1.1 → Camino2.0
This affects CocoaFox as well. Moving to Core/Widget:Cocoa.
Component: HTML Form Controls → Widget: Cocoa
Product: Camino → Core
Target Milestone: Camino2.0 → ---
Version: unspecified → Trunk
Assignee: nobody → joshmoz
QA Contact: form.controls → cocoa
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.
Blocks: Persian
Now that bug 175279 landed, this affects regular Firefox trunk builds.
Blocks: 175279
Flags: blocking1.9?
Uri, could you actually reproduce this on Fx trunk? This looks fine in my build.
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).
Weird, I cannot reproduce it with the testcase here, maybe one of the regressions fixed after the initial landing broke that?
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. 
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.
My patch in bug 382043 should fix this again.
Depends on: 382043
Flags: blocking1.9? → blocking1.9+
Fixed on trunk by bug 382043.
Status: NEW → RESOLVED
Closed: 18 years ago15 years ago
Resolution: --- → FIXED
Mass-assigning the new rtl keyword to RTL-related (see bug 349193).
Keywords: rtl
You need to log in before you can comment on or make changes to this bug.