Affected versions

• 73.0a1(2019-12-03), 72.0b1, 71.0, 68.3esr;

Affected platforms

• Windows 10(ARM), Ubuntu 16.04;

Steps to reproduce

1. Launch Firefox access about:profiles
2. Click on the Restart with addons disabled... button;
3. Click on the Refresh Firefox button;

Expected result

• the window for Refresh Firefox is disabled and content is properly contained and displayed;

Actual result

• text from the description is pushed on the next row causing the buttons to appear truncated;

Regression range

• will look into it at a later date;
• limitation is, that it reproduces on some machines only probably related to the font density as well;
• leaving the regression-window wanted keyword up until we can confirm;

Additional notes

• noticed with :vlucaci on some devices, so for additional information any of us can be contacted;
• attached screenshot with the issue;
  ** this issue can also be viewed as an enhancement, in the way that the window can and should adjust the height based on the available content instead of truncating it.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=cf32e70c234f4ce2361bb8e01a08ccd9a8ea24c6&tochange=68f9119eacf574ed41522163366e23e68fbdedfa

Minor polish issue that we have since 67, when we have a fix we can let it ride the trains.

Sigh… yet another regression from the Fluent migration wrt. to dialog sizing. I get the feeling that Fluent is still having a net negative impact on users and I don't see that changing anytime soon as user-facing benefits are a ways away (and things like live language switching aren't going to be used frequently or regularly).

