All users were logged out of Bugzilla on October 13th, 2018

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

VERIFIED FIXED in M18

Status

()

P1
normal
VERIFIED FIXED
20 years ago
7 years ago

People

(Reporter: karnaze, Assigned: ian)

Tracking

({platform-parity})

Trunk
platform-parity
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta3+][PDTP5])

(Reporter)

Description

20 years ago
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.

Updated

20 years ago
Status: NEW → ASSIGNED

Comment 1

20 years ago
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.

Comment 2

20 years ago
Setting all current Open/Normal to M4.

Comment 3

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

Updated

20 years ago
Summary: widgets have funny looking default backgroud colors → widgets have funny looking default backgroud colors
Target Milestone: M4 → M5

Updated

20 years ago
Target Milestone: M5 → M7

Updated

20 years ago
Summary: widgets have funny looking default backgroud colors → widgets have funny looking default background colors

Updated

20 years ago
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.

Comment 5

20 years ago
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.

Updated

20 years ago
Target Milestone: M9 → M10

Updated

19 years ago
Depends on: 1004

Updated

19 years ago
Assignee: peterl → rods
Status: ASSIGNED → NEW

Comment 6

19 years ago
CSS system colors in place, now needs nsILookAndFeel support.

Updated

19 years ago
Assignee: rods → trudelle

Comment 7

19 years ago
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.

Updated

19 years ago
Assignee: trudelle → pavlov
Target Milestone: M10 → M11

Comment 8

19 years ago
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

Updated

19 years ago
Assignee: pavlov → pinkerton

Comment 9

19 years ago
done on linux, reassigning to pink for mac work

Updated

19 years ago
Blocks: 1763

Updated

19 years ago
No longer blocks: 1763
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
first stab checked in. i will open a new bug to get the colors correct via
appearance manager.

Updated

19 years ago
No longer depends on: 1004

Updated

19 years ago
Blocks: 1004

Updated

19 years ago
No longer blocks: 1004
Status: RESOLVED → REOPENED
Summary: widgets have funny looking default background colors → Widgets should get colours from CSS2

Updated

19 years ago
Assignee: pinkerton → rods
Status: REOPENED → NEW
Depends on: 1004
Summary: Widgets should get colours from CSS2 → Widgets should use CSS2 system colors

Updated

19 years ago
Resolution: FIXED → ---

Updated

19 years ago
Severity: normal → minor
OS: Windows NT → All
Priority: P2 → P3
Hardware: PC → All

Updated

19 years ago
Target Milestone: M11 → M12

Comment 12

19 years ago
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.

Updated

19 years ago
Target Milestone: M12 → M14

Comment 13

19 years ago
changed to M14

Updated

19 years ago
Assignee: ckritzer → rods
QA Contact: phillip → ckritzer

Updated

19 years ago
Depends on: 24224

Comment 14

19 years ago
this is a test

Comment 15

19 years ago
changing to M15
Target Milestone: M14 → M15

Comment 16

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

Comment 17

19 years ago
Really reassigning to ben.
Assignee: rods → ben
*** Bug 22620 has been marked as a duplicate of this bug. ***

Comment 19

19 years ago
Move to M16 for now ...
Target Milestone: M15 → M16
non-essential skin work. shifting off. 
Status: NEW → ASSIGNED
Target Milestone: M16 → M30

Comment 21

19 years ago
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.

Comment 22

19 years ago
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
(Assignee)

Comment 23

18 years ago
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
(Assignee)

Updated

18 years ago
Depends on: 49922
(Assignee)

Updated

18 years ago
No longer depends on: 49922
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
(Assignee)

Updated

18 years ago
Severity: minor → normal
(Assignee)

Comment 24

18 years ago
almost done
Whiteboard: [nsbeta3+]

Comment 25

18 years ago
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-]
(Assignee)

Comment 26

18 years ago
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+]
(Assignee)

Updated

18 years ago
Depends on: 3935

Comment 27

18 years ago
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]
(Assignee)

Updated

18 years ago
No longer depends on: 3935
(Assignee)

Updated

18 years ago
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 ... ;->
(Assignee)

Comment 29

18 years ago
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

Comment 30

18 years ago
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.
(Assignee)

Updated

18 years ago
Summary: Widgets should use CSS2 system colors [html.css] → [html.css] Widgets should use CSS2 system colors (and fonts)

Comment 31

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

Comment 32

18 years ago
marking fixed because i think ian's *.css changes fixed this...please do reopen 
if I'm mistaken.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago18 years ago
Resolution: --- → FIXED
(Assignee)

Comment 33

18 years ago
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.

Comment 34

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

Comment 35

18 years ago
Updating QA contact.
QA Contact: ckritzer → bsharma

Comment 36

18 years ago
Build: 2000092711 MN6
Platform: WinNT

Verified by loading the test8 file under sample directory.
Status: RESOLVED → VERIFIED

Comment 37

18 years ago
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 → ---

Comment 38

18 years ago
..and remarking fixed!

(please direct spam complaints to nobody@mozilla.org, my secretary)
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED
(Assignee)

Comment 39

18 years ago
[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?

Comment 40

18 years ago
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.

Comment 41

18 years ago
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.