Closed
Bug 1220440
Opened 9 years ago
Closed 9 years ago
Available languages are not displayed/cut off in Options -> Content -> Languages
Categories
(Firefox :: Settings UI, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 1194346
People
(Reporter: mvocom, Unassigned)
Details
(Keywords: regression, rtl)
Attachments
(2 files)
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 2•9 years ago
|
||
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?
Comment 4•9 years ago
|
||
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?
Flags: needinfo?(tomer.moz.bugs)
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•9 years ago
|
||
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.
Comment 9•9 years ago
|
||
Flags: needinfo?(tomer.moz.bugs)
Comment 10•9 years ago
|
||
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.
Reporter | ||
Comment 11•9 years ago
|
||
Thank you Tomer. I appreciate it.
Comment 12•9 years ago
|
||
Regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=09f4968d5f42&tochange=9696d1c4b3ba
I suspect regression from bug 1119475.
Flags: needinfo?(jfkthame)
Keywords: regression
Comment 13•9 years ago
|
||
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.
Flags: needinfo?(jfkthame)
Comment 14•9 years ago
|
||
Also reproduced in about:preferences#content on Firefox 37.0.2 / OS X / intl.uidirection.en = rtl.
Reporter | ||
Comment 15•9 years ago
|
||
Thank you Simon and Jonathan.
Bug 1095915 is another interesting mystery.
Comment 16•9 years ago
|
||
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
Closed: 9 years ago
Resolution: --- → DUPLICATE
Comment 17•9 years ago
|
||
(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•9 years ago
|
||
Sorry, "removed one route... in bug 1131371" (not 1194844)
Reporter | ||
Comment 19•9 years ago
|
||
Thank you Daniel.
You need to log in
before you can comment on or make changes to this bug.
Description
•