LABEL element problematic

VERIFIED FIXED in M7

Status

()

Core
Layout
P3
normal
VERIFIED FIXED
20 years ago
19 years ago

People

(Reporter: Mark Anderson, Assigned: Eric Pollmann)

Tracking

Trunk
x86
Windows 98
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: (04/09) 3jrgm@qlink.queensu.ca -- reviewed, URL)

Attachments

(2 attachments)

(Reporter)

Description

20 years ago
I know Kipp opened a bug on a similar topic, but I believe this is slightly
different....  The problem with the rendering in this case is that the LABEL
element makes the text that is the label be entirely rendered over by a big
white box.  The element didn't do this when the bug that didn't allow black
backgrounds to work correctly was unresolved, but now that that bug is long
since plugged, the element is rendering entirely incorrectly (white boxes
overwriting the text which would normally be white on the black background).

Updated

19 years ago
Assignee: troy → karnaze

Updated

19 years ago
Status: NEW → ASSIGNED

Updated

19 years ago
Whiteboard: (04/09) 3jrgm@qlink.queensu.ca -- reviewed

Comment 1

19 years ago
Pasting this test case in from bug #2736. As noted above, the LABELs for the
FORMs show up as white squares on the black background.

Example:

<html><BODY BGCOLOR="#000000" TEXT="#FFFFFF">
<FORM method=post action="whatever">
<TABLE>
 <TR>
  <TD ALIGN=LEFT><I><LABEL for="siteid">Site ID:</LABEL></I></TD>
  <TD><INPUT type="text" name="id" size=20 id="siteid" tabindex="16"></TD>
 </TR>
 <TR>
  <TD ALIGN=LEFT> </TD>
  <TD ALIGN=CENTER><INPUT type="submit" value="Edit" tabindex="18">
                   <INPUT type="reset" value="Clear" tabindex="19"></TD>
 </TR>
</TABLE>
</FORM>
</body></html>

The problem appears to be that the LABELs background is not inheriting from
the BODY (and, in this case, 'white' text on 'white' shows no text). However
if you play with the colors, you can see that the text is there, but the
background color does not inherit.

Updated

19 years ago
Target Milestone: M6

Comment 2

19 years ago
Moving to M6.

Comment 3

19 years ago
Moving to M8.
This problem is incredibly easy to fix.

Remove this line:
  http://lxr.mozilla.org/mozilla/source/layout/html/document/src/ua.css#696

i.e., remove the "background-color: white;" declaration for the LABEL element
in the ua.css file.
*** Bug 6151 has been marked as a duplicate of this bug. ***

Updated

19 years ago
Assignee: karnaze → pollmann
Status: ASSIGNED → NEW

Comment 6

19 years ago
Reassigning to Eric.
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 7

19 years ago
Created attachment 374 [details]
Minimized Test Case
(Assignee)

Comment 8

19 years ago
I just tested py8ieh's fix to the bug and can confirm that it is both simple and
effective.  Unfortunately, it has the unintended side-effect of making the
labels in Example 8 look "smeared" when the page is scrolled.

I also tried setting the playing with the display: value (no effect) and setting
background-color to "inherit" but this had the same effect as not specifying it.

Chris, according to cvsblame, you added the line "background-color: white" to
ua.css.  Is there a way to achieve the "opaqueness" this line gives, but let the
color inherit from the parent?
(Assignee)

Comment 9

19 years ago
Created attachment 376 [details] [diff] [review]
Proposed fix
(Assignee)

Comment 10

19 years ago
Ah, it seems we weren't telling the view system that the label view has some
'transparent' pixels in it.  I added this to nsLabelFrame's Reflow method
immediately after the view is initialized:

      view->SetContentTransparency(PR_TRUE);

When done in addition to py8ieh's change to ua.css, the label element inherits
the background color properly, and repaints properly as well.  Chris, I'm not
100% familiar with this code.  Is this a reasonable fix?

Comment 11

19 years ago
Your fix is probably ok, but I'm CCing Peter just to make sure.

Comment 12

19 years ago
Sounds good to me. The label should nit have a background unless the author
gives it one.
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 13

19 years ago
Just checked in a fix.

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 14

19 years ago
Fixed in the June 14th Build.
(Assignee)

Comment 15

19 years ago
*** Bug 7779 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.