(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #3)

I don't see [fluent having a positive user impact] anytime soon as user-facing benefits are a ways away

I'm pretty optimistic we can end the use of DTDs next quarter, which would eliminate the YSOD. It will likely also help with the update/langpack issues ( bug 1566084, bug 1564998).

The dialog resize issues shouldn't be super hard to fix - I think we found out too late that they'd be happening and didn't take this into account. That's unfortunate, but we'll take it into account going forward.

Too late for a fix in 72 but we could still take a patch for 74 and possibly 73.

I can't reproduce on Windows 10. I also tried changing the text size, the DPI, or both, and still was not able to reproduce on current nightly.

Can you still see this on current nightly, and if so, what Windows settings and what steps do you use, esp. if they're different from the ones in comment #0 ? Any chance this is a race condition and only happens some of the time?

I also can't reproduce on Ubuntu. You mentioned in comment #0 that you can reproduce on "some" machines. Any chance you can narrow down what's different between the machines where this reproduces and where it doesn't?

Managed to reproduce on my machine as well after adjusting the Scale of text from the Display settings; this should be helpful.
From 100% to 125%.

For Windows 10:

• right Click to bring up Context menu;
• Display Settings;
• scroll to Scale and layout section;
• change to 125%

It doesn't seem to be a race condition, since the reproduction rate is 100% if the stars align. The above mentioned finding seems to help in triggering this effect and clearing it on affected machines(devices), if reducing from recommended one (125/150 %) to 100%.

Can look into if further, if this still doesn't trigger it for you.

I can still reproduce the glitch on Nightly74.0a1(20200106215403) Windows10.

*Nightly74.0a1 [en-US] build Windows10:
It need to use bigger text to reproduce the issue.
Start - Settings - Ease of Access - Display, Make text bigger to 150%.
*Nightly74.0a1 [ja] build:
The bug can be reproducible with default text size of Windows10.

STR:

1. Start Firefox and Open about:profiles
2. Click [Restart with Add-ons Disabled...] button in "Restart" pane at the top-right of the page
   --- Main browser window will disappear, and "Firefox Safe Mode" dialog will pops up
3. Click [Refresh Firefox] button in "Firefox Safe Mode" dialog
   --- "Refresh Firefox" dialog will pops up
4. Observe the glitch of "Refresh Firefox" dialog

OR

1. Open about:support
2. Click [Refresh Firefox]

Actual Results:
Bottom of buttons are cut off

Expected Results:
No glitch

Thanks. The 125% thing is key - I tried both 100% and 150% and various text sizes and those are all fine.

This is ultimately the fault of bug 1293242 but that was wontfixed, so here we are...

(In reply to :Gijs (he/him) from comment #10)

Thanks. The 125% thing is key - I tried both 100% and 150% and various text sizes and those are all fine.

I'm on 150% DPI and I can also reproduce...

Bottom of buttons are cut off

Odd, I can't reproduce with either of the settings combinations Alice posted.

In any case, I can reproduce with 125% as the DPI size... but fixing this is tricky - just calling sizeToContent() does nothing, because layout is confused about the size of the description which is wrapping.

This is basically the same technique as descriptionHeightWorkaround in the
PanelMultiView implementation (from bug 1009116).

Trypush that should have builds in an hour or so - Itiel / Alice, can you check if the issue is fixed for you on those builds when they appear? Thanks. https://treeherder.mozilla.org/#/jobs?repo=try&revision=5a22a7103080c1bf98a92ae1e8c698b461a3f0b2

(In reply to :Gijs (he/him) from comment #14)

Odd, I can't reproduce with either of the settings combinations Alice posted.

In any case, I can reproduce with 125% as the DPI size... but fixing this is tricky - just calling sizeToContent() does nothing, because layout is confused about the size of the description which is wrapping.

FWIW, it's also possible there are two separate issues here... the 125% dpi issue still reproduces when I replace all the strings with hardcoded versions and remove the fluent <link>s. So that being a regression from bug 1517307 seems impossible.

It's possible there's a fluent-related race condition that manifests on other DPI sizes on other machines that I can't reproduce because for whatever reason the timing works out differently on my machine. Either way, the attached patch should address both types of issues.

(In reply to Alice0775 White from comment #9)

I can still reproduce the glitch on Nightly74.0a1(20200106215403) Windows10.

*Nightly74.0a1 [en-US] build Windows10:
It need to use bigger text to reproduce the issue.
Start - Settings - Ease of Access - Display, Make text bigger to 150%.
*Nightly74.0a1 [ja] build:
The bug can be reproducible with default text size of Windows10.

Default system font are different between Windows10 HOME(1909) English Edition and Japanese Edition.
i.e., "Segoe UI" 9pt (English Edition) and "Yu Gothic UI" 9pt (Japanese Edition) .

I think that's why the font zoom levels are different.

The try build of comment#16 fixed this issue.

(In reply to Alice0775 White from comment #19)

The try build of comment#16 fixed this issue.

Same here.

https://hg.mozilla.org/mozilla-central/rev/b3d0b186aff5

Can confirm that with 74.0a1 (2020-01-14) - Windows 10 this particular issue is fixed.

However, I've just uncovered another scenario that causes the same issue to occur:

• changing the scale of the display with the window open causes the same issue (still).

@Gijs sorry to poke you with this, but is it something that can be patched here or do we need to open a follow up bug for it?

(In reply to Cristian Fogel, QA [:cfogel] from comment #23)

Created attachment 9120976 [details]
prScale.gif

Can confirm that with 74.0a1 (2020-01-14) - Windows 10 this particular issue is fixed.

However, I've just uncovered another scenario that causes the same issue to occur:

• changing the scale of the display with the window open causes the same issue (still).

@Gijs sorry to poke you with this, but is it something that can be patched here or do we need to open a follow up bug for it?

Please file a follow-up.

Filed bug 1609446 for this.
Thank you!

I'm not sure if this is worth uplifting on its own while we're still diagnosing bug 1609446, but feel free to nominate if you think that it is.

Comment on attachment 9119100 [details]
Bug 1600919 - work around XUL layout bug by manually measuring wrapping description element in reset profile dialog, r?MattN!,zbraniecki!

Beta/Release Uplift Approval Request

• User impact if declined: Unusable dialog
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: See comment 8 onwards
• List of other uplifts needed: nope
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): straightforward fix to work around some layout issues
• String changes made/needed: nope

(In reply to Ryan VanderMeulen [:RyanVM] from comment #26)

I'm not sure if this is worth uplifting on its own while we're still diagnosing bug 1609446, but feel free to nominate if you think that it is.

I think bug 1609446 is such an edgecase (changing windows text size while the safe mode and refresh dialogs are up) that it borders on wontfix - but it offers a clear way to reproduce an existing layout issue, whose fix would also allow us to remove the workaround we added here and in bug 1009116. So it's worth keeping the bug open but not worth delaying this fix for it.

Comment on attachment 9119100 [details]
Bug 1600919 - work around XUL layout bug by manually measuring wrapping description element in reset profile dialog, r?MattN!,zbraniecki!

Works around a XUL layout bug to avoid text getting pushed out of the visible part of the window. Approved for 73.0b8.

https://hg.mozilla.org/releases/mozilla-beta/rev/6436bededa92

Verified with 73.0b8 using the treeherder builds.
As per the note from Gijs, bug 1609446 is indeed a somewhat unlikely to happen edge-case.

Emilio, am I right in thinking we should be able to back out the hackaround I landed here when the fix from bug 1620575 lands?

I think so, yeah.