The default background colors for most widgets except buttons are very dark. It would be nice if the widget library could set them to reasonable defaults and possibly even get the settings from the operating system. This can be tested by uncommenting the code in forms\nsFormControlFrame::SetColors and switching to Standard mode in the viewer upon viewing test8.

Last I heard, peterl was hooking up CSS2 System Colors, which would let you set the colors for these correctly in ua.css in a way that's consistent with the OS.

Setting all current Open/Normal to M4.

per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

Peter I'm assigning this bug to you. You can assign it back to me when the CSS2 System color property values are available.

Moving all Widget Set bugs, past and present, to new HTML Form Controls component per request from karnaze. Widget Set component will be retired shortly.

CSS system colors in place, now needs nsILookAndFeel support.

Peter, This is what I sent you mail on a few days ago. This now works on Windows and needs to be implemented on Mac and GTK.

reassigning to pavlov to do on linux, cc'ing pink to implement on Mac. Please leave this bug open until it is done on both

done on linux, reassigning to pink for mac work

accepting

first stab checked in. i will open a new bug to get the colors correct via appearance manager.

Just happened to look at this bug. Just wanted to note that the status probably should be "resolved" instead of "new"? At least the combination of "new" and "fixed" is strange.

changed to M14

this is a test

changing to M15

This bug is similar to bug 16729. Reassigned to ben. CCd Sherry Wang <xiaotong@us.ibm.com> who volunteered to do the work.

Really reassigning to ben.

*** Bug 22620 has been marked as a duplicate of this bug. ***

Move to M16 for now ...

non-essential skin work. shifting off.

Remark: one of the things on our plate is a 4.x classic theme, that will attempt to take advantage of system colors and fonts like 4.x did. There is a variety of bugs on all three system properties that can be used in CSS2 (colors, fonts and the third one escapes me...) so its coming. Varying or user set often do not work well with design skins with the author will create and rely on certain color combination, thus the advice is (see also" Cascading Style Sheets" by Bos/Li, Adison-Wesley) to either do a fully systm compliant design or to do a fully custom designed one, but to not mix from either.

Basics appear to be in place on Linux and Windows; changing platform, OS to Mac.

Based on comments, the CSS system colours code is in, and now we just need to change html.css. Luckily enough, that is exactly what I am doing now. Taking bug. This will not fully work on the mac until bug 1004 is fixed.

almost done

PDT believes that enough of this feature is implemented to make classic skin work, and we're therefore marking this bug nsbeta3-.

This has nothing to do with classic skin. This is an html.css fix which I have almost completed (I am merely waiting for the CSS pseudos renaming to finish). Reinstating [nsbeta3+] per Eric Krock's request that I plus all bugs that I would have time to do by the nsbeta3 deadline.

per PDT team. At this time, PDT marking priority to P5. If you believe this to be a P1 priority, please let us know how this fits into the P1 criteria. Bug was marked nsbeta3- by PDT team earlier. We are sorry to see that it be suggested by ekrock for this to be a nsbeta3 merely due to having time to fix. Normally, if a person doesn't have any more nsbeta3+ bugs to fix, s/he should help out the team with other nsbeta3+ bugs. Thanks.

Since I'm getting lectured by the PDT team in print here ;-> ... for the record, to clarify, I have never given anyone a blanket instruction to "nsbeta3+ all bugs they have time to fix, irrespective of severity." Rather, during the nsbeta3 timeframe, authority to + or - bugs was passed down to the first-line engineers and their managers. During triage, I noticed that dbaron and ianh had open nsbeta3 nominees whose status had not been assigned, so, per PDT team instructions to resolve the status of outstanding nsbeta3 nominees that had not been nominated, I asked them (just like the other first-line engineers) to indicate which bugs currently assigned to them they were going to fix by the nsbeta3 deadline, and to minus or reassign the others, so their status would be resolved. This is what Ian was referring to. Let's not convict the innocent on terse hearsay please ... ;->

While we're at it, I should possibly point out that since I'm a QA person doing this in addition to all the other QA work, and that I don't know C++, there is no way I could have "helped out the team with other nsbeta3+ bugs". This is effectively a free fix, guys! Quit complaining! :-)

Ian, there isn't free work late in a product cycle. Perceived risk becomes a dominant factor. That's what's going on here with pdt intervention. Not resetting priority, for once, PDT weighed in earlier on its assessment.

*** Bug 53483 has been marked as a duplicate of this bug. ***

marking fixed because i think ian's *.css changes fixed this...please do reopen if I'm mistaken.

blake: You should never set the resolution to FIXED unless _you fixed it_. FIXED. Please verify by checking on at least five platforms as this is a very platform-sensitive change.

cc: gerardok. ckritzer is on sabbatical and can't verify this bug. We should get this verified soon, if possible.

Updating QA contact.

Build: 2000092711 MN6 Platform: WinNT Verified by loading the test8 file under sample directory.

reopening and remarking fixed (and spamming people who will hate me forever in the process). Please read Ian's comment: "Please verify by checking on at least five platforms as this is a very platform-sensitive change."

..and remarking fixed! (please direct spam complaints to nobody@mozilla.org, my secretary)

[Thanks Blake.] To check this you need to: 1. Change your system font 2. Change your system colours 3. Check that widgets in Mozilla are using these new settings 4. Repeat this for edge cases This needs to be done, as I said, on at least five platforms since this issue is known to have so many hidden dependencies and is very OS sensitive. Things to look out for: Are the inset/outset borders on radio buttons correct? Is the page background correct? Are text fields getting the correct background colour? Are fonts the right size, not too big and not smaller than the OS?

asa - can we get some folks on mozilla.org to help verify this also? It sounds like the changes are fairly sensitive and there may be hidden problems waiting to be uncovered.

Verifying Win 98 build 2001-02-06-04-Mtest Linux RedHat build 2001-02-06-08-Mtest and MacOS 8.x build 2001-02-06-08-Mtest