297790 - [RTL] Checkbox and bullets appear on wrong side of right-aligned menu and in RTL UI

Status: RESOLVED WORKSFORME

(Toolkit :: UI Widgets, defect)

Description

[Reuven Gonen]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; he; rv:1.8b2) Gecko/20050614 Firefox/1.0+
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; he; rv:1.8b2) Gecko/20050615 Firefox/1.0+

on Linux, checkbox marks and bullets appear in the menus of an RTL interface on
the wrong side.

Reproducible: Always

Steps to Reproduce:
1. download a Linux he build from:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk-l10n/firefox-1.0+.he.linux-i686.tar.gz
2. go to the View(תצוגה) menu and make sure there is a checkmark next to the
Status bar(שורת מצב) label.


Actual Results:  
the checkbox mark appears at the left side of the label

Expected Results:  
the checkbox mark should appear at the right of the label

Comment 1

[Reuven Gonen]

Attachment: screenshot of View menu

Comment 2

[Reuven Gonen]

Attachment: menulist arrows are misplaced

Comment 3

[Reuven Gonen]

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

Comment 4

[Simon Montagu :smontagu]

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

Comment 6

[Aaron]

This bug also affects menulists that are aligned right, in that the menulist does not indent the text from the right side when it is collapsed so that the arrow doesn't cover it. A basic example can be seen if you test the following code at http://ted.mielczarek.org/code/mozilla/xuledit/xuledit.xul :

<?xml version="1.0"?>
<?xml-stylesheet href="chrome://global/skin/" type="text/css"?>
<window id="yourwindow" xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
<menulist style="text-align:right;">
<menupopup>
<menuitem label="test" />
</menupopup>
</menulist>
</window>

Comment 7

[(no longer active)]

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

Comment 8

[(no longer active)]

Can anyone reproduce this bug now?

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+1]]

This is more a widget bug as a menu bug. I've tried to create a testcase. I'll attach it right away.

Ehsan, as what I can see there are two different problems. Probably the second one isn't known yet?

1. The bullets or checkboxes are placed correctly when the element has explicitly the dir attribute set. But in such a case the text is still aligned to the wrong side.

2. The ordering of the radiobuttons in the radiogroup looks wrong to me. Shouldn't they be displayed in a reversed order?

Please tell me if I should file new bugs on the specific problems which will not be covered on this bug.

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: testcase (rtl)

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: testcase (ltr)

Comment 12

[(no longer active)]

(In reply to comment #9)
> This is more a widget bug as a menu bug. I've tried to create a testcase. I'll
> attach it right away.

This bug is really confusing.  In comment 0, this was filed for menus (<xul:menuitem> in <xul:menupopup>).  In comment 6, it was extended to cover <xul:menuitem> in <xul:menulist>.  And the test cases that you attached now focus on <xul:checkbox> and <xul:radio>.  :-)

So, firstly I'd like to know if the issue in comment 0 and comment 6 is still reproducible or not.  Can you please test those, Henrik?

Also, I'm pretty sure that the test cases you attached here are invalid, since the dir attribute for XUL elements is entirely different than that of HTML elements.  The docs <https://developer.mozilla.org/en/XUL/Attribute/dir> are kind of vague, so I'm not really sure if the rendering of the test cases is the same thing we want, but I'm sure that these test cases do not test RTL functionality, as none of the frames in those test cases are RTL (this can be verified using the DOM Inspector.)  CCing Neil who is probably able to provide more insight here.

> Ehsan, as what I can see there are two different problems. Probably the second
> one isn't known yet?
> 
> 1. The bullets or checkboxes are placed correctly when the element has
> explicitly the dir attribute set. But in such a case the text is still aligned
> to the wrong side.

Like I said, if that is a problem, then it's a different bug (and not an RTL bug, BTW).

> 2. The ordering of the radiobuttons in the radiogroup looks wrong to me.
> Shouldn't they be displayed in a reversed order?

I think the behavior we're seeing is that dir=ltr appears as dir=normal and dir=rtl as dir=reverse.  I don't know if that's intended or not.

