File inputs expand to fill page when printed or previewed

VERIFIED FIXED in mozilla1.0

Status

()

P2
major
VERIFIED FIXED
17 years ago
17 years ago

People

(Reporter: jsp, Assigned: kmcclusk)

Tracking

Trunk
mozilla1.0
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [bae:20011129][adt3], URL)

Attachments

(3 attachments)

(Reporter)

Description

17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6) Gecko/20011120
BuildID:    2001112009

File inputs expand vertically to the bottom of the page when printed or previewed.

Reproducible: Always
Steps to Reproduce:
1. Load the URL.
2. Preview or print the page.

Actual Results:  The file select control expands vertically to the bottom of the
page. I'd guess it's 20x as tall as it needs to be. The text box and button
texts are positioned as they should be, at the top of their boxes, but there
appears to be a huge amount of padding on the bottom.

Expected Results:  The file select control should have the same size as when it
is displayed in the browser (approximately 1em + borders).

Comment 1

17 years ago
Created attachment 59321 [details]
(partial) screendump

Build ID: 2001 11 26 03. Windows 2000.

This is what a print preview looks like for me, the top left corner of it.

Comment 2

17 years ago
This printed incorrectly in 6.2

The problem is the GfxButtonFrame is being sized incorrectly. The 
mComputedHeight in the incoming ReflowState is set to 13661 which off the top of 
my head is the content height for the page (probably).

The aReflowState coming into the nsFileControlFrame has the mComputedHeight set 
to UNCONSTRAINED, so somewhere in block reflow between the FileControlFrame and 
the GfxButtonControl the mComputedHeight is being changed. I tried to tace into 
all that but had no luck finding it.

The best way to debug this is set a break point here in FileCOntrolframe:

    nsFormControlFrame::GetStyleSize(aPresContext, aReflowState, styleSize);

And then here in GfxButtonControlFrame:

    nsFormControlFrame::GetStyleSize(aPresContext, aReflowState, styleSize);

Note that at this point in the btn frame the aReflowState.mComputedHeight is 
wrong and in the GetStyleSize is where it takes the wrong value abnd sticks it 
in styleSize to be used below in the code.

Here is the stack from where it is OK to where it is wrong:
nsGfxButtonControlFrame::DoNavQuirksReflow(nsGfxButtonControlFrame * const 
0x04a7c6c4, nsIPresContext * 0x04a0f700, nsHTMLReflowMetrics & {...}, const 
nsHTMLReflowState & {...}, unsigned int & 0) line 258
nsGfxButtonControlFrame::Reflow(nsGfxButtonControlFrame * const 0x04a7c6c4, 
nsIPresContext * 0x04a0f700, nsHTMLReflowMetrics & {...}, const 
nsHTMLReflowState & {...}, unsigned int & 0) line 591 + 31 bytes
nsLineLayout::ReflowFrame(nsIFrame * 0x04a7c6c4, nsIFrame * * 0x00129fb8, 
unsigned int & 0, nsHTMLReflowMetrics * 0x00000000, int & 0) line 1037 + 43 
bytes
nsBlockFrame::ReflowInlineFrame(nsBlockReflowState & {...}, nsLineLayout & 
{...}, nsLineList_iterator {...}, nsIFrame * 0x04a7c6c4, unsigned char * 
0x00129438) line 3674 + 29 bytes
nsBlockFrame::DoReflowInlineFrames(nsBlockReflowState & {...}, nsLineLayout & 
{...}, nsLineList_iterator {...}, int * 0x00129b58, unsigned char * 0x00129928, 
int 0, int 0) line 3555 + 32 bytes
nsBlockFrame::DoReflowInlineFramesAuto(nsBlockReflowState & {...}, 
nsLineList_iterator {...}, int * 0x00129b58, unsigned char * 0x00129928, int 0, 
int 0) line 3480 + 46 bytes
nsBlockFrame::ReflowInlineFrames(nsBlockReflowState & {...}, nsLineList_iterator 
{...}, int * 0x00129b58, int 0, int 0) line 3424 + 36 bytes
nsBlockFrame::ReflowLine(nsBlockReflowState & {...}, nsLineList_iterator {...}, 
int * 0x00129b58, int 0) line 2492 + 33 bytes
nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & {...}) line 2149 + 31 bytes
nsBlockFrame::Reflow(nsBlockFrame * const 0x04a7bbb8, nsIPresContext * 
0x04a0f700, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, 
unsigned int & 0) line 824 + 15 bytes
nsFileControlFrame::Reflow(nsFileControlFrame * const 0x04a7bbb8, nsIPresContext 
* 0x04a0f700, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, 
unsigned int & 0) line 375 + 25 bytes
Assignee: rods → attinasi
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 3

