1220440 - Available languages are not displayed/cut off in Options -> Content -> Languages

Status: RESOLVED DUPLICATE of bug 1194346

(Firefox :: Settings UI, defect)

Description

[Yaron]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:42.0) Gecko/20100101 Firefox/42.0
Build ID: 20151029151421

Steps to reproduce:

Options -> Content -> Languages
Select...


Actual results:

Available languages are not displayed until pressing somewhere in the dialog.
http://postimg.org/image/vny4r4b11/

Comment 1

[Yaron]

http://s2.postimg.org/t6mdjur4p/Langs.png

Comment 2

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Confirming with Firefox 42.0 in Hebrew on Windows 8.1.

This might be an RTL issue or because of the long label for es-do (Spanish/Dominican Republic).

Comment 3

[Yaron]

Thank you Sebastian. I appreciate it.

Did you happen to test it with LTR locals?

Comment 4

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

With English, I didn't notice the issue. In Hebrew, there was something in the fourth line, but it was cut off. Using the dropdown seemed to fix it. Changing window.with in languages.dtd allows to fix it: https://transvision.mozfr.org/string/?entity=browser/chrome/browser/preferences/languages.dtd:window.width&repo=release

Tomer, can you investigate the issue, please?

Comment 5

[Yaron]

Thanks again Sebastian.

>Changing window.with in languages.dtd allows to fix it

Could you please elaborate?
I've changed the width to 32em; - the basic problem is still there.

Comment 6

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Setting it to 37em fixes it here. But that applies only to new profiles because Firefox caches the window/popup dimensions if you opened it already earlier.

Comment 7

[Yaron]

Thank you!

Yes, the languages are displayed.
Please note that after pressing somewhere in the dialog, the layout changes (better padding).

Comment 8

[Yaron]

Sebastian,

May I ask your opinion about Bug 1220443?
- Not necessarily a solution. Just the logic behind the behavior.

Thanks.

Comment 9

[Tomer Cohen :tomer]

Attachment: Yaron's screenshot

Comment 10

[Tomer Cohen :tomer]

Attachment: listbox#activeLanguages with dir=ltr

This is not a width issue, because when adding direction:ltr to the listbox#activeLanguages it doesn't overlap the display area (but lost its direction…). Also, if it was caused by long strings (the es-do case mentioned in comment 2) there should be visible horizontal scrollbar and it doesn't exists on the Hebrew locale. 

This is indeed an RTL issue, and reproduces on Linux (Aurora v43) as well.

Comment 11

[Yaron]

Thank you Tomer. I appreciate it.

Comment 12

[Simon Montagu :smontagu]

Regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=09f4968d5f42&tochange=9696d1c4b3ba

I suspect regression from bug 1119475.

Comment 13

[Jonathan Kew [:jfkthame]]

I'm not sure the range in comment 12 is correct... I built 09f4968d5f42 locally and could still reproduce this (on OS X, with intl.uidirection.en set to rtl).

I wonder if this is basically a problem with flex layout in RTL direction; it looks like it may be computing a width for the list items before taking account of the width of the buttons that will appear to the left of the list (in RTL). Then, when a user action triggers another reflow, things get updated and the list items are sized properly.

It's possible bug 1119475 has had some effect on the exact circumstances where the problem occurs, but I don't think it's the root cause here.

Comment 14

[Jonathan Kew [:jfkthame]]

Also reproduced in about:preferences#content on Firefox 37.0.2 / OS X / intl.uidirection.en = rtl.

Comment 15

[Yaron]

Thank you Simon and Jonathan.
Bug 1095915 is another interesting mystery.

Comment 16

[Daniel Holbert [:dholbert]]

This was reported earlier as bug 1194346.  Duping.

(The proximal cause is bug 1131371, but really it's an extremely-long-standing underlying bug -- bug 1194844 -- about XUL listboxes not getting reflowed sometimes when really they need to.  And bug 1131371 just incidentally removed some redundant reflowing that happened to be masking this problem by giving us extra reflows.)

Comment 17

[Daniel Holbert [:dholbert]]

(In reply to Jonathan Kew (:jfkthame) from comment #13)
> I wonder if this is basically a problem [...]
> Then, when a user action triggers another reflow, things get
> updated and the list items are sized properly.

(This is indeed approximately what's going on, per bug 1194844. And the recent-ish thing that regressed this [or at least made it easier to hit] is that I removed one route for another reflow to be triggered, in bug 1194844.)

Comment 18

[Daniel Holbert [:dholbert]]

Sorry, "removed one route... in bug 1131371" (not 1194844)

Comment 19

[Yaron]

Thank you Daniel.