Only top of page printed with floated div

RESOLVED WORKSFORME

Status

()

Core
Layout
RESOLVED WORKSFORME
12 years ago
10 years ago

People

(Reporter: GAThrawn, Unassigned)

Tracking

({regression, testcase})

Trunk
x86
Windows XP
regression, testcase
Points:
---
Bug Flags:
blocking1.9 -
wanted1.9 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

In the internal Unisys support system, only the top half of a page is printed when you click the "Print" button on the page. The print page is a specifically generated Print friendly page listing the full set of information for an engineer. Page URL: https://www.servicecenter.unisys.com/resolver/ (company login required, test cases coming).

The problem ticket page prints correctly in Firefox 1.0.7 and previous 1.0.x versions, but in all tested versions of Firefox 1.5 only the top half of the first page prints. So seems to be a regression since Firefox 1.0.7, this is preventing upgrade to Firefox 1.5.x

The page has a page with a <div> a <span> and <div> where the first div has {overflow:hidden} set and the final div has {float:left;overflow:hidden;} only the first div prints, nothing lower on the page, or subsequent pages prints.

Reproducible: Always

Steps to Reproduce:
1. Load first testpage
2. Try to print it (or print-preview)


Actual Results:  
Only top section of first page prints

Expected Results:  
First page is filled with text which continues onto second page.

Tested in Firefox 1.0.7 entire document prints correctly:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.12) Gecko/20050919 Firefox/1.0.7

Tested in Firefox 1.5.0.1 on XP and SeaMonkey 1.0 in Windows 2000, it fails in both:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Mozilla/5.0 (Windows; U; Windows NT 5.0; un-US; rv:1.8.0.1) Gecko/20060130 SeaMonkey/1.0

Tested in latest Trunk Firefox, none of the page prints (blank document):
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060206 Firefox/1.6a1


Reduced test case (attached below) is:

<HTML>
<HEAD>
<TITLE>
</TITLE>
<style type="text/css">
.div1 {overflow:hidden;}
.div2  {float:left;overflow:hidden;}
</style>
</HEAD>
<BODY>
<div class="div1">First Div - PRINTS OK</div>
<span>First Span - DOES NOT PRINT</span>
<div class="div2">Second Div - DOES NOT PRINT</div>
</BODY>
</HTML>
(Reporter)

Comment 1

12 years ago
Created attachment 210948 [details]
Test case. Full page, only top half prints

This is the full source of a "printer friendly" page from the web site above (with personal details xxx'd out.

Reduced version below.
(Reporter)

Comment 2

12 years ago
Created attachment 210949 [details]
Reduced test case

Updated

12 years ago
Status: UNCONFIRMED → NEW
Component: General → Layout
Ever confirmed: true
Flags: blocking1.9a1?
Keywords: regression, testcase
Product: Firefox → Core
QA Contact: general → layout
Version: unspecified → Trunk

Comment 3

11 years ago
A little debugging reveals:

1. We can't create continuations for scroll frames.

2. A float which isn't at the beginning of a line always creates a continuation when a limited height is available, i.e. in paginated/columnated contexts. (http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/generic/nsBlockReflowState.cpp&rev=3.508&mark=658#658)
This is inefficient, but would not cause problems if not for 1.

3. The reflow mechanism gives up when it can't make a continuation (http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/generic/nsBlockFrame.cpp&rev=3.767&mark=4161#4161).

I think it worked in Firefox 1.0 because we didn't paginate floats at all (the code mentioned in 2 is post-1.7, I believe).

The behavior is slightly different on the trunk; there, nothing at all shows up.

Not sure whether to mark this [reflow-refactor].

Comment 4

11 years ago
dbaron, any chance for 1.9a1 or a2?
(Reporter)

Comment 5

11 years ago
Having played around with this a bit lately (getting quite sick of this bug forcing us all to stick on Firefox 1.08 at work) and I've found a workaround for the one particular website that I first spotted this bug on.

Note that this will most definitely not work around the problem on any other website, and is not a fix for the underlying bug. I'm just posting this here in case anyone else Google's this printing problem with ServiceCenter and stumbles across this bug.

Adding the following two lines to your userChrome.css means that you can print ServiceCenter tickets in their entirety in Firefox 1.5.x and Firefox 2.0beta1:


@-moz-document domain(www.sc-ps.unisys.com){
div.labl, div.val { overflow:visible !important; } }


For more detailed info see http://gathrawn.blogspot.com/2006/07/unisys-servicecenter-firefox-printing.html
We should be able to fix Eli's item #2.

Updated

11 years ago
Flags: blocking1.9a1? → blocking1.9-
Whiteboard: [wanted-1.9]
(Reporter)

Comment 7

11 years ago
Re-tested this in the latest Trunk Minefield, the print preview on both test cases shows the full page without any problems.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/2006121304 Minefield/3.0a1

Can someone else check it to confirm that it's not just messing around with my config in the last week that's done this. Thanks.
(Reporter)

Comment 8

11 years ago
Retested with a clean profile and Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/2006121804 Minefield/3.0a1

Both test cases and a random job from the original site all now both Print Preview and Print correctly.

Looks like this was possibly fixed by the Reflow landing in bug 300030 ?
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WORKSFORME
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
You need to log in before you can comment on or make changes to this bug.