[PP][NATIVE-WIDGET]<input> background cannot be made transparent (which should be default)

VERIFIED FIXED in M15

Status

()

P3
normal
VERIFIED FIXED
20 years ago
19 years ago

People

(Reporter: jsp, Assigned: kmcclusk)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

20 years ago
Maybe I'm missing something here, and I may have guessed wrong as to the
appropriate component. I trust someone will tell me if so...

I'm running Mozilla M4. The following trivial HTML displays a single radio
button on a form with a gray background. According to my reading of the HTML 4.0
spec, all elements should by default have a transparent background. However,
using apprunner, the button has a white square around it.

<html>
  <body bgcolor=#c0c0c0>
    <form>
      <input type="radio" name="radio1" value="1">
    </form>
  </body>
</html>

You'd think you could work around this by specifying a transparent background,
but this results in a black background instead.

Similar problems occur with <input type="image"> if the image has transparent
regions. Probably related: if you assign a <label> to a radio button (probably
other inputs as well), it has the same behavior.

I can't reproduce any of this with the December Gecko release, for what that's
worth.

Updated

20 years ago
Status: NEW → ASSIGNED
Target Milestone: M6

Comment 1

20 years ago
Looks like form element rendering is wrong.
(Reporter)

Comment 2

20 years ago
My recollection about Gecko's behavior was incorrect. Radio button inputs and
<label> behave the same as M4, but img inputs correctly display the background
color in transparent regions.

Comment 3

20 years ago
On the Mac, radio buttons are drawn by a call to ::DrawOneControl, which is
evidently erasing the whole rectangle to white. The appearance manager provides a
way to install user defined functions that get called for various operations
controls might perform, such as defining the background color used whenever a
control draws. Here's a reference:

http://developer.apple.com/techpubs/macos8/HumanInterfaceToolbox/ControlManager/﷒0﷓

If we attach a ControlUserPaneBackgroundUPP to the root control of each window
(using SetControlData(rootControl, kControlEntireControl,
kControlUserPaneBackgroundProcTag, sizeof(ControlUserPaneBackgroundUPP), &upp),
then the function will be called to set up the proper background color for the
control. Is this the only way to make this work?

This also appears to be a problem on Win95.

Comment 4

20 years ago
On the Mac, radio buttons are drawn by a call to ::DrawOneControl, which is
evidently erasing the whole rectangle to white. The appearance manager provides a
way to install user defined functions that get called for various operations
controls might perform, such as defining the background color used whenever a
control draws. Here's a reference:

http://developer.apple.com/techpubs/macos8/HumanInterfaceToolbox/ControlManager/﷒0﷓

If we attach a ControlUserPaneBackgroundUPP to the root control of each window
(using SetControlData(rootControl, kControlEntireControl,
kControlUserPaneBackgroundProcTag, sizeof(ControlUserPaneBackgroundUPP), &upp),
then the function will be called to set up the proper background color for the
control. Is this the only way to make this work?

This also appears to be a problem on Win95.

Updated

20 years ago
OS: Windows NT → All
Hardware: PC → All
won't this go away when we use Ender for the text widgets?

Comment 6

20 years ago
But Ender won't affect form control backgrounds? I'd really like to see form
controls drawn better; ever since 4.0, they've looked really messy.
Form controls will be gfx-rendered. That was our solution, no?

Comment 8

20 years ago
Correct. Bug #4764 ("Radio buttons display garbage around periphery") is assigned
to me. This one, as well as a couple of other bugs, has been marked "[NATIVE-
WIDGETS]" and I'll close them as Invalid as soon as we get rid of native widgets.
Similarly, I have several bugs that are marked "[ENDER]". I used this method
because QA and especially the i18n team wouldn't let me close them as Later.

Comment 9

20 years ago
Pierre, I assume you meant bug # 4767. These may in fact be related, but this bug
also appears currently on Windows NT/95 with the included example.

Updated

20 years ago
Assignee: karnaze → kmcclusk

Comment 10

20 years ago
This will only be supported for gfx rendered form controls which will not
include <input type=text> or <input type=textarea> until Ender is ready.
Reassigning to Kevin. Pierre is alreay on the CC list.
(Assignee)

Updated

20 years ago
Status: NEW → ASSIGNED
(Assignee)

Updated

20 years ago
Target Milestone: M6 → M8
(Assignee)

Comment 11

20 years ago
*** Bug 1405 has been marked as a duplicate of this bug. ***

Comment 12

20 years ago
I investigated this problem a little bit on the Mac.
1) Mac specific: I'll do an ::EraseRect() before the ::DrawOneControl() so that
the background paints correctly if it is set to the proper color in Layout.
2) XP: if NEW_COMPOSITOR is enabled in nsViewManager.cpp, the entire widgetRect
of the native control frames is clipped out of the visRegion when painting the
background of the parent view. It means that if you have a dozen native
controls on a gray background, the NEW_COMPOSITOR will paint a gray background
with a dozen white holes in it before painting the controls themselves.
3) XP: The background of the buttons is properly painted, but not the background
of radio buttons nor checkboxes which still appears as white. I could tell that
the background was correctly set for buttons because on the Mac - unlike on
other platforms - they are displayed as round rects, not square rects, and the
pixels at the corner were correctly painted as gray. I looked a bit further and
saw that the background color was set by
nsButtonControlFrame::PostCreateWidget() when calling SetColors(). This call
doesn't exist in nsRadioControlFrame nor nsCheckboxControlFrame. I added it but
it did not help because by the time GetStyleData() is called inside SetColors(),
the background color is white instead of gray. Maybe because, as suggested
above, the background is not transparent for these controls.

Hope this helps. Have fun with the rest.

Comment 13

20 years ago
Correction: The note #2 above means that if NEW_COMPOSITOR is enabled (and it is
now), the native controls have the responsability to paint their own background.
As a result, I'm not sure that making the background transparent will change
anything. Maybe... if the transparency setting is used to initialize the color
of a children according to the color of its parent.
(Assignee)

Comment 14

20 years ago
*** Bug 7119 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

20 years ago
Summary: <input> background cannot be made transparent (which should be default) → [PP][NATIVE-WIDGET]<input> background cannot be made transparent (which should be default)
Target Milestone: M8 → M15
(Assignee)

Comment 15

20 years ago
Marking as [PP][NATIVE-WIDGET] gfx-rendered form elements render with
transparent backgrounds.

Comment 16

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

Updated

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

Comment 17

19 years ago
Fixed by enabling gfx rendered form elements as of Aug 19, 1999 4:00PM.

Will not fix for native widgets

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 18

19 years ago
With the Sept 2 build with gfx enabled, the problem is fixed.
You need to log in before you can comment on or make changes to this bug.