The "OK", "Cancel" and "Help" buttons from the "Languages" pop-up are cut off

VERIFIED FIXED in Firefox 62

Status

()

defect
VERIFIED FIXED
Last year
11 months ago

People

(Reporter: mcoman, Assigned: zbraniecki)

Tracking

({regression})

Trunk
Firefox 62
x86_64
Windows
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr52 unaffected, firefox-esr60 unaffected, firefox60 unaffected, firefox61 unaffected, firefox62 verified)

Details

Attachments

(2 attachments)

Posted image language panel.gif
**[Affected versions]:**
- Firefox Nightly (62.0a1 - Build ID 20180510100205)

**[Affected Platforms]:**
- All Windows

**[Prerequisites]:**
- Have a new Firefox profile.

**[Steps to reproduce]:**
1. Open the browser with the profile from prerequisites.
2. Navigate to the "about:preferences#general" page.
3. Click the "Choose" button from the "Language and Appearance" section.
4. Observe the buttons displayed in the bottom part of the pop-up.

**[Expected result]:**
- The buttons are entirely visible.

**[Actual result]:**
- The buttons are cut off, because are overlapped by the pop-up margins.

**[Regression window]:**
Last good revision: b32423756cb7383969fc4cd366f852ce2e5523ce
First bad revision: af2f85201ec26b3a639e9e2ba94e805c5f5890a1
Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b32423756cb7383969fc4cd366f852ce2e5523ce&tochange=af2f85201ec26b3a639e9e2ba94e805c5f5890a1

From this pushlog looks like the Bug 1457021 caused this issue. 

**[Notes]:**
- Attached a screen recording of the issue.
Interesting, I thought we fixed all these in bug 1457252.

Comment 2

Last year
(In reply to Francesco Lodolo [:flod] from comment #1)
> Interesting, I thought we fixed all these in bug 1457252.

I think the regressor made the generation of the list of languages async, and so we should wait for that to finish before deciding on the size of the dialog. Gandalf, does that sound right?
Flags: needinfo?(gandalf)
yep! on it.
Assignee: nobody → gandalf
Status: NEW → ASSIGNED
Flags: needinfo?(gandalf)
So, it's not about the bootstrap here. What's going on is:

1) The listbox is bound to preferences
2) Before first paint XUL removes the content of the listbox
3) Somehow the listbox without content has different height than with content
4) First paint calculates the subdialog size
5) Prefs are loaded asynchronously
6) Prefs populate the listbox and l10n is set
7) Fluent localizes the new content

Now, 5/6/7 are asynchronous and usually start before (4) but end up anywhere from before to after (4). If they end up after (4), the size is wrong.

We could try to force some content into the <listbox> to make it take the final size before prefs are loaded, but in my testing forcing eager localization did the trick just fine.

Soo... let's do this and hope the next revision of Preferences won't use XUL? :)
Comment on attachment 8974828 [details]
Bug 1460654 - Trigger eager l10n for listbox items in Preferences::Languages subdialog to avoid overflow.

https://reviewboard.mozilla.org/r/243208/#review249398
Attachment #8974828 - Flags: review?(jaws) → review+

Comment 7

Last year
Pushed by zbraniecki@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/2083171b3ecb
Trigger eager l10n for listbox items in Preferences::Languages subdialog to avoid overflow. r=jaws
https://hg.mozilla.org/mozilla-central/rev/2083171b3ecb
Status: ASSIGNED → RESOLVED
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → Firefox 62
I have reproduced this bug with Nightly 62.0a1 (2018-05-10) on Windows 10, 64 Bit!
This bug's fix is verified with latest Nightly!

Build ID   : 20180605100102
User Agent : Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0
QA Whiteboard: [bugday-20180530]
Flags: qe-verify+
Managed to reproduce with Nightly 62.0a1 (2018-05-10) on Windows 10x64 as well.

Verified the bug fix, using the Firefox 63.0a1 (2018-07-09) 62.0b7, 61.0.1;  and can confirm the issue is not reproducible on the mentioned versions.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.