Bug 19785 - <select> can't display right-to-left (rtl) languages
: <select> can't display right-to-left (rtl) languages
Status: RESOLVED FIXED
: WebKit
CSS
: 525.x (Safari 3.1)
: All All
: P2 Normal
Assigned To:
: http://shelleyandjosh.com/test/rtl_se...
:
: 38780
: 50969
  Show dependency treegraph
 
Reported: 2008-06-26 19:18 PST by
Modified: 2011-01-28 13:37 PST (History)


Attachments
test case (1.08 KB, text/html)
2009-09-23 14:35 PST, Xiaomei Ji
no flags Details
FF's handling on the above test case (13.88 KB, image/jpeg)
2009-09-23 14:36 PST, Xiaomei Ji
no flags Details
On Mac OS X, align pop-up menu items according to the <select>’s writing direction and use <option>’s writing direction for each (58.59 KB, patch)
2011-01-28 11:33 PST, mitz@webkit.org
no flags Review Patch | Details | Formatted Diff | Diff
On Mac OS X, align pop-up menu items according to the <select>’s writing direction and use <option>’s writing direction for each (63.68 KB, patch)
2011-01-28 12:19 PST, mitz@webkit.org
no flags Review Patch | Details | Formatted Diff | Diff
On Mac OS X, align pop-up menu items according to the <select>’s writing direction and use <option>’s writing direction for each (63.68 KB, patch)
2011-01-28 12:57 PST, mitz@webkit.org
sam: review+
Review Patch | Details | Formatted Diff | Diff


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2008-06-26 19:18:43 PST
It seems impossible to get Safari to render a <select> with the text right justified.

This makes webpages that are localized for RTL languages (like Arabic) not look correct, as their <select> boxes can't correctly show text RTL.

Perhaps there is some tricky CSS to make this happen, but from everything I've been able to look at it does seem like anything makes Safari do the right thing.
------- Comment #1 From 2008-06-26 19:56:41 PST -------
Isn't this how dropdown controls on Mac behave with RTL text?
------- Comment #2 From 2008-06-26 19:57:52 PST -------
(I didn't think popup menus did right justified text for RTL on OS X.)  Since OS X doesn't flip scrollbars either in its controls, I don't think text is right justified for list boxes either, but I could be wrong.  I'll let Mitz comment.
------- Comment #3 From 2008-06-27 16:28:52 PST -------
Right-to-left pop-ups are not available in Mac OS X. It is possible to right-align menu items but indentation and markers would still be on the left. For list boxes, I think it would be okay to support text-align:right if other browsers do it, and leave the scroll bar on the right.
------- Comment #4 From 2008-07-23 01:16:36 PST -------
Does this make this a windows-only bug then?
------- Comment #5 From 2008-07-23 16:00:09 PST -------
This is *not* a windows only bug.  The bug impacts Safari in OS X as well.

From the sounds of it, it may be infeasible to fix in OS X?

Also, I should point out that Firefox right-aligns the text, even while leaving the scroll bar on the right.
------- Comment #6 From 2009-01-07 16:17:09 PST -------
Related Chrome bug: http://code.google.com/p/chromium/issues/detail?id=6113
------- Comment #7 From 2009-02-02 17:30:51 PST -------
Correct, FF3 shows these pop-ups with the text left-justified, even on the Mac.  It seems since we paint the text ourselves, this should be "easy" to fix, if we can get a comprehensive test case which makes clear what edge cases we need to support.  Mitz is the only WebKit committer able to read an RTL language (that I know of), so a test case from an RTL speaker which demonstrates what should be done when the text is too long to fit in the popup, what should be done for multi-selects, etc. could be very useful. :)
------- Comment #8 From 2009-04-15 14:46:58 PST -------
the related chrome bug is now
http://code.google.com/p/chromium/issues/detail?id=6244
------- Comment #9 From 2009-09-23 14:31:41 PST -------
Hi Mitz,

I have some thought on the problem and would like to know what do you think.

For <select><optioin>:

IE in windows ignore directionality in <option> and it sets the item's writing direction and alignment (both the selected item in menu and the items in drop-down) based on the directionality of the <select>.

FF in windows and Mac render item in menu (for both alignment and text writing direction) based on the directionality of the <select>, but it render the items in drop-down (for both alignment and text writing direction) based on the directionality of <option>. So, there is inconsistency for both alignment and writing directionality between the items in selected menu and in drop-down list. (See attachment).

Looks like currently, webkit uses natrual-writing-direction to display both the selected item in menu and the items in drop-down list.

But the text-alignment of selected item in menu is always set as LEFT.

I asked Aharon's opinion on the alignemnt and writing direction of <select>.
He thinks "the directionality be estimated for each option
separately, with each option displayed in its own directionality both in the
drop-down and when chosen. The select's directionality should only affect the
position of the arrow button (and possibly the alignment of the items, in both
the dropdown and the select, which is the real issue at hand). This way, there
is no inconsistency between what the user sees in the dropdown and the chosen
item." (please refer to comment #5 in https://bugs.webkit.org/show_bug.cgi?id=29612 for detail).

