Closed Bug 1021 Opened 26 years ago Closed 24 years ago

[html.css] Widgets should use CSS2 system colors (and fonts)

Categories

(Core :: Layout: Form Controls, defect, P1)

Product:
Core
Component:
Layout: Form Controls
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: karnaze, Assigned: ian)

References

Details

(Keywords: platform-parity, Whiteboard: [nsbeta3+][PDTP5]) 

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.
Status: NEW → ASSIGNED
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
Summary: widgets have funny looking default backgroud colors → widgets have funny looking default backgroud colors
Target Milestone: M4 → M5
Target Milestone: M5 → M7
Summary: widgets have funny looking default backgroud colors → widgets have funny looking default background colors
Assignee: kmcclusk → peterl
Status: ASSIGNED → NEW
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.
Target Milestone: M9 → M10
Depends on: 1004
Assignee: peterl → rods
Status: ASSIGNED → NEW
CSS system colors in place, now needs nsILookAndFeel support.
Assignee: rods → trudelle
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.
Assignee: trudelle → pavlov
Target Milestone: M10 → M11
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
Assignee: pavlov → pinkerton
done on linux, reassigning to pink for mac work
Blocks: 1763
No longer blocks: 1763
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
first stab checked in. i will open a new bug to get the colors correct via
appearance manager.
No longer depends on: 1004
Blocks: 1004
No longer blocks: 1004
Status: RESOLVED → REOPENED
Summary: widgets have funny looking default background colors → Widgets should get colours from CSS2
Assignee: pinkerton → rods
Status: REOPENED → NEW
Depends on: 1004
Summary: Widgets should get colours from CSS2 → Widgets should use CSS2 system colors
Resolution: FIXED → ---
Severity: normal → minor
OS: Windows NT → All
Priority: P2 → P3
Hardware: PC → All
Target Milestone: M11 → M12
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.
Target Milestone: M12 → M14
changed to M14
Assignee: ckritzer → rods
QA Contact: phillip → ckritzer
Depends on: 24224
this is a test

changing to M15
Target Milestone: M14 → 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.
Assignee: rods → ben
*** Bug 22620 has been marked as a duplicate of this bug. ***
Move to M16 for now ...
Target Milestone: M15 → M16
non-essential skin work. shifting off.
Status: NEW → ASSIGNED
Target Milestone: M16 → M30
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.
Keywords: pp
OS: All → Mac System 9.0
Hardware: All → Macintosh
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.
Assignee: ben → py8ieh=bugzilla
Status: ASSIGNED → NEW
Keywords: nsbeta3
OS: Mac System 9.0 → All
Priority: P3 → P1
Hardware: Macintosh → All
Summary: Widgets should use CSS2 system colors → Widgets should use CSS2 system colors [html.css]
Target Milestone: M30 → M18
Depends on: 49922
No longer depends on: 49922
Status: NEW → ASSIGNED
Severity: minor → normal
almost done
Whiteboard: [nsbeta3+]
PDT believes that enough of this feature is implemented to make classic skin
work, and we're therefore marking this bug nsbeta3-.
Whiteboard: [nsbeta3+] → [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.
Whiteboard: [nsbeta3-] → [nsbeta3+]
Depends on: 3935
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.
Priority: P1 → P5
Whiteboard: [nsbeta3+] → [nsbeta3+][PDTP5]
No longer depends on: 3935
Blocks: 6625
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! :-)
Priority: P5 → P1
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.
Summary: Widgets should use CSS2 system colors [html.css] → [html.css] Widgets should use CSS2 system colors (and fonts)
*** 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.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
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.
QA Contact: ckritzer → bsharma
Build: 2000092711 MN6
Platform: WinNT

Verified by loading the test8 file under sample directory.
Status: RESOLVED → VERIFIED
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."
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
..and remarking fixed!

(please direct spam complaints to nobody@mozilla.org, my secretary)
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
[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
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.