Two corrections and one identification, all from the colour probe, which gives every system colour a unique bright value and prints the name beside it. Reset, Apply, Cancel one probe colour OK ANOTHER, #E87F9D, and the log names it exactly cider-wayland-color name=alternateSelectedControlTextColor probe=0.9067,0.5,0.6167 232/255, 127/255, 157/255. An exact match, and nothing else in the run is close. FIRST CORRECTION: THE LABEL IS DRAWN ON TOP OF OUR BEZEL, not underneath it. In the probe run it is plainly visible over the white bezel. An earlier commit said the half alpha probe had settled that it was underneath. It had not: half alpha cannot tell white text under a white bezel from white text on top of one, because it comes out white either way, and I read it as proof. SECOND CORRECTION: in the Options dialog the button region has no pixels that differ from the bezel, which I took to mean nothing was drawn there. It is drawn, in a colour that is white in the real palette. The three buttons beside it use controlTextColor and are perfectly visible. WHY THIS IS NOT A ONE LINE FIX. alternateSelectedControlTextColor is white on macOS and correctly white here: it is the text colour for an emphasised background. LibreOffice uses it for DEFAULT BUTTON text and expects that button to be filled with the accent colour, which on macOS happens because AppKit knows which cell is the window default button. LibreOffice tells us nothing: all four buttons arrive with identical cell state, no title, no key equivalent, no view, state 0, and only their widths differ. There is no signal to key on and inventing one would be a guess dressed as a fix, so this stays open with the cause named rather than closed with a heuristic. docs/wayland-default-button-colour-probe.png is the picture that names it.