In another word, he thinks the writing direction in webkit is desired, but not the alignment.

The text-alignment of selected item in menu is always set as LEFT in RenderMenuList::adjustInnerStyle().

    if (PopupMenu::itemWritingDirectionIsNatural()) {
        // Items in the popup will not respect the CSS text-align and direction properties,
        // so we must adjust our own style to match.
        m_innerBlock->style()->setTextAlign(LEFT);
        ...
    }

From your comment #3, should we remove the above text-alignment resetting? So that the selected item in menu is aligned based on select element's alignment, while its directionality is still based on natural writing direction.
Or we can introduce PopupMenu::itemNatrualWritingDirectionDomElementAlignment().

As to the items in drop-down list, looks like it is taken care by each client. In order for each client to handle alignment and writing direction separately for items in drop-down, I think we need to add textAlignment to PopupMenuStyle.

For example, given the following structure:
<select dir="rtl">
<option>abc CBA</option>   (where 'CBA' represents Hebrew word)
<option>CBA abc</option>
</select>

The writing direction of "abc CBA" is LTR, while writing direction of "CBA abc" is RTL.
But both "abc" and "CBA" should be right-aligned in drop-down box (and in selected menu). Without passing the text alignment to PopupMenuStyle, there is no way for each client to display them as right-aligned.

In summary, we need to 
1. remove the alignment resetting in RenderMenuList::adjustInnerStyle() for rendering selected item in the menu.
2. add textAlignment to PopupMenuStyle, so that each client could control how to render (in writing direction and in alignment) items in drop-down.


Looking forward for your input!

Thanks,
Xiaomei
------- Comment #10 From 2009-09-23 14:35:17 PST -------
Created an attachment (id=40019) [details]
test case
------- Comment #11 From 2009-09-23 14:36:29 PST -------
Created an attachment (id=40020) [details]
FF's handling on the above test case
------- Comment #12 From 2011-01-28 11:33:15 PST -------
Created an attachment (id=80470) [details]
On Mac OS X, align pop-up menu items according to the <select>’s writing direction and use <option>’s writing direction for each
------- Comment #13 From 2011-01-28 11:58:36 PST -------
(From update of attachment 80470 [details])
View in context: https://bugs.webkit.org/attachment.cgi?id=80470&action=review

> Source/WebCore/rendering/RenderMenuList.cpp:213
> +            m_buttonText->setText(s.impl(), true);

What's the true?

> Source/WebKit/chromium/src/ChromeClientImpl.h:176
>      virtual bool selectItemWritingDirectionIsNatural();
> +    virtual bool selectItemAlignmentFollowsMenuWritingDirection();

I'm surprised this interface doesn't just return a writing direction.  But maybe I'm misunderstanding.
------- Comment #14 From 2011-01-28 12:07:05 PST -------
(In reply to comment #13)
> (From update of attachment 80470 [details] [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=80470&action=review
> 
> > Source/WebCore/rendering/RenderMenuList.cpp:213
> > +            m_buttonText->setText(s.impl(), true);
> 
> What's the true?

Force, but this was not meant to be part of this change.
------- Comment #15 From 2011-01-28 12:19:38 PST -------
Created an attachment (id=80480) [details]
On Mac OS X, align pop-up menu items according to the <select>’s writing direction and use <option>’s writing direction for each
------- Comment #16 From 2011-01-28 12:57:53 PST -------
Created an attachment (id=80487) [details]
On Mac OS X, align pop-up menu items according to the <select>’s writing direction and use <option>’s writing direction for each
------- Comment #17 From 2011-01-28 13:35:55 PST -------
Fixed in r76983 <http://trac.webkit.org/changeset/76983>.
------- Comment #18 From 2011-01-28 13:36:17 PST -------
(From update of attachment 80487 [details])
View in context: https://bugs.webkit.org/attachment.cgi?id=80487&action=review

> Source/WebCore/rendering/RenderMenuList.cpp:101
> +        innerStyle->setTextAlign(style()->isLeftToRightDirection() ? LEFT : RIGHT);

what if the menu's writing direction is LTR, but it is alignment is right?
------- Comment #19 From 2011-01-28 13:37:25 PST -------
(In reply to comment #18)
> (From update of attachment 80487 [details] [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=80487&action=review
> 
> > Source/WebCore/rendering/RenderMenuList.cpp:101
> > +        innerStyle->setTextAlign(style()->isLeftToRightDirection() ? LEFT : RIGHT);
> 
> what if the menu's writing direction is LTR, but it is alignment is right?

The button and the menu items will disregard the text-align value. We are not going to center or justify menu items on Mac OS X.