Closed Bug 5685 Opened 25 years ago Closed 25 years ago

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

Categories

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

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

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: jsp, Assigned: kmcclusk)

References

Details

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.
Status: NEW → ASSIGNED
Target Milestone: M6
Looks like form element rendering is wrong.
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.
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.
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.
OS: Windows NT → All
Hardware: PC → All
won't this go away when we use Ender for the text widgets?
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?
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.
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.
Assignee: karnaze → kmcclusk
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.
Status: NEW → ASSIGNED
Target Milestone: M6 → M8
*** Bug 1405 has been marked as a duplicate of this bug. ***
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.
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.
*** Bug 7119 has been marked as a duplicate of this bug. ***
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
Marking as [PP][NATIVE-WIDGET] gfx-rendered form elements render with
transparent backgrounds.
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.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Fixed by enabling gfx rendered form elements as of Aug 19, 1999 4:00PM.

Will not fix for native widgets
Status: RESOLVED → VERIFIED
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.