GetThemeMetric answered ZERO and an error for every metric it was ever asked. That reads like a harmless stub and it is not: a caller that ignores the status lays its control out at nothing. LibreOffice asks for exactly ONE metric, kThemeMetricPushButtonHeight, three times per print alert: CIDER_BUTTON bezel=1 bordered=1 title= frame=93x0+0+0 before CIDER_BUTTON bezel=1 bordered=1 title= frame=93x20+0+0 after The table answers the documented Aqua values for the metrics worth standing behind and keeps the old fallback for everything else, so a caller asking for something outside it still uses its own idea rather than a number invented here. Found by turning on the theme trace and reading what was actually asked: one metric, three times, and the answer was zero. A SECOND FIX IN THE SAME AREA THAT DID NOT MOVE THIS SYMPTOM, said plainly because it would be easy to imply otherwise: cellSize on NSButtonCell adds up the title and the image, so a bordered button with NEITHER measures zero high. Wrong on its own terms, fixed with the floors NSPopUpButtonCell already uses for the same three control sizes. LibreOffice does not ask the cell for that height, it asks the theme, so the button stayed 93x0 until the metric changed. STILL WRONG AND NOT CLAIMED: the label reads OK in near white on a near white bezel. On Apple systems the DEFAULT button is filled with the accent colour and its text is white, which is why LibreOffice draws it white. Our bezel is not blue, and the cell cannot currently tell that it is the default button: the only signal cocotron has is the window default button cell, and LibreOffice draws with no view at all. docs/wayland-print-alert-button.png shows the state as it is.