As the URL points out, there don't seem to be any guidelines for placement / arrangement of common dialog buttons, such as OK / Cancel, Yes / No (not that they are a good idea, but that's another problem) and Help. That, or developers do not care about them (in that case, this bug is WFM, of course). The first image in the blog entry shows a dialog that has a confirmation question to be answered; the more likely answer is "OK, do log me out", whereas the less likely answer is "Cancel, it was a mistake". Though "Log out" would be a better label for the OK button (it makes reading the question redundant for many cases, and people are lazy and *don't* want to read the question), apart from that, this dialog is fine. The second image is a lot worse. Only the advanced users can understand the contents of a certicifacte, so the "View Certificate" button shouldn't be as large as the others. Because many, many sites get certificates wrong, "OK, continue anyway" is rightly the default option. But it isn't that obvious what it does. Without reading the small print, the user might think it really means "OK, I'm having bad luck then. Thanks for informing me." So just label it "Continue anyway". And reverse the arrangement and alignment. The "Continue anyway" button should be to the very right. It should attract the user's eye the very first. In reality, most don't care about certificates anyway. Put "Cancel" directly to the left of it, and then Help (e.g. reverse the order, as said above). This dialog is just an example though; I'm sure there are lots. I believe the Preferences dialog, the Cookie Manager, and lots of other strange stuff suffer from this. AFAIK, UI research has proved the most likely option should be in the bottom right, which is why the first dialog is (apart from the unclear labeling) the right solution. Even if you were to decide for the opposite solution, offer consistence. It helps a lot.

Dialogs should be using <dialog>, which automatically does correct placement of buttons, following the platform guidelines. This provides the desired unified arrangement of dialog buttons. This does not mean some people don't try to reinvent the wheel. Dialogs not using <dialog> (like that security) UI should have bugs filed, one per dialog, to stop using <window> and use <dialog> like they're supposed to. Over to PSM, since that's who the UI in question belongs to; please file separate bugs on other instances of the problem the you encounter....

"Dialogs should be using <dialog>, which automatically does correct placement of buttons, following the platform guidelines. This provides the desired unified arrangement of dialog buttons." That's great and exactly what I wanted. Thanks. "This does not mean some people don't try to reinvent the wheel. Dialogs not using <dialog> (like that security) UI should have bugs filed, one per dialog, to stop using <window> and use <dialog> like they're supposed to." I'll keep digging.

Mass reassign ssaux bugs to nobody

Fixed via bug 251991.