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/
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).
Status: UNCONFIRMED → NEW
Component: Untriaged → Preferences
Ever confirmed: true
Summary: Available languages are not displayed in Options -> Content -> Languages → Available languages are not displayed/cut off in Options -> Content -> Languages
Thank you Sebastian. I appreciate it. Did you happen to test it with LTR locals?
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?
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.
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.
Thank you! Yes, the languages are displayed. Please note that after pressing somewhere in the dialog, the layout changes (better padding).
Sebastian, May I ask your opinion about Bug 1220443? - Not necessarily a solution. Just the logic behind the behavior. Thanks.
Created attachment 8681771 [details] 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.
Thank you Tomer. I appreciate it.
Regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=09f4968d5f42&tochange=9696d1c4b3ba I suspect regression from bug 1119475.
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.
Also reproduced in about:preferences#content on Firefox 37.0.2 / OS X / intl.uidirection.en = rtl.
Thank you Simon and Jonathan. Bug 1095915 is another interesting mystery.
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.)
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1194346
(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.)
Sorry, "removed one route... in bug 1131371" (not 1194844)
Thank you Daniel.
You need to log in before you can comment on or make changes to this bug.