The previous commit says LibreOffice gives no way to tell which button is the default, that all four arrive with identical cell state, and that inventing a rule would be a guess. That was wrong, and the reason is the fourth instrument failure of this session. Two traced lines were identical in every visible character and still did not collapse under uniq: ... defaulted=0 key=^M frame=93x20+0+0 the default button ... defaulted=0 key= frame=93x20+0+0 the others A CARRIAGE RETURN in the key equivalent. The log printed the string raw and a control character does not show, it moves the cursor. A signal present in every run of this hunt was read as its own absence, and I wrote that absence into a commit message. The return key is the macOS convention for the default button and LibreOffice follows it. drawBezelWithFrame now asks the window OR the key equivalent, which needs no view at all, and the default bezel is filled with the accent colour instead of a white box inside a black ring, which was a much older macOS. White label on accent blue is exactly what LibreOffice expects, since it draws that label in alternateSelectedControlTextColor. keychar=13 twice, keychar=0 forty two times, in one Options dialog VERIFIED IN THREE DIALOGS, all looked at rather than counted. Options: Reset, Apply and Cancel white with dark labels, OK blue with a white one. The print alert: a blue OK that can be read for the first time. The save panel: a blue Save beside a white Cancel, and it still writes the file, cider-typed-name.odt at 9699 bytes. Zero unrecognized selectors in every run. The trace prints the key equivalent as a character CODE now, so it cannot hide again. A probe that renders a control character raw can conceal the very thing it was added to find.