17 years ago
I think this needs to go over to dcone, reassigning to him - Don if it should be 
Marcs just reassign back to him
Assignee: attinasi → dcone

Comment 4

17 years ago
Beth, you failed to read my comment, this is a table or block reflow bug, it is 
not Don's bug. Back to marc.
Assignee: dcone → attinasi

Comment 5

17 years ago
talked with Rod about this one, and he explained just how severe this one is, so 
I am setting it to 9.8
Priority: -- → P2
Whiteboard: [bae:20011129]
Target Milestone: --- → mozilla0.9.8

Comment 6

17 years ago
Rod, the problem is this line in forms.css:

/* button part of file selector */
input[type="file"] > input[type="button"] {
  height: inherit;
}


You are setting the height to be 'inherit' and that probably changes in print
preview mode to mean inherit from something really big.  I'll attach a reduced
testcase too, showing the impact of overriding that height property.

Comment 7

17 years ago
Created attachment 64385 [details]
Testcase showing that an explicite size for the inlut[type="file"] fixes the problem.

The size of the input[type="file] is set to 'inherit' - in PrintPreview this
probably means somethign different than in galley mode - not sure what to do
here since I don't understand the relationships of the page, body, html
elements

Comment 8

17 years ago
Quick hack is to put this in the @media print section of forms.css

input[type="file"] { height: 2em; }

Comment 9

17 years ago
Rod, what is going on with the frame hierarchy in printing that would change
this? Is there another frame between the <input> and the <body>, or something?

I think that this is either a FormControl issue or a Print issue - but I cannot
tell without doing some serious digging, and since viewer has no print preview
this is hard (no Dump Frames facility in Mozilla either)
Status: NEW → ASSIGNED

Comment 10

17 years ago
Bulk push to next milestone
Target Milestone: mozilla0.9.8 → mozilla0.9.9
(Assignee)

Comment 11

17 years ago
John can you take a look at this when you get a chance.
Assignee: attinasi → jkeiser
Status: ASSIGNED → NEW
(Assignee)

Comment 12

17 years ago
Marking nsbeta1+
Keywords: nsbeta1+
Target Milestone: mozilla0.9.9 → mozilla1.0

Comment 13

17 years ago
adt3 per adt triage
Whiteboard: [bae:20011129] → [bae:20011129][adt3]
(Assignee)

Comment 14

17 years ago
Taking this bug since John is overloaded.
Assignee: jkeiser → kmcclusk
(Assignee)

Comment 15

17 years ago
Created attachment 76202 [details] [diff] [review]
Add style rule to set size for file inputs in @media print section of forms.css
(Assignee)

Updated

17 years ago
Keywords: review
(Assignee)

Comment 16

17 years ago
I confirmed that setting the file input size in a style rule in the @media print
section of forms.css fixes both print preview and printing of file input elements.

Comment 17

17 years ago
Comment on attachment 76202 [details] [diff] [review]
Add style rule to set size for file inputs in @media print section of forms.css

r=rods
Attachment #76202 - Flags: review+

Comment 18

17 years ago
Comment on attachment 76202 [details] [diff] [review]
Add style rule to set size for file inputs in @media print section of forms.css

sr=attinasi
Attachment #76202 - Flags: superreview+
(Assignee)

Updated

17 years ago
Keywords: approval
Comment on attachment 76202 [details] [diff] [review]
Add style rule to set size for file inputs in @media print section of forms.css

a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #76202 - Flags: approval+
(Assignee)

Comment 20

17 years ago
Note: This was tested on both WinXP, and Linux
(Assignee)

Comment 21

17 years ago
Fix checked into the trunk
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 22

17 years ago
jsp, please verify this is fixed for you...thanks.
(Reporter)

Comment 23

17 years ago
WFM in 2002032708. A quibble, however: while the file input and the submit
button have the same height in the screen rendering, the file input is taller in
the print rendering. Ideally, for any given media, both controls would have the
same height. Furthermore, if their relative heights change based on media, it
violates the rule of least astonishment.

Comment 24

17 years ago
marking verified per comments..

jsp, feel free to file a new bug if necessary on the new issue.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.