112156 - File inputs expand to fill page when printed or previewed

Status: VERIFIED FIXED

(Core :: Printing: Output, defect, P2)

Description

[jsp]

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

[Karl Johan Kleist]

Attachment: (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

[rods (gone)]

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

Comment 3

[rubydoo123]

I think this needs to go over to dcone, reassigning to him - Don if it should be 
Marcs just reassign back to him

Comment 4

[rods (gone)]

Beth, you failed to read my comment, this is a table or block reflow bug, it is 
not Don's bug. Back to marc.

Comment 5

[rubydoo123]

talked with Rod about this one, and he explained just how severe this one is, so 
I am setting it to 9.8

Comment 6

[Marc Attinasi]

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

[Marc Attinasi]

Attachment: 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

[Marc Attinasi]

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

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

Comment 9

[Marc Attinasi]

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)

Comment 10

[Marc Attinasi]

Bulk push to next milestone

Comment 11

[Kevin McCluskey (gone)]

John can you take a look at this when you get a chance.

Comment 12

[Kevin McCluskey (gone)]

Marking nsbeta1+

Comment 13

[Syd Logan]

adt3 per adt triage

Comment 14

[Kevin McCluskey (gone)]

Taking this bug since John is overloaded.

Comment 15

[Kevin McCluskey (gone)]

Attachment: Add style rule to set size for file inputs in @media print section of forms.css

Comment 16

[Kevin McCluskey (gone)]

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

[rods (gone)]

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

Comment 18

[Marc Attinasi]

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

Comment 19

[Asa Dotzler [:asa]]

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

Comment 20

[Kevin McCluskey (gone)]

Note: This was tested on both WinXP, and Linux

Comment 21

[Kevin McCluskey (gone)]

Fix checked into the trunk

Comment 22

[sujay]

jsp, please verify this is fixed for you...thanks.

Comment 23

[jsp]

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

[sujay]

marking verified per comments..

jsp, feel free to file a new bug if necessary on the new issue.