Build: 2001030804, Windows Terminal Server To reproduce: * Start Mozilla, and switch to the Classic theme if you are not already using it. * Open the Preferences dialog. * Switch to the `Navigator' panel. * Look at the checkboxes in the `Select the buttons that you want to see in the toolbars.' listbox. What you see: * Checkboxes the same as they appear everywhere else in the chrome -- an inset bevelled square. What you should see: * Checkboxes appearing as an unbevelled gray outline.

I'm not sure why the bevelled look of the checkboxes is a bug. That is the way all checkboxes look in Windows. Native win32 checkboxes are not unbevelled gray outlines. Give me a reason not to mark this invalid :)

There are three ways in which you can convince yourself that this bug is valid. In decreasing order of difficulty, they are as follows. Firstly, imagine yourself as a blowfly walking across the monitor, and imagine that the 3-D affordances in the Windows UI are real dips and raises in the terrain, which you have to climb onto or into. Notice that checkboxes or radio buttons within listboxes, in Mozilla, are inconsistent in being the only controls in any dialog which go two steps down from `sea level' -- a pit within a pit. Giving the checkboxes and radio buttons a flat appearance in this situation avoids this inconsistency. Secondly, look yourself at a Microsoft app which uses checkboxes or radio buttons within listboxes -- for example, the `Advanced' tab of the `Internet Options' control panel. Note that the checkboxes and radio buttons usually have a flat appearance. (The `Compatibility' tab of Word 2000's Options dialog seems to be an exception, but that might be just because I'm running it on NT 4.0.) Thirdly, and most easily, read the last section of the URL of the Microsoft UI guidelines which I thoughtfully provided when filing the bug, viz.: | | Flat Appearance | | When you use controls such as check boxes and option buttons in a list box | control, you should use the control's flat (as opposed to three-dimensional) | appearance, as shown in Figure 14.22. I trust this is adequate explanation. :-)

This seems like it can go either way, though. One hand, Microsoft has guidelines that say to use flat checkboxes within listboxes. The other hand, they don't follow this convention themselves in all their own apps (Word 97 also has 3D checkboxes within listboxes). Finally, Whistler's interface seems to change a LOT of things in the UI, right up to whether most controls look 3D at all.

if you just look at windows 2000 control panels you'll see that most checkboxes in listboxes are flat (i can't think of an exception to this :) ...) mpt: could you cc me (timeless@bemail.org) for ts related bugs? hewitt we can let you browse to see for yourself.

I apologize, I skimmed over this bug too quickly and didn't process the word "listboxes" in the subject. You're right, they should be flat in that case.

giving to shuehan

The description isn't up to date any more because the listbox was replaced by a group box. To see the bug try following: - Open Preferences dialog - Go to Advanced -> Scripts & Plugins - Look at the listbox called "Allow scripts to:"

This patch only addresses checkboxes (there are no radio buttons defined in listbox.css).

Comment on attachment 131522 [details] [diff] [review] Patch Seems to me that you need to find out if XP themes affect listbox checkboxes; also I'm not sure that ThreeDShadow would be the correct colour anyway.

So it seems this bug applies to Windows versions 2000 and earlier. (Microsoft don't have UI guidelines for Windows XP.)

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

Comment on attachment 131522 [details] [diff] [review] Patch This file doesn't exist in current chrome any more, so the review request is bogus.

The comments dispute the relevance of this bug, and hasn't been a meaningful comment in years, so I'm setting it to INCOMPLETE. Please file a new bug on toolkit if there's still an issue here.