Test case: 1. Start Composer 2. Click on HLine toolbar button to insert a horizontal line 3. Click on the HR, then on the toolbar button again to show its properties There are 3 radio buttons for alignment. Click on another button, and note that the initial state ("Left" by default) is not shown as unchecked. The "checked" state seems to be set correctly, it seems to be a display issue for the "Left" button not clearing it's state.

I don't think it's fully a display issue -- if I initially click on the Left radio button, and then on the Center button, the Left is cleared when the Center is clicked (i.e., behaviour is normal if the Left button is manually "initialized"). ben currently has an RFE on himself to reimplement radio buttons (radiogroup) in XUL -- ben, do you know what this bug is about. By the way, though, I noticed that 'globalElement.getAttribute('align')' in EdHLineProps.js is getting "Left" for a value, but then comparing it to "left"|"right"|"center" for setting the value of the .checked attribute.

cc: ben -- ben currently has an RFE on himself to reimplement radio buttons (radiogroup) in XUL -- ben is there an open bug for this type of behaviour known to you right now?

reassigning to ben to cover that work or close as dup.

I am seeing similar problems in the image dialog (though only 2 radio buttons in that set). I also seem to be having some problems with the corresponding js. I had to rewrite it to default in a broken but better way but I really would like to clean up the JS. Right now there are bugs that I can't do a simple "if (radiobutton.checked)" query. If I click the radio buttons enough times (twice each?) then the JS executes as expected. I'm hoping this is related to the initial click problem and that there is an easy fix for it.

I wouldn't rewrite any XUL or JS to hide this bug. It must be fixed. Adding nsbeta2 to raise attention on the issue.

Putting on [nsbeta2+] radar for beta2 fix.

This is fixed by the new <radio> XBL/js on mac/win32/linux, I do believe. If there are still problems (I can't quite tell from the previous comments) then please reopen this bug or, better, file a new one for the remaining problem. I do note though that there are new bugs in these dialogs: 1) in the HR dialog, the "Width:" textfield overwrites the units menulist to the right of it (and this is not just visual ... you can actually type over the menulist with the textfield characters). (mac/win32/linux) 2) in the image dialog, when you click "more properties" the radio buttons in that dialog are initially displayed in a 'disabled' state. As soon as click to give focus to the titledbox that the <radio> are contained in, they switch to 'not disabled' state. (mac/win32/linux) Filing bugs on, sigh, these points now.

verified fixed