Closed Bug 192938 Opened 22 years ago Closed 21 years ago

Form elements not visible in print and print preview

Categories

(Core :: Printing: Output, defect)

Product:
Core
Component:
Printing: Output
Platform:
x86
Windows NT
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 191938

People

(Reporter: xavier.loup, Assigned: rods)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3b) Gecko/20030210
Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3b) Gecko/20030210

The border of form elements are not visible in print and print preview.

Reproducible: Always

Steps to Reproduce:
1. Create a simple web page with this content

<html>
<head>
  <meta http-equiv="content-type"
 content="text/html; charset=ISO-8859-1">
  <title>Print test</title>
</head>
<body>
<br>
<form>
  <p><input type="text" name="testText" value="test text"></p>
  <p><input type="radio" name="testRadio" value="test"> test radio</p>
  <p>
  <select name="testSelact">
  <option value="Test">Test Select</option>
  </select>
  </p>
</form>
</body>
</html>


2. Open the page in print preview
3. Print the page

Actual Results:  
The borders of text inputs are not visible in print preview.
The borders of select and radio inputs are not visible in print and print preview.

The content of these elements is visible, only the border is missing.

Expected Results:  
All inputs should be visible in print and print preview.
Sounds like more theming issues...
This happens only when you have "Print Background (colors & images)" turned 
off...  I think this was exposed by your patch in 191574.  The default value 
for aUsePrintSettings used to be false, but now it's getting called with true 
in nsFrame.  So it's bailing before the theme paints.  The theme stuff should 
probably be moved before the printing check.. see
http://lxr.mozilla.org/mozilla/source/layout/html/style/src/nsCSSRendering.cpp#2
836
Status: UNCONFIRMED → NEW
Ever confirmed: true
Right-o.  That's what the patch in bug 191938 does.
Depends on: 191938
So... is this fixed now by bug 191938?
At least I cannot reproduce it in a current build on Win2k.

*** This bug has been marked as a duplicate of 191938 ***
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.