Chrome Version       : 63ish

This is hard to describe. So here's a "picture": Consider,


 Dialog Title
 
 This is a long multiline string. It
 would normally wrap like this except,
 in this locale, the button row came
 out really long. However the *height*
 of this label is determined first. So
 it will always have 6 lines of height.

 |Something a lot longer than OK| |Cancel might be changed too|



tl'dr. The result we end up with is:


 Dialog Title

 [empty space]
 This is a long multiline string. It would normally wrap like
 this except, in this locale, the button row came out really
 long. However the *height* of this label is determined first.
 So it will always have 6 lines of height.
 [empty space]

 |Something a lot longer than OK| |Cancel might be changed too|



The width of the dialog is predominantly determined by a function of 
 - std::max(button_row_width, kPreferredTextWidth); or
 - std::max(button_row_width, gfx::Font::GetExpectedTextWidth(kLocalizedTextLength));


(aside: kLocalizedTextLength *can* be localized, but I don't think it ever is..).

Note that specifying 0 doesn't work. Some concept of "width" needs to be fed into the message string _first_, otherwise it tries to put the string entirely on one line.

The problem with all of these approaches is that the label needs to first be "locked in" to report a correct GetPreferredSize. DialogClientView never asks the "real" ClientView for its GetHeightForWidth(..) once it has determined how wide the button row needs to be. Likewise, BubbleFrameView never asks for a new bounds/height once it has determined the real bubble width in GetFrameWidthForClientWidth().



I suspect the realistic fix for this is to say "Buttons should never have really long labels". Under any locale. If they do, currently the dialog gets extra vertical white space, but it's not a disaster. (Also keeping labels "short" gets harder with increased font sizes).


With dialog width snapping for Harmony, this problem is now more likely to manifest, since a wide button row will now be "rounded up" to the next largest dialog width, increasing the chance that re-wrapping the text will lose a line (or more).

Width-snapping also means that approaches like using width=Font::GetExpectedTextWidth(something-larger-if-a-dialog-has-long-button-labels) are rarely suitable. Because
 a) Ensuring "most cases" get the dialog width UX want becomes less likely, since it may bump up into a larger width
 b) Width-snapping becomes *guaranteed*. I.e., it always must increase. Which has repercussions for this specific Issue.


For an algorithmic fix... Maybe we need to feed some kind of "preferred" width into views::Label, or a LayoutManager, and perhaps plumb it all the way into into View::GetPreferredWidth() (or adopt a convention that a zero-height returned by CalculatePreferredSize, means "always consult GetHeightForWidth()").

Alternatively, perhaps allowing the ClientView to participate directly in calculations like BubbleFrameView::GetFrameWidthForClientWidth().

And really it would be nice to avoid a "fix" that makes writing specific dialogs more complicated (i.e. requiring each dialog to do more than just set a LayoutManager and preferred width).


For now, I think it's just important to avoid relying heavily on the width-snapping for dialogs with multiline text. Worded as a guideline, we could say,

"The width of a dialog should always be predominantly determined by WidgetDelegate::GetContentsView()->GetPreferredSize().width(). If width-snapping or the button row causes the contents view to get a different width it's probably a bug. The width may need to be locale-specific when button label widths are long vary significantly." Under harmony, this width should be 288, 416 or 480.


This guideline doesn't really cater for large font sizes. That's when Font::GetExpectedTextWidth() was more useful. A "guide" width that we use for all dialogs to determine which of 288, 416 or 480 should be chosen for {small, medium, large} dialogs might be the way to resolve this.
 

Deleted: bulgarian_16pt_no_button.png 75.2 KB

	bulgarian_16pt_no_button.png 75.2 KB View Download

Deleted: bulgarian_16pt_with_button.png 92.0 KB

	bulgarian_16pt_with_button.png 92.0 KB View Download