Closed
Bug 326162
Opened 19 years ago
Closed 18 years ago
Only top of page printed with floated div
Categories
(Core :: Layout, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: mozbugs, Unassigned)
Details
(Keywords: regression, testcase)
Attachments
(2 files)
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>
This is the full source of a "printer friendly" page from the web site above (with personal details xxx'd out. Reduced version below.
|
||
Updated•18 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•18 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•18 years ago
|
||
dbaron, any chance for 1.9a1 or a2?
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•18 years ago
|
Flags: blocking1.9a1? → blocking1.9-
Whiteboard: [wanted-1.9]
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.
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
Closed: 18 years ago
Resolution: --- → WORKSFORME
|
||
Updated•17 years ago
|
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
You need to log in
before you can comment on or make changes to this bug.
Description
•