Input elements not painted when in a SPAN with background-color set

RESOLVED FIXED in mozilla1.0

Status

()

defect
P2
normal
RESOLVED FIXED
18 years ago
17 years ago

People

(Reporter: rzach, Assigned: dbaron)

Tracking

Trunk
mozilla1.0
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments)

Reporter

Description

18 years ago
INPUT elements don't get painted if enclosed in a SPAN which has its
background-color set.  It seems they get painted beneath the background of the SPAN.

I'll attach a testcase.

This breaks a major function of WebCT, a web-based course management system, and
is cited as one of the reasons they currently don't support Mozilla (see
http://www.webct.com/>)

Win 2000, 20011027 build, but also observed with recent Linux builds.
Reporter

Comment 1

18 years ago
Posted file Testcase โ€”
ccing rods.  This seems like a form controls problem...
Status: NEW → ASSIGNED
Component: Style System → HTML Form Controls
Priority: -- → P2
Target Milestone: --- → mozilla0.9.6
We should check if other controls (combobox, list, file, button, etc.) have this
problem...

Comment 5

18 years ago
Looks right r=rods (I know selects don't have the same problem)

Comment 6

18 years ago
Sure, sr=waterson.

Why doesn't nsLeafFrame::Paint() just call nsFrame::Paint() itself?

Also, you're inconsistent with constants on the LHS of equality tests (e.g.,
|aWhichLayet == BLAH| vs. |NS_OK == rv|), which is surprising for you, dbaron. ;-)
I converted my |NS_OK == rv| to |NS_SUCCEEDED(rv)| and filed bug 108310 on the
bogus nsresult return values in GetFrameForPoint and bug 108311 on the weirdness
in nsLeafFrame::Paint.
Fix checked in 2001-11-02 22:23 PDT.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 9

18 years ago
verified fixed on
win2000 buildID: 2001-11-08-06-trunk
macOS9.1 buildID: 2001-11-08-08-trunk
Status: RESOLVED → VERIFIED

Comment 10

17 years ago
select, button and button on file control also have this problem.
Should reopen this bug.
Comment on attachment 77372 [details]
Testcase of button, select and file

Select looks fine to me.
... because I have an un-checked-in patch to nsComboboxControlFrame.cpp in my tree.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Target Milestone: mozilla0.9.6 → mozilla1.0
We need testcases for fieldset and listbox.
This tests fieldset (which is a block so it *should* be broken) and listbox
(which we probably need to fix).  At least it should it it's right.  My build
is crashing when I open local files, so I can't tell until I attach it.
Well, ok, they're both fine (although the fieldset testcase only thanks to the
parser, but that's how it should be).  So the patch above should be enough.
Status: REOPENED → ASSIGNED

Updated

17 years ago
Attachment #77378 - Attachment description: patch fixing button (and thus file) and combobox → This patch works fine for me

Comment 17

17 years ago
Comment on attachment 77378 [details] [diff] [review]
patch fixing button (and thus file) and combox

This patch works fine for me
(Change back patch description, sorry for mistake)
Attachment #77378 - Attachment description: This patch works fine for me → patch fixing button (and thus file) and combox

Comment 18

17 years ago
Comment on attachment 77378 [details] [diff] [review]
patch fixing button (and thus file) and combox

r=rods
Attachment #77378 - Flags: review+

Comment 19

17 years ago
Comment on attachment 77378 [details] [diff] [review]
patch fixing button (and thus file) and combox

sr=waterson
Attachment #77378 - Flags: superreview+
Comment on attachment 77378 [details] [diff] [review]
patch fixing button (and thus file) and combox

a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #77378 - Flags: approval+
Fix checked in 2002-04-06 07:31 PST.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.