Bound the size of an alert that carries a formatted message - #2836

UIFacadeImpl.showOptionDialog knows two message formats besides plain text, HTML_MESSAGE_FORMAT and MARKDOWN_MESSAGE_FORMAT (UIFacade.java:82-83). Both take a different route from plain text: instead of setContentText they put a MarkdownView straight into the dialog pane (UIFacadeImpl.java:302-309).

A MarkdownView is a VBox, and a VBox asks for as much width as its widest child needs. DialogPane in turn takes the preferred size of its content as its own. Nothing bounds either dimension, so a long message makes the dialog as wide as the screen and taller than the screen, and the buttons go with it.

Measured on a 1024x768 screen with a 2611 character HTML message, an error list of the kind a failing document reader would produce:

STAGE   x=0 y=63  W=1024 H=519
PANE    W=1024 H=826  prefW=1633
CONTENT MarkdownView W=1024 H=710  prefW=1633  prefH=1655
BUTTON "Restore" x=737..824 y=853..879   on screen = NO
BUTTON "Skip"    x=833..918 y=854..879   on screen = NO
BUTTON "Cancel"  x=928..1013 y=854..879  on screen = NO

The dialog pane asks for 1633px of width, is clamped to the screen, and all three buttons sit at y=853..879 — below the bottom edge of a 768px screen. The dialog can then only be dismissed with Escape, which picks the cancel action whatever the user meant. The text is cut off as well: the message is 710px tall inside a 519px window.

What this changes

The formatted message goes into a scroll pane that bounds the preferred size in both directions:

• width at MAX_CONTENT_WIDTH = 720, twice the 360px that DialogPane.createContentLabel hard-codes for a plain text message. A formatted message may carry tables and code blocks that do not wrap, so it gets more room than plain text, but not the whole screen. It is a fixed number and not a share of the screen, because how wide a column may be before it becomes hard to read does not depend on the monitor.
• height at 60% of the screen height. This one does depend on the monitor: what is left over has to hold the header and the buttons.

The bounds sit on the preferred size and not on the maximum, because the preferred size is the only one DialogPane ever asks the content for.

The same message now measures:

STAGE   x=152 y=56  W=720 H=541
PANE    W=720 H=541  prefW=720
CONTENT W=720 H=425
SCROLL  content 995px in a 403px viewport, scrollable = YES
BUTTON "Restore" x=585..672 y=561..587  on screen = YES
BUTTON "Skip"    x=681..766 y=562..587  on screen = YES
BUTTON "Cancel"  x=776..861 y=562..587  on screen = YES

A short message is untouched

This is the part worth checking, because a width correction of this kind can quietly change every dialog in the application.

HTML_MESSAGE_FORMAT has exactly one call site today, HelpMenu.java:153, the question that offers to restore an autosaved document. MARKDOWN_MESSAGE_FORMAT has none. That one message must keep the dialog it has, and it does:

A screenshot of the two dialogs differs in 0 of 93296 pixels.

The reason it survives is worth stating, because the obvious version of this change does not: modena gives a ScrollPane the same 0.833em of padding it gives the content of a DialogPane. Zeroing the scroll pane's padding — which looks like the tidy thing to do — makes every short formatted dialog 22px narrower. Leaving the padding alone puts the text back on the pixel it was on.

Only -fx-background-color is cleared, which takes modena's border and background box with it. -fx-background is deliberately not touched: modena derives the text colour from it through -fx-text-background-color: ladder(-fx-background, ...), so setting it to transparent turns every label inside the scroll pane white on white.

Tests

AlertContentSizeTest, four cases:

• a long message does not stretch the dialog sideways
• a long message does not stretch the dialog past the screen
• a long message keeps growing behind a scroll bar (four times the text gives the same height)
• a short message keeps the dialog it had — the guard, which compares against a bare MarkdownView built the way the code built it before

All four were run against the unfixed code first. The three defect cases fail there and the guard passes, which is what a guard is for. The guard was then made to fail on purpose by tightening the width bound to 200px, to check it can fail at all.

Whole suite: 375 tests before, 382 after, 0 failures.

Note on #2833

#2833 does the matching thing for the plain text branch of the same method. The two touch different branches of the same if, so they do not conflict in behaviour, but they share one line: MAX_CONTENT_HEIGHT_RATIO = 0.6. Whichever lands second should drop that one declaration and use the other's. This PR stands on its own against master and does not depend on #2833.