> Please tell me if I should file new bugs on the specific problems which will
> not be covered on this bug.

Let's see what Neil thinks here.

Comment 13

[Tomer Cohen :tomer]

I am just wondering - why the rtl testcase above is vertically aligned to the bottom of the page while the ltr one doesn't? I can't find any directive to do so in the file itself, and according to my view, dir=rtl should not affect vbox in this way. 

I think we solved this issue with 3.0 release by fixing theme issues (float, probably). You should try to reproduce this issue on the three platforms, as every platform has different theme.

Comment 14

[(no longer active)]

Like I said, dir=rtl in XUL does *not* mean style="direction:rtl", and I think it has the same effect as dir=reverse which reverses the order of the children of any box, be it horizontal or vertical.

Comment 15

[Neil Deakin]

dir="rtl" and dir="ltr" force the box to be right-to-left and left-to-right respectively, regardless of the style setting. dir="reverse" merely reverses what the css direction property specifies. dir="rtl/ltr" probably doesn't need to apply to vertical boxes though which is what the testcases above use. That said, it (and the testcases) doesn't relate to the bug.

Comment 16

[(no longer active)]

When I used DOM Inspector on the XUL elements of these test cases, the computed style for all of them had set the direction style to ltr.  Is dir=rtl handled differently?  For HTML, the following rule in layout/style/html.css causes all elements with dir=rtl to have RTL CSS direction:

[dir="rtl"] {
  direction: rtl;
  unicode-bidi: embed;
}

Don't XUL elements also use this computed style to determine their direction?

Comment 17

[(no longer active)]

To demonstrate my point, check out this test case:

data:text/xml,<?xml version="1.0"?><?xml-stylesheet href="chrome://global/skin/" type="text/css"?><window xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"><checkbox checked="true" label="dir='rtl'" dir="rtl" /><checkbox checked="true" label="direction: rtl" style="direction: rtl;" /></window>

The rendering behavior of the two check boxes certainly differs.

Comment 18

[(no longer active)]

Actually, check out:

data:text/xml,<?xml version="1.0"?><?xml-stylesheet href="chrome://global/skin/" type="text/css"?><window xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"><checkbox checked="true" label="dir='rtl'" dir="rtl" /><checkbox checked="true" label="dir='reverse'" dir="reverse" /><checkbox checked="true" label="direction: rtl" style="direction: rtl;" /></window>

Comment 19

[Neil Deakin]

The xul dir attribute isn't the same as the html dir attribute. It doesn't affect whether the UI is right-to-left or the writing direction. If simply means reverse the order in which the children of a box are placed, and applies equally to horizontal and vertical boxes. The order in which the children of a box are placed is also affected by the CSS direction property. The CSS direction property is the only means to specify the ui/bidi/writing direction.

The checkbox has two children of interest here, the checkmark and the label. In comment 18 there are three checkboxes. When using dir="rtl" it means display the two children right to left. When using dir="reverse" it means display the two children in reverse of the normal ui direction. The third child checkbox however is the only one that actually implies a right-to-left UI.

The point is, is that the dir attribute doesn't have anything to do with this bug.

Comment 20

[(no longer active)]

Thanks for the clarification, Neil.

Comment 21

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Marking testcases as obsolete. Ehsan, can you create a testcase which really shows the problem here? I won't have time for that.

Comment 22

[(no longer active)]

Judging from attachment 186329 [details] and attachment 186331 [details], this should be present in the main UI.  What I was asking in comment 8 is if anyone can still reproduce this in the main UI (like for example Firefox menus and the content prefpane).  Can you test it in those cases, please?  (I'm fairly certain that this can't be reproduced any more).  If that is not the case, I'd be happy to create a reduced test case.

Comment 23

[Itiel]

Reuven, is this still reproducible?

Comment 24

[BugBot [:suhaib / :marco/ :calixte]]

Clear a needinfo that is pending on an inactive user.

For more information, please visit auto_nag documentation.

Comment 25

[Itiel]

This seems to be working fine for me on Ubuntu 22.04.
Feel free to reopen if this still reproduces for you.