Last Comment Bug 154892 - Splitting Absolutely positioned frames not implemented - Missing second page of content when printing or print previewing this site
: Splitting Absolutely positioned frames not implemented - Missing second page ...
Status: RESOLVED FIXED
don't spam the bug [adt2] PATCH
: dataloss, testcase, top100, topembed+
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: All All
: -- critical with 117 votes (vote)
: mozilla1.9beta1
Assigned To: fantasai
:
Mentors:
http://sports.espn.go.com/mlb/index
: 75213 122750 127527 153332 188167 205486 207962 219274 229900 231483 234023 235157 237970 238004 240035 240715 241695 242135 242227 242606 244480 248440 251571 256203 258501 260024 260069 260423 262170 263260 265197 265355 266504 267709 267745 269993 270291 270827 271311 272998 273780 274684 274961 276504 277133 278952 280753 288635 289414 290503 292716 296867 297423 298179 298946 299076 300728 301880 302763 303002 304399 309105 310555 312412 315763 319931 327112 327736 328123 330719 330880 337183 341936 350709 357483 361471 366948 372594 379252 391521 392298 398106 398452 398518 403750 406749 411033 (view as bug list)
Depends on: 379349 398322 398332 399994 450509
Blocks: 521204 538708 546559 394237
  Show dependency treegraph
 
Reported: 2002-06-28 15:09 PDT by Kevin McCluskey (gone)
Modified: 2015-04-07 14:52 PDT (History)
173 users (show)
reed: wanted1.9+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Reduced test case from espn site (3.60 KB, text/html)
2002-06-28 23:10 PDT, Chris Petersen
no flags Details
patch to implement splitting absolutely positioned elements (98.37 KB, patch)
2002-11-04 07:31 PST, karnaze (gone)
no flags Details | Diff | Splinter Review
kin's test case that probably asserts the patch (142 bytes, text/html)
2002-12-03 17:37 PST, karnaze (gone)
no flags Details
Super simplified tests case (1.03 KB, text/html)
2004-07-07 19:22 PDT, Leigh Morresi
no flags Details
A screenshot of the problem in action. (211.76 KB, image/png)
2007-01-26 04:38 PST, Chris Thompson
no flags Details
first pass (21.86 KB, patch)
2007-08-09 13:34 PDT, fantasai
no flags Details | Diff | Splinter Review
dynamic testcase (multi-col) (1.53 KB, application/xhtml+xml)
2007-08-17 14:33 PDT, fantasai
no flags Details
patch pass 2 (55.97 KB, patch)
2007-08-17 16:28 PDT, fantasai
no flags Details | Diff | Splinter Review
patch (30.59 KB, patch)
2007-08-23 14:54 PDT, fantasai
no flags Details | Diff | Splinter Review
patch -up12 (56.17 KB, patch)
2007-08-24 11:27 PDT, fantasai
no flags Details | Diff | Splinter Review
patch pass 4 (60.86 KB, patch)
2007-09-02 00:33 PDT, fantasai
no flags Details | Diff | Splinter Review
patch pass 5 (60.38 KB, patch)
2007-09-05 19:32 PDT, fantasai
roc: superreview+
Details | Diff | Splinter Review
Multi-Col Interlaced Abspos and Overflow Pagination [reftest-ready] (4.16 KB, application/xhtml+xml)
2007-09-05 19:42 PDT, fantasai
no flags Details
Interlaced Abspos and Overflow Pagination [reftest-ready] (4.44 KB, application/xhtml+xml)
2007-09-07 22:01 PDT, fantasai
no flags Details
Dynamic Interlaced Abspos and Overflow Pagination [reftest-ready] (6.45 KB, application/xhtml+xml)
2007-09-29 20:03 PDT, fantasai
no flags Details
patch (73.02 KB, patch)
2007-09-29 20:06 PDT, fantasai
roc: review+
roc: superreview+
roc: approval1.9+
Details | Diff | Splinter Review
diff patch and patch pass 5 (29.04 KB, patch)
2007-09-30 14:43 PDT, fantasai
no flags Details | Diff | Splinter Review
reftests.zip (7.10 KB, application/zip)
2007-10-01 20:47 PDT, fantasai
no flags Details
final patch (66.11 KB, patch)
2007-10-02 00:38 PDT, fantasai
no flags Details | Diff | Splinter Review
follow-up patch (15.68 KB, patch)
2007-10-02 00:44 PDT, fantasai
roc: superreview+
roc: approval1.9+
Details | Diff | Splinter Review
Prints correctly on first page, then seems to be bunched up on the first line of the second page (13.86 KB, text/html)
2008-10-15 18:38 PDT, Isaac
no flags Details
PDF showing incorrect output of above (8.94 KB, image/pdf)
2008-10-15 18:39 PDT, Isaac
no flags Details
PDF showing correct output, as printed from Webkit (12.77 KB, image/pdf)
2008-10-15 18:41 PDT, Isaac
no flags Details
When div position is changed to relative instead of absolute, still doesn't print after first page, but does add extra blank pages (13.86 KB, text/html)
2008-10-15 18:43 PDT, Isaac
no flags Details

Description Kevin McCluskey (gone) 2002-06-28 15:09:05 PDT
If you print or print preview this site there should be at least (2) full pages
of content. Instead you get (1) full page and second page with just a little
content on it. A large portion of the content is missing. In IE 6.0 there are 2
full pages of content output.
Comment 1 Kevin McCluskey (gone) 2002-06-28 15:15:07 PDT
petersen: Chris we need a reduced test case for this page. Thanks
Comment 2 Chris Petersen 2002-06-28 17:08:25 PDT
Working on testcase
Comment 3 Chris Petersen 2002-06-28 23:10:57 PDT
Created attachment 89664 [details]
Reduced test case from espn site

Page includes an absolute positioned DIV containing a TABLE. DIV is positioned
at {position: absolute;top: 780px;left: 133px;}. Attempting to print document
will push a portion of the table to a second page. Content is only printed on
the 1 page.
Comment 4 karnaze (gone) 2002-07-01 09:12:08 PDT
This is a known problem. We don't yet split absolutely positioned elements.
Comment 5 Chris Petersen 2002-07-01 11:57:31 PDT
Removing [testcase] since a reduced testcase has been attached.
Comment 6 Kevin McCluskey (gone) 2002-07-02 06:26:35 PDT
The fix for this will large and risky. Marking nsbeta1-.
Comment 7 Kevin McCluskey (gone) 2002-07-25 13:54:58 PDT
Clearing nsbeta1-, setting target to 1.2a.
Comment 8 Chris Petersen 2002-08-01 12:35:25 PDT
Still occurs in the OS X 2002-07-31-05 NB.
Comment 9 Kevin McCluskey (gone) 2002-08-12 11:23:16 PDT
nsbeta1+
Comment 10 Max Alekseyev 2002-10-17 19:10:31 PDT
Could anybody check if bug 170848 is a dup of this one?
Comment 11 karnaze (gone) 2002-11-04 07:31:39 PST
Created attachment 105081 [details] [diff] [review]
patch to implement splitting absolutely positioned elements
Comment 12 Boris Zbarsky [:bz] 2002-11-17 14:33:17 PST
OK.  I just started reading this patch, and it'll probably take me at least a
few days to figure out everything that's going on.... for now,
IsOnParentsPage(nsIPresContext& aPresContext, nsIFrame& aFrame) seems incorrect
-- it should just |return !*value;| instead of |return (value) ? PR_FALSE :
PR_TRUE;| (yes, for now they are equivalent, but god forbid someone sets the
property to PR_FALSE instead of clearing it... ;) ).

Also, is there a good reason for passing around references instead of pointers?
 Taking a pointer of a reference is a little weird and many not even give the
same value as taking a pointer of the original object, with some compilers...
Comment 13 karnaze (gone) 2002-11-18 07:25:22 PST
As a rule, I try to use references instead of pointers in non COM methods when
they must be non null to avoid having to check for null. I don't think there is
any additional overhead for passing references instead of pointers.
Comment 14 karnaze (gone) 2002-11-20 15:45:25 PST
The comments in the patch of bug 127286 relating to the Get/SetProperty methods
and the memory leak of the property value are probably appropriate here as well,
since the code for Get/SetProperty was borrowed from that bug.
Comment 15 kinmoz 2002-11-25 13:37:35 PST
Comment on attachment 105081 [details] [diff] [review]
patch to implement splitting absolutely positioned elements

I'm about a 3rd of the way through this diff, and I'm still trying to grok
what's going on. Here are my notes so far:


==== Should this just be removed?


-    SetIsPrintingInDocShellTree(docShellTreeNode, aIsPrinting, PR_TRUE);
+    //SetIsPrintingInDocShellTree(docShellTreeNode, aIsPrinting, PR_TRUE);


==== Was this commented out while you were debugging? Or did you comment it out
on purpose?


-      DumpNode(tree2, stdout, 1);
-      result = PR_FALSE; // we have a non-critical failure, so remember that
but continue
+      //DumpNode(tree2, stdout, 1);
+      //result = PR_FALSE; // we have a non-critical failure, so remember that
but continue


==== This leaks the |value| since the PR_TRUE arg just removes the property
from the hash table, but never causes the destructor func for the property to
be called ... why even allocate a bool? Why not just store a zero or non-zero
value as the property?


+    PRBool* value = 
+      NS_STATIC_CAST(PRBool*, aFrame.GetProperty(&aPresContext, 
+						 
nsLayoutAtoms::notOnParentsPageProperty, 
+						  PR_TRUE));


==== So why use a reference args in some cases and not in others? In particular
the |didReflow| pointer arg you add to ReflowAbsoluteFrame()?


==== I'm not sure I fully grok the changes you are making to
|nsAbsoluteContainingBlock::Reflow()|, like why the next-in-flow you create for
|kidFrame| has to be placed before |kidFrame| in the flow chain, especially
after seeing that you have to transfer placeholder info over to the
next-in-flow you just created?


==== |nsHTMLContainerFrame::CreateNextInFlow()| leaves |kidFrame| and |kidCont|
as siblings, doesn't that mean that the call to
|mAbsoluteFrames.ReplaceFrame()| will cause any siblings after |kidCont| to be
lost and it's next sibling pointer pointing at itself?


+      // Remove kidFrame from the absolute items and add kidCont instead.
+      mAbsoluteFrames.ReplaceFrame(parent, kidFrame, kidCont);
+
+      contFrames.AppendFrame(parent, kidFrame);
+      ::SetOnParentsPage(*aPresContext, *kidCont, PR_FALSE);
+      continue;


==== Also, does anything ever null out the |mNextSibling| pointer of
|kidFrame|? Or are we relying on that being left non-null to help us continue
on through the |for| loop to process the next-in-flow we just created? I
believe frameLists expect their lists to be null terminated. Won't this cause
problems when |AddContinuedOutOfFlows()| gets called?
Comment 16 Boris Zbarsky [:bz] 2002-11-25 22:25:51 PST
I'm sorry it's taking me so long to get to this.... I may be able to do it
tomorrow night; if not it won't be till after Thanksgiving... 
Comment 17 karnaze (gone) 2002-12-03 17:37:10 PST
Created attachment 108127 [details]
kin's test case that probably asserts the patch
Comment 18 kinmoz 2002-12-16 12:30:00 PST
Comment on attachment 105081 [details] [diff] [review]
patch to implement splitting absolutely positioned elements

I'm almost all the way through the this diff, here more of my notes ...

==== The parent of a positionedInlineFrame could be another inline, do we need
some sort of loop to traverse up the hierarchy to find the parent block?


+    else if (nsLayoutAtoms::positionedInlineFrame == delType) {
+      // add the continued frames to the overflow lines of aDelegatingFrame's
block parent
+      nsIFrame* parent;
+      aDelegatingFrame->GetParent(&parent);
+      if (nsBlockFrame::IsBlockFrame(*parent)) {
+	 ((nsBlockFrame*)parent)->AddContinuedOutOfFlows(*aPresContext,
contFrames);
+      }
+      else
+	 NS_ASSERTION(PR_FALSE, "invalid parent of positioned inline frame");
+    }
+    else
+      NS_ASSERTION(PR_FALSE, "invalid delegating frame");



==== Instead of calling |GetFrameType()| through every iteration of the loop,
you might just want to call it under the |if (display->IsPositioned())| block
which is the only place that uses it.


+	 for (firstInFlow->GetParent(&parent); parent && (parent !=
pageContentFrame); parent->GetParent(&parent)) {
+	   nsCOMPtr<nsIAtom> fType;
+	   parent->GetFrameType(getter_AddRefs(fType));


==== Should this be |-1 == aCBWidth| like the code you replaced checked?


+    if ((-1 != aCBWidth) || (-1 == aCBHeight)) {
+      cbFrame = kidReflowState.ComputeContainingBlockRectangle(aPresContext,
&aReflowState,
+								aCBWidth,
aCBHeight);



==== Do we need to call |NS_WARNING()| if |kidOffset.y < 0| like we did above
this code?


+  // Position the child relative to our padding edge. 
+  nsRect rect(kidOffset.x, kidOffset.y, 
+	       kidDesiredSize.width, kidDesiredSize.height);
+  // XXX there can be data loss if kidOffset.y < 0. See comments above.
   aKidFrame->SetRect(aPresContext, rect);


==== Will this cause a problem if a block with overflow none contains another
block that is completely within the bounds of the parent yet straddles 2 pages?



+  aStatus = state.mReflowStatus;
+
+  if (NS_FRAME_IS_NOT_COMPLETE(aStatus)) {
+    if (NS_STYLE_OVERFLOW_HIDDEN == aReflowState.mStyleDisplay->mOverflow) {
+      aStatus = NS_FRAME_COMPLETE;
+    }
Comment 19 Kevin McCluskey (gone) 2003-01-07 15:00:48 PST
-> Kin
Comment 20 Boris Zbarsky [:bz] 2003-01-08 19:32:02 PST
*** Bug 188167 has been marked as a duplicate of this bug. ***
Comment 21 Brant Gurganus 2003-01-18 17:57:25 PST
By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.
Comment 22 Jim Goode 2003-04-16 15:29:45 PDT
I found a MOZILLA WorkAround!!!! 
(for #166836, most likely this one and #75213 too)
(now line-spacing is a bit jacked in IE6 - Use a browser detect & write)

link a stylesheet for printing only.
<link href="/common/NoPrint.css" rel="stylesheet" type="text/css" media="print" />

In the stylesheet, redefine the <BODY> tag with:
body{
white-space: pre;
line-height: .5em;
}

Long Single Divs that wouldn't print all parts before should print all parts,
and also, Multiple Divs that were split and printed on multiple pages, will now
all print Inline.

YEAH!
Comment 23 Boris Zbarsky [:bz] 2003-06-02 08:52:30 PDT
*** Bug 207962 has been marked as a duplicate of this bug. ***
Comment 24 Asa Dotzler [:asa] 2003-09-10 13:19:50 PDT
Is this the kind of change we could still consider for 1.5 or is it something
that needs to happen in an alpha or beta first?
Comment 25 Asa Dotzler [:asa] 2003-09-10 13:27:11 PDT
Too large a change for 1.5. This is going to need vetting in an alpha cycle. 
Comment 26 kinmoz 2003-09-10 13:37:41 PDT
Yeah I'd be a bit nervous about this for 1.5 final, besides, the patch is almost
a year old so it might have bit-rotted a bit. FYI, we held off on some of this
because of jkeiser's pending rewrite/simplification of our printing mechanism.
Comment 27 Boris Zbarsky [:bz] 2003-09-15 08:52:43 PDT
*** Bug 219274 has been marked as a duplicate of this bug. ***
Comment 28 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2003-10-21 21:52:50 PDT
*** Bug 122750 has been marked as a duplicate of this bug. ***
Comment 29 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2003-11-25 12:35:08 PST
*** Bug 75213 has been marked as a duplicate of this bug. ***
Comment 30 Boris Zbarsky [:bz] 2003-12-11 14:24:37 PST
*** Bug 153332 has been marked as a duplicate of this bug. ***
Comment 31 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2004-01-02 07:34:48 PST
*** Bug 229900 has been marked as a duplicate of this bug. ***
Comment 32 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2004-01-19 09:31:36 PST
*** Bug 231483 has been marked as a duplicate of this bug. ***
Comment 33 Oliver Klee 2004-01-24 02:09:04 PST
What's the status of jkeiser's pending rewrite/simplification of our printing
mechanism? Maybe this bug can be marked as a dependency of that bug.
Comment 34 Boris Zbarsky [:bz] 2004-01-24 09:30:08 PST
jkeiser is not currently working on Mozilla code, and his suggested rewrite had
some issues that roc raised, last I checked.
Comment 35 Robert Accettura [:raccettura] 2004-01-28 16:57:03 PST
(In reply to comment #34)
> jkeiser is not currently working on Mozilla code, and his suggested rewrite had
> some issues that roc raised, last I checked.

Is there a bug for that?  Could we add it as a "depends on" for reference
(besides, I'd like to read up on it).
Comment 36 Boris Zbarsky [:bz] 2004-02-12 09:08:34 PST
*** Bug 234023 has been marked as a duplicate of this bug. ***
Comment 37 Boris Zbarsky [:bz] 2004-03-19 09:37:00 PST
*** Bug 237970 has been marked as a duplicate of this bug. ***
Comment 38 Boris Zbarsky [:bz] 2004-03-19 09:37:58 PST
*** Bug 238004 has been marked as a duplicate of this bug. ***
Comment 39 Boris Zbarsky [:bz] 2004-04-16 09:42:56 PDT
*** Bug 240715 has been marked as a duplicate of this bug. ***
Comment 40 Boris Zbarsky [:bz] 2004-04-25 20:36:36 PDT
*** Bug 241695 has been marked as a duplicate of this bug. ***
Comment 41 Bogdan Stroe 2004-04-30 18:49:23 PDT
*** Bug 242227 has been marked as a duplicate of this bug. ***
Comment 42 Craig Reynolds 2004-05-06 16:54:13 PDT
I'm probably being redundant so at least I will be brief...  I just noticed this
symptom in 1.7(RC1) on Mac OS 10.3.3 (and 1.7b on Linux) for this page:
http://mediamatters.org/
Comment 43 Jesiah S 2004-05-12 10:24:49 PDT
*** Bug 240035 has been marked as a duplicate of this bug. ***
Comment 44 Stefan [:stefanh] 2004-05-24 04:15:07 PDT
*** Bug 244480 has been marked as a duplicate of this bug. ***
Comment 45 Hal Johnson 2004-05-28 13:04:00 PDT
(In reply to comment #22)
> I found a MOZILLA WorkAround!!!! 
> (for #166836, most likely this one and #75213 too)

It didn't work for me. (a single DIV position: absolute).
Comment 46 Jens O. Meiert 2004-07-05 11:42:10 PDT
Maybe helpful for others suffering from this bug: I was able to 'fix' the
described malpractice in a quite complex document (heavy use of 'floats',
positioned, and overflow restricted elements) via a single '* { overflow:
visible; }' in the print style sheet.

(Alas, the sources are currently locked, and it was too much work to create a
neutral and reasonable pendant yet. I'll add an URI later if wanted.)

Also, I determined a strange behavior in relation to two+ CSS class values per
'class' attribute, a la '<div class="foo bar" />'. In this case, removing 'bar'
fixed the print bug, but I didn't succeed in manually overrunning (and
resetting) all declarations defined by 'bar' (this was kind of curious).

Hope this helps anyway.
Comment 47 mmortal03 2004-07-05 15:00:12 PDT
I think more and more, printing bugs have become the most annoying bugs in
Mozilla;  people just don't like wasting paper and having to reprint pages.  I
frequently have to go into IE to print pages that just won't print correctly. 
This bug is the biggest printing bug that I have run into with Mozilla and
Firefox.  There are a couple of very similar printing bugs that I have noticed,
and they have to do with whole prints of pages being blank, printing selection
printing a blank page, first page of print blank, second page of print blank,
and print preview being blank.   Oddly, all of these bugs seem related to the
splitting of pages in some way, and all seem to lead me back to this bug.  Here,
are some examples; some may be duplicates of this bug.  Bug 208070, Bug 192129,
 Bug 132712, Bug 191308.   This bug should definately be reviewed to block
aviary-1.0.  Something to note, it is the most voted on printing bug on Bugzilla.
Comment 48 Robert Accettura [:raccettura] 2004-07-05 15:50:00 PDT
I'll second the nomination for blocking blocking-aviary1.0.

I've run across a few times where I've printed and found that the page was
effected by this bug.  I'm sure most mozilla users have as well.  

The problem I see is that this will need some serious testing (it's really
something for an alpha release).

But it's also a bug I think is pretty ugly, and not something that should make
it into a release.
Comment 49 Pierre 2004-07-06 01:59:59 PDT
I think this bug prevents a lot of people from using the Mozilla products (Camino/Firefox for me). It is 
not only very annoying, it is very dangerous and some data loss may occur on the paper side: in my 
case, I didn't realize I was missing a page 2 because only 1 line would have been printed there, but this 
was important information... Unfortunately, we still need a lot of paper, and although I realize a 
browser is not meant for printing, this bug forces me to use other browsers on my daily tasks. For the 
record, Safari and Opera 7.5 are printing these pages ok.
Comment 50 dolphinling 2004-07-06 18:41:57 PDT
If this is going to block aviary1.0, it had better block the release candidate,
too, so it's tested enough...

blocking-aviary1.0RC1 ?
Comment 51 Leigh Morresi 2004-07-07 19:22:17 PDT
Created attachment 152571 [details]
Super simplified tests case

This is a super-simplified example of this bug where position: absolute tag
confused mozilla's internals and stops mozilla printing the right amount of
pages (mozilla will only print the first page)
Comment 52 Adam Becevello 2004-07-08 08:27:42 PDT
*** Bug 242606 has been marked as a duplicate of this bug. ***
Comment 53 Andrew Hagen 2004-07-11 12:15:45 PDT
Karnaze posted the patch. Karnaze is now gone. See comment 4.

Kinmoz is now the bug's owner, but is also signed up to superreview the patch,
which came from Karnaze.

In comment 15, Kinmoz wanted some changes in the patch.

A possibility would be for Kinmoz to minus the superreview on the patch. Then we
move on from there.
Comment 54 Max Alekseyev 2004-07-15 16:58:24 PDT
*** Bug 251571 has been marked as a duplicate of this bug. ***
Comment 55 Leigh Morresi 2004-07-28 19:34:01 PDT
Hello

I have made an example of how someone could use this bug to hide information
about transactions etc.

http://dgtlmoon.koan.net/mozilla-printing-loss-of-information/
Comment 56 Andrew Schultz 2004-08-20 18:13:42 PDT
*** Bug 256203 has been marked as a duplicate of this bug. ***
Comment 57 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2004-09-08 13:51:44 PDT
*** Bug 258501 has been marked as a duplicate of this bug. ***
Comment 58 James Napolitano 2004-09-09 20:53:42 PDT
*** Bug 242135 has been marked as a duplicate of this bug. ***
Comment 59 Manfred Richter 2004-09-22 02:29:24 PDT
I have the same problem with "print preview" and printing the full document. The
preview and printing stopps at end of page 1 (only two "<div class=..." in my
xhtml-document) -> Mozilla 1.7.3 . 
I can say, i'm not so happy about this critically bug, that does not appear in
Opera and IE.
Is there a solution or bug around "in sight" ????
Comment 60 Manfred Richter 2004-09-22 10:15:47 PDT
Additional Comment No. 2 :
I've also make some testing with my pages about this bug. Perhaps it will help
someone, here are my few tests and the results:

Original CSS-definitions (with the problem of only 1 page in mozilla):

div { text-align: center ; }

div.toppi    { text-align: left ; background-color: #66CCFF ; padding: 0 ;
margin: 0 ;
               position: absolute ;
               top: 0 ;
               left: 0 ;
               right: 0 ;
               width: 100% ; 
               height: 114px ;
               border-bottom: 4px solid #CCCCCC ; }

div.botti    { text-align: left ; background-color: #FFFFCC ; padding: 0 ;
               position: absolute ; 
               left: 0 ;
               top: 120px ;
               margin-left: 0mm ;
               margin-top: 1mm ;
               margin-right: 0mm ;
               width: 100% ; }

The problem seems for me in the tag "position: absolute ;" in "div.botti". When 
i change it to the folling, the problem is not there. Also my page looks
fine in Opera. But: In IE the "div.botti"-stuff ist placed from the top, so that
means under my navigation-stuff ("div.toppi"):

div.botti    { text-align: left ; background-color: #FFFFCC ; padding: 0 ;
margin: 0 ;
               left: 0 ;
               top: 200px ;
               margin-left: 0mm ;
               margin-top: 122px ;
               margin-right: 0mm ;
               width: 100% ; }

Best Regards
Manny

PS to Leigh:
I think, i reduce my CSS-file to only 1 "div"-definition, to get also a
relatively fine lookout with IE (yes, i know, about 94 % are still using IE).

Sorry, but this is really not the way, that i as webpage-creator have to write 
around the tricky implementions of the "glasklaren" W3C-standards in the 
browser-clients.
Comment 61 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2004-09-29 13:28:05 PDT
*** Bug 262170 has been marked as a duplicate of this bug. ***
Comment 62 Leigh Morresi 2004-10-04 06:45:10 PDT
Manny,
There is no way fixing my local code will solve the problem, the problem exists
with the rest of the world, not just my code, every other browser can print it
just fine.

After much discussion i am told that anyone that worked on the printing
subsystem with mozilla was with netscape, and they have long long since gone, so
basically we are up a creek without a paddle, meanwhile, my company will
continue to use microsoft internet explorer because IT PRINTS RELIABLY, it just
doesnt cut it, we are not getting anywhere with this bug, everyone has provided
as much information as they can to help the developers of mozilla address the
problem but they just dont give a damn OR they dont have the technical know-how
to resolve the bug.

In a commercial environment, someone would have been employed to fix this bug,
where do i throw some money? Why are there so many slashdot stories carrying on
about how great mozilla is? how come non of my original posts about looking for
help to fix this bug made it slashdot? is there some kind of self-feeding loop
of **** that is making opensource *desktop* out to be better than it is?
Comment 63 Andrew Schultz 2004-10-04 07:06:25 PDT
> After much discussion i am told that anyone that worked on the printing
> subsystem with mozilla was with netscape, and they have long long since gone, so
> basically we are up a creek without a paddle

There are people working on printing, but (as you might notice) this is a layout
bug.
Comment 64 Corey Gilmore 2004-10-04 07:11:30 PDT
(In reply to comment #62)
> Manny,
> There is no way fixing my local code will solve the problem, the problem exists
> with the rest of the world, not just my code, every other browser can print it
> just fine.

I can't speak to the rest of your post, but you can fix your local code - I did.
 Changing the surrounding div's position from absolute to relative will do it,
even if you have to create a print specific definition.  
@media print { #mainContent { position:relative; } }

It's an obnoxious bug, but if cross-browser support is important to you, you'll
work around it.
Comment 65 Ronald W. Heiby 2004-10-08 20:51:17 PDT
I ran into this bug report when looking to see whether my problem was already
reported. I suspect that this may also apply to the page I'm still forced to use
IE in order to print properly, <http://www.cboe.com/data/IntraDayVol.aspx>. Is
this the same problem? Thanks!
Comment 66 Andrew Schultz 2004-10-20 20:59:50 PDT
*** Bug 265197 has been marked as a duplicate of this bug. ***
Comment 67 Andrew Schultz 2004-10-20 21:15:32 PDT
*** Bug 263260 has been marked as a duplicate of this bug. ***
Comment 68 Niklas Morberg 2004-11-15 12:48:44 PST
*** Bug 269993 has been marked as a duplicate of this bug. ***
Comment 69 Sean McGuinness 2004-11-16 09:36:40 PST
Hello. At first, I thought I was having a problem with SiteSpinner (a webpage
creation program) but it turns out that it is still a bug in Mozilla/Firefox.
This is a reply I received from Harpo at SiteSpinner tech. supp:

**************

I looked into this and it seems to be a bug in FoxFire when printing absolutely
positioned elements.

For example this simple page will not print correctly:
----------------------
<HTML>

<body >

<div style="position:absolute; left:10px;top:20px;width:197px;height:93px;">
Top</div>

<div style="position:absolute; left:10px;top:1800px;width:197px;height:93px;">
Middle </div>

<div style="position:absolute; left:10px;top:3600px;width:197px;height:93px;">
Bottom</div>

</body>

</html>

**************

And then he refers me to this thread here at bugzilla.

Here is the full thread at SiteSpinner's forum:
SiteSpinner <a
href="http://virtualmechanics.infopop.cc/eve/ubb.x?a=tpc&s=3636038591&f=1246038591&m=796101937&r=828103047&ORIGINAL_REFERRER_URL=http%3A%2F%2Fvirtualmechanics.infopop.cc%2Feve%2Fubb.x%3Fa%3Dtpc%26s%3D3636038591%26f%3D1246038591%26m%3D796101937%26r%3D828103047"
target="_blank">thread</a>.
Comment 70 Boris Zbarsky [:bz] 2004-12-04 13:32:30 PST
*** Bug 271311 has been marked as a duplicate of this bug. ***
Comment 71 Mats Palmgren (vacation) 2004-12-18 19:01:12 PST
*** Bug 274961 has been marked as a duplicate of this bug. ***
Comment 72 Jo Hermans 2005-01-05 09:15:25 PST
*** Bug 277133 has been marked as a duplicate of this bug. ***
Comment 73 Jo Hermans 2005-01-05 09:15:38 PST
*** Bug 274684 has been marked as a duplicate of this bug. ***
Comment 74 Jo Hermans 2005-01-05 09:15:50 PST
*** Bug 276504 has been marked as a duplicate of this bug. ***
Comment 75 Simon Montagu :smontagu 2005-01-19 00:30:34 PST
*** Bug 278952 has been marked as a duplicate of this bug. ***
Comment 76 Boris Zbarsky [:bz] 2005-02-08 17:47:29 PST
*** Bug 280753 has been marked as a duplicate of this bug. ***
Comment 77 Rick Stockton 2005-02-09 13:39:25 PST
Mr. 280753 here, sorry I didn't find the Dup:

But, I'd like to note that the html code for 280753 identifies it's Generator as
 "WebObjects 5.2". Thus, we have already identified both SiteSpinner (Comment
69) and WebObjects as code generators which are KNOWN to generate pages which
fail in Moz/FF.

I don't know if WebObjects has a lot of Market Share, but I think it's
especially bad to fail on valid pages created by such tools.

I also second the loud complaint in  Comment 62, don't bother with giving us
workarounds for the HTML code-- this problem is about pages created by OTHER
people, not ourselves.
Comment 78 Leigh Morresi 2005-02-09 13:51:43 PST
Hi there

I dont understand what you mean by a problem created by other people, not
mozilla? How come it doesnt work with mozilla?

leigh

(In reply to comment #77)
> Mr. 280753 here, sorry I didn't find the Dup:
> 
> But, I'd like to note that the html code for 280753 identifies it's Generator as
>  "WebObjects 5.2". Thus, we have already identified both SiteSpinner (Comment
> 69) and WebObjects as code generators which are KNOWN to generate pages which
> fail in Moz/FF.
> 
> I don't know if WebObjects has a lot of Market Share, but I think it's
> especially bad to fail on valid pages created by such tools.
> 
> I also second the loud complaint in  Comment 62, don't bother with giving us
> workarounds for the HTML code-- this problem is about pages created by OTHER
> people, not ourselves.
Comment 79 Rick Stockton 2005-02-11 16:40:44 PST
Leigh, let me rephrase, I'm a very poor writer.

The issue which I attempted to highlight is that another HMTL code generating
tool (WebLogic) has been found to create valid HTML code which exposes this
critical Mozilla defect, resulting in lost data upon printing. (SiteSpinner was
identified by Sean in comment #69).

Thus, the workaround "how to patch up your HTML by avoiding absolute positioning
tags" is even --LESS-- helpful, because the page authors arent' even coding
HTML... they're using a GUI tool to create the layout tags for them.

The problem is not created by other people (it's in Mozilla), but the Web pages
which expose OUR problem are under the control of other webmasters and authors,
and we can't --MAKE THEM-- fix their pages to work with Moz/FF. )Because their
pages are OK!!).

Likewise, WebLogic would be taking a very reasonable business step by dropping
the issue after showing that it is OUR bug. (Just as SiteSpinner did.) Since
their code generating tool is generating VALID HTML, their software hasn't got a
defect wich needs to be fixed. Asking them to "fix" their software so that it
hides -OUR- defect might work if we had overwhelming market share, or a special
business relationship, but typically deserves a polite but firm "No, it's your
problem.".

I understand the attractiveness of maybe waiting for 2.0 (Suite and FF) for this
large layout redesign, but I think that all victims agree: It is 100%
UNACCEPTABLE to present our Products as "World Class" Browsers while loosing
data in such a horrible way on printouts.

On Windows, most of us resort to IE, our favorite product of Monopoly Extension
by Criminal Means. (We just love to use it, NOT!!). On Linux, I resort to
Konqueror, not a "bad" thing, but a reminder that my favorite just really isn't
up to the job of being a W3C Web Browser.

Comment 80 Leigh Morresi 2005-02-13 16:35:30 PST
is "absolute positioned div" styling part of the CSS standard?
Comment 81 Damian Yerrick 2005-02-14 13:23:18 PST
div#navbar { position: absolute; /* ... */ }

Of course it's part of the CSS 2.x standard.
Comment 82 Wells 2005-03-22 08:01:03 PST
Here is another web page URL http://www.pouliadis.gr/autodesk/aad.htm that
suffers dataloss on printing and print view in Firefox v1.0.1, yet prints and
views all four pages in IE 6.  The page is full of absolute positioning and only
the first page is printed or viewed in Firefox.  After reading all the previous
comments, I concur that this type of print error should not have been allowed in
a v1+ release.  It is not what one expects from a stable version when using
correctly apparently formed CSS code ESPECIALLY since it was first reported
almost three years ago!  I hope that some resources are devoted to fixing it as
I believe I lack the skill level to tackle this type of bug.

On the side, as this was the first bug I attempted to report, I will say that
although the number of hoops required to get here was frustrating, I was
impressed that I located this bug thread relatively quickly.
Comment 83 Boris Zbarsky [:bz] 2005-03-29 16:20:27 PST
*** Bug 205486 has been marked as a duplicate of this bug. ***
Comment 84 Steve England [:stevee] 2005-04-02 04:16:50 PST
*** Bug 288635 has been marked as a duplicate of this bug. ***
Comment 85 Kevin Brosnan 2005-04-02 17:53:52 PST
*** Bug 265355 has been marked as a duplicate of this bug. ***
Comment 86 Jo Hermans 2005-04-07 04:21:43 PDT
*** Bug 289414 has been marked as a duplicate of this bug. ***
Comment 87 Tim Richardson 2005-04-10 03:20:33 PDT
*** Bug 266504 has been marked as a duplicate of this bug. ***
Comment 88 Martijn Wargers [:mwargers] (not working for Mozilla) 2005-04-15 13:56:25 PDT
*** Bug 290503 has been marked as a duplicate of this bug. ***
Comment 89 Jo Hermans 2005-05-03 07:15:58 PDT
*** Bug 292716 has been marked as a duplicate of this bug. ***
Comment 90 Jo Hermans 2005-05-03 07:19:04 PDT
*** Bug 248440 has been marked as a duplicate of this bug. ***
Comment 91 Jo Hermans 2005-05-03 07:19:18 PDT
*** Bug 267745 has been marked as a duplicate of this bug. ***
Comment 92 Jo Hermans 2005-05-03 07:20:51 PDT
*** Bug 260024 has been marked as a duplicate of this bug. ***
Comment 93 Jo Hermans 2005-05-03 07:24:07 PDT
*** Bug 267709 has been marked as a duplicate of this bug. ***
Comment 94 Iris Macsek 2005-05-04 03:02:52 PDT
Me too, I'vegot the same problem in
http://nic.tuwien.ac.at/
Recently I changed my website to a table-free Layout. Since then only the first
page of my html-pages was printed. As I know that divs that are absolutely
positioned and are longer than one page mean  a problem for FF, I now changed
the positioning
of my div "content" to relative. Now FF prints many pages. But at the bottom of
each side FF tries to print more lines than possible (which does of course not
work) and these lines are missing. 
So my problem is not really solved but has only become smaller!
This bug was first mentioned in 2003! When will it be solved?
Comment 95 Martijn Wargers [:mwargers] (not working for Mozilla) 2005-06-06 17:37:01 PDT
*** Bug 296867 has been marked as a duplicate of this bug. ***
Comment 96 Leigh Morresi 2005-06-06 17:49:30 PDT
Can we start to gather some information about the mozilla codebase to fix 
this? does anyone know why this happens? 
Comment 97 Rick Stockton 2005-06-11 14:41:54 PDT
Although I am not a Developer, I have a mini-status report on this problem:

Deep in the comments of a MozillaZine article, Boris Zbarksy mentions a "REFLOW"
project which Dave Baron has been working on, for possible inclusion in Gecko
1.8 (i.e., Firefox 1.1). It hasn't been merged yet. This re-design is (IIUC)
PREREQUISITE for fixing a bunch of problems in handling table-less layouts, but
doesn't target our problem.

Boris advises "The reflow branch won't really affect splitting of abs pos
frames; it's about doing shrink-wrapping in a better way. At this point, abs pos
splitting is a 1.9-type item." (i.e., Firefox 1.5).

His summary for me was, "briefly, the abs pos splitting bug has in fact fallen
off the earth, more or less. Or more precisely never appeared on the earth...".

It's not that the bug is unknown (he and Dave are aware of it, **don't** fling
email and other s*** at them!!!), but rather that no one has the time or ability
to step up to take on this problem.
Comment 98 Andrew Schultz 2005-06-11 22:18:19 PDT
*** Bug 297423 has been marked as a duplicate of this bug. ***
Comment 99 Martijn Wargers [:mwargers] (not working for Mozilla) 2005-06-19 13:50:32 PDT
*** Bug 298179 has been marked as a duplicate of this bug. ***
Comment 100 Samuel Sidler (old account; do not CC) 2005-06-27 15:38:32 PDT
*** Bug 298946 has been marked as a duplicate of this bug. ***
Comment 101 Jo Hermans 2005-06-29 01:51:18 PDT
*** Bug 299076 has been marked as a duplicate of this bug. ***
Comment 102 Martijn Wargers [:mwargers] (not working for Mozilla) 2005-07-14 00:38:48 PDT
*** Bug 300728 has been marked as a duplicate of this bug. ***
Comment 103 Scott Young 2005-07-22 06:34:27 PDT
For what it is worth, Firefox does not have this problem. Loss of text/pictures
also occurs when creating PDF.
Comment 104 Jon Scaife 2005-07-22 06:48:55 PDT
(In reply to comment #103)
> For what it is worth, Firefox does not have this problem. Loss of text/pictures
> also occurs when creating PDF.

Firefox DOES have this problem - it fails to split any absolutely positioned
element over 2 printed pages.  This is a problem that really should be addressed
as a matter of some urgency as it effects many websites that are designed to
work with the W3C standards
Comment 105 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-07-23 18:17:35 PDT
*** Bug 301880 has been marked as a duplicate of this bug. ***
Comment 106 Adam Guthrie 2005-08-01 17:28:19 PDT
*** Bug 303002 has been marked as a duplicate of this bug. ***
Comment 107 Adam Guthrie 2005-08-01 20:47:31 PDT
*** Bug 302763 has been marked as a duplicate of this bug. ***
Comment 108 Aaron Slunt 2005-08-11 21:03:18 PDT
*** Bug 304399 has been marked as a duplicate of this bug. ***
Comment 109 Samuel Sidler (old account; do not CC) 2005-08-26 10:05:13 PDT
This bug was given topembed+ back in 2002. It's a top100 bug that has been 
duped over 50 times. Is there any reason this shouldn't be fixed in 1.9? (I 
understand it's too late for 1.8, unfortunately.)

Requesting blocking1.9a1.
Comment 110 Boris Zbarsky [:bz] 2005-08-26 10:16:41 PDT
If someone is willing to do the work (even as far as bringing that patch up to
date) that would be quite nice.  Until then, I think it's waiting on someone
having the time to deal with this warren of code.
Comment 111 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-08-26 15:23:45 PDT
I definitely want to get this done for 1.9, but it'll have to wait for the
reflow branch to land. (I'd like to do this in conjunction with refactoring
absolute positioning so any frame can be an abs-pos container.)
Comment 112 Ashley Bischoff (blog at handcoding.com) 2005-08-26 15:33:25 PDT
(In reply to comment #111)
> I definitely want to get this done for 1.9, but it'll have to wait for the
> reflow branch to land. (I'd like to do this in conjunction with refactoring
> absolute positioning so any frame can be an abs-pos container.)

Is there a bug for landing the reflow branch?
Comment 113 Mark Dionne 2005-09-01 20:49:35 PDT
As of 1 Sep 2005, Print Preview hangs using the original URL. (Site changes
constantly though.)
Comment 114 DucemBarr 2005-09-18 07:48:03 PDT
It feel that I encounter this problem more and more often. Now even BusinessWeek
cannot print properly, the text just flows off the first page...

PLEASE SOMEONE HELP & FIX IT!

(It's such a pity when you have to launch IE several times a day, just to get
readable printer output...)
Comment 115 Mark Gordon 2005-09-27 08:13:42 PDT
*** Bug 260069 has been marked as a duplicate of this bug. ***
Comment 116 James Wright 2005-09-29 02:25:45 PDT
We have just encountered this problem when using a css print style sheet to
reposition the content in our page for printing. This bug effectively makes the
print functionality useless with the page content we produce (ie. long schedule
tables). It seems this problem has been around for a long long time, please fix
this...

Comment 117 Jo Hermans 2005-09-30 03:56:42 PDT
*** Bug 310555 has been marked as a duplicate of this bug. ***
Comment 118 Jo Hermans 2005-10-01 03:03:23 PDT
*** Bug 272998 has been marked as a duplicate of this bug. ***
Comment 119 Jo Hermans 2005-10-02 08:37:23 PDT
*** Bug 260423 has been marked as a duplicate of this bug. ***
Comment 120 Adam Guthrie 2005-10-13 21:44:29 PDT
*** Bug 312412 has been marked as a duplicate of this bug. ***
Comment 121 Jo Hermans 2005-10-16 09:37:52 PDT
*** Bug 273780 has been marked as a duplicate of this bug. ***
Comment 122 Jo Hermans 2005-11-09 15:52:02 PST
*** Bug 315763 has been marked as a duplicate of this bug. ***
Comment 123 James 2005-12-02 19:17:55 PST
www.csszengarden.com uses media="screen" to work around this problem. It disables all styles leaving the validated html to be printed.
Comment 124 Robert Parenton 2005-12-10 15:18:09 PST
*** Bug 270827 has been marked as a duplicate of this bug. ***
Comment 125 Jo Hermans 2005-12-12 05:29:48 PST
*** Bug 319931 has been marked as a duplicate of this bug. ***
Comment 126 Sebastian 2005-12-13 22:51:50 PST
FF 1.5 is still defective in the described meanner.
see:
http://www.com-tra.de/shop/de_DE/produkt/id_is_3254_and_Chieftec_MESH_CA-01B-B-SL_Big-Server_ATX_schwarz_solo.html
for another webpage with teh problem.
Comment 127 Jens O. Meiert 2005-12-14 02:40:39 PST
OT: This is the most incredible bug here, and in any commercial context, it would already have been fixed in 2002 (yeah, this bug is old). Meanwhile, it is a reason to switch the browser (again).
Comment 128 Mike Connor [:mconnor] 2006-01-05 14:11:56 PST
bumping nom to core noms
Comment 129 Wayne Mery (:wsmwk, NI for questions) 2006-01-08 05:00:10 PST
*** Bug 127527 has been marked as a duplicate of this bug. ***
Comment 130 Knud Berggreen 2006-02-04 00:52:48 PST
I just get a new version (1.5.0.1) and this bug is still not fixed!

I still just get the first page out of four when printing.

It is really i BIG problem. Firefox will never be THE browser with such a bug. This bug should have been solved for loooong time ago!
Comment 131 Henrik Ræder Clausen 2006-02-04 00:59:52 PST
Yes, this is just embarrasing. At 1.0, I was recommending Firefox for better printing than IE - but then I found this, and had to stop. It's a stain on the Open Source process that's supposed to fix bugs faster.

Strangely, people don't seem to vote very much for this one - only 97 votes total?
Comment 132 Joe Veler 2006-02-11 15:39:54 PST
When I first looked at this bug, I figured that someone had fixed it, and then they just didn't get it right... given that it was opened in June of '02.  I just finished a site and was doing thorough testing cross-browser... and my issue is the same as all others described.

I have my "content" inside the template and when I want it to print, I use a separate stylesheet for media="print".  In this print media stylesheet, I hide the main table of the document "visibility: hidden;" and then "unhide" the content.  The DIV that this content is in is then absolutely positioned at 10 left, 10 top and the width is increased so it will print the width of a standard 8.5x11 sheet of paper.

Works fine in IE, and then BLAM... Firefox renders page 1 of 1, with text scrolling off the preview on the bottom.  In IE, there are 4 pages that DO print.  So, looking in the comments... it looks like "splitting of absolutely positioned div's" is still not fixed.  

I'm not a programmer sophiscated enough to fix this bug... I just know basic javascript, HTML and css.  But I will sing the high praises of Allah to he who can take on this bug and finally get it to work.  From looking at this... I don't even think someone IS working on it?

Well, I hope my Vote... to make it 108 FOR FIXING THE BUG... helps out and that we can get this escaleted enough for it to make it into the next release... hopefully sometime this decade.  Please view this simply as a legitimate plea to get this bug fixed.
Comment 133 Jamie 2006-02-13 14:15:22 PST
I believe this bug is also causing your own bug tracker to print improperly! :)

https://bugzilla.mozilla.org/page.cgi?id=fields.html#status

I was trying to print out the page which cut off the status/resolution table.  When I disabled all the CSS styles using the Webdeveloper toolbar it print previewed /printed ok.  

It's strange that firefox 1.5.0.1 can view all of these pages correctly, yet cannot print them?  Isn't the printer supposed to be just another GDI device that you're rendering to? Although I suppose the pagination issue applies..

Please fix asap! I hate blank pages!
Comment 134 Darren Robinson 2006-02-13 17:09:48 PST
*** Bug 325388 has been marked as a duplicate of this bug. ***
Comment 135 :Mook 2006-02-13 23:55:58 PST
*** Bug 327112 has been marked as a duplicate of this bug. ***
Comment 136 Darren Robinson 2006-02-14 03:44:50 PST
Interestingly i have just converted my page to relatively positioned elements and yet i still get the rendering problem. the page contains divs only, no tables. A float, and some overflow:hidden divs. It still renders correctly, but still doesnt output correctly. I get the header div, the main and float div, then the footer div on three different pages with lots of white space. the main and float print on the same page but are cliped at the page boundary, it should extend for antother page at least. This bug doesnt seem to just affect absolutly positioned DIVs, anyone else experimented with this?

One last note on this, just removed the all the overflow attributes, and found that the page 'prints' almost correctly, only the float is in the wrong place... maybe this affects the overflow attribute not the possition attribute?!
Comment 137 Darren Robinson 2006-02-14 04:34:38 PST
Have reopened Bug #325388 as it will help keep different, even if related, bugs appart - preventing cross contamination.

NOTE: this bug (Bug# 154892) does not affect absolutly positioned divs that are contained within the print page boundary, as the issue reported in Bug #325388 demonstrates. The absolutley positioned div i have my navigation in prints fine in stitue with the rest of the pages content, but only if overflow is not set.
However, the test cases shown in the attachments result in different behaviour.

1) The ESPN case outputs only a blank page, yet no overflow (or even media type) is set and there is only simple layout absolute positioning, positioning it beyond the first page boundary, and hence firefox never prints.

2) the Kin test case, renders correctly on print out, but occupies only one page so doesnt demonstrate the bug. The bug only seems to occur, from experience, if content is beyond the print page boundary.

3) demonstrates the bug excellently, clipping the content of the possitioned div at the print page boundary.
Comment 138 dolphinling 2006-02-19 03:09:51 PST
*** Bug 327736 has been marked as a duplicate of this bug. ***
Comment 139 Aaron Lawrence 2006-02-19 06:31:05 PST
65 or so dupes so far ... 
Comment 140 Smokey Ardisson (offline for a while; not following bugs - do not email) 2006-02-23 23:53:18 PST
*** Bug 328123 has been marked as a duplicate of this bug. ***
Comment 141 Tim Richardson 2006-03-07 13:51:34 PST
Singapore Airlines website also has this bug when a trip itinerary is more than one page. So I told my wife to copy and paste itinerary options into MS Word and print from there. This is a horrible old wrinkly bug. 
Comment 142 :Gavin Sharp [email: gavin@gavinsharp.com] 2006-03-25 21:19:29 PST
*** Bug 330880 has been marked as a duplicate of this bug. ***
Comment 143 froodian (Ian Leue) 2006-05-08 15:34:01 PDT
*** Bug 337183 has been marked as a duplicate of this bug. ***
Comment 144 marcus pullen 2006-05-23 01:14:37 PDT
I confirm - printing fails. I was using an HP Deskjet 9300. I checked the drivers and other apps were handling printing just fine. When I use the print command it seems to spool the document. the printer goes through the motions but I get nothing on the page. This affects printing from ANY site not just ESPN.
Comment 145 Knud Berggreen 2006-06-04 01:18:11 PDT
This problem has been there since version 1.0
I do not understand why this not is solved yet?
Why did correct printing not have a very high priority?
Comment 146 Wayne Mery (:wsmwk, NI for questions) 2006-06-04 02:00:50 PDT
Robert O'Callahan (Novell) comment #111:
> I definitely want to get this done for 1.9, but it'll have to wait for the
> reflow branch to land. (I'd like to do this in conjunction with refactoring
> absolute positioning so any frame can be an abs-pos container.)

bz, roc, which bug is this?  And shouldn't it be set to block this bug?  Bug 261196?
Comment 147 Darin Fisher 2006-06-13 16:32:56 PDT
Not going to happen for 1.8.1 (dbaron says it is way too risky at this point).
Comment 148 Leigh Morresi 2006-06-13 16:45:12 PDT
I dont get it, mozilla are making 10's of millions of $dollars a year and yet cant put the resources towards solving one of its oldest bugs, and a very important one (tag top100+)

This raises serious concerns about mozilla/firefox's resource allocation and management strategies.

http://www.technoogle.com/?p=408

http://news.zdnet.com/2100-9588_22-6048377.html

This is typical immature opensource attitude, i dont believe you would expirience this bug in a commercial web browser because there would be an organised company behind it, feeding customer feedback directly into the development team to make a solid product that attracted more buyers becuase it simply worked, rather than adding frivolous features and avoiding focusing on core bugs while still making tens of millions of dollars a year from one of its flagship products.

I reject the attitude of "oh well its broken, fix it yourself, read the source code", mozilla CAN afford to fix it, but they are more interested in feature development than cleaning up its top100 bugs.
Comment 149 Jo Hermans 2006-06-18 09:56:27 PDT
*** Bug 341936 has been marked as a duplicate of this bug. ***
Comment 150 Chris C 2006-06-29 11:30:57 PDT
I have the same problem and i'm not using the keyword "absolute" anywhere in my stylesheets.

see: http://hitech.lead2gold.org/view_teams.php
I'm using liquid style columns and (as everyone has stated already) only FireFox has a problem printing more then 1 page.

I didn't create a new bug because i'm assuming its still related to this one?
Comment 151 Bill Gianopoulos [:WG9s] 2006-06-29 12:02:10 PDT
(In reply to comment #150)
> I have the same problem and i'm not using the keyword "absolute" anywhere in my
> stylesheets.
> 
> see: http://hitech.lead2gold.org/view_teams.php
> I'm using liquid style columns and (as everyone has stated already) only
> FireFox has a problem printing more then 1 page.
> 
> I didn't create a new bug because i'm assuming its still related to this one?
> 

Your page contains:

<div id="overDiv" style="position:absolute; visibility:hidden; z-index:1000;"></div>

This is exactly what this bug is about.
Comment 152 Eli Friedman 2006-06-29 14:13:23 PDT
Chris, the bug on your page is bug 324956, not this one.

There are many bugs that cause the symptom of cut-off content.  If you have a webpage that doesn't work and you don't have a simplified testcase (see http://www.mozilla.org/newlayout/bugathon.html#testcase), please create one.  If you're unable to do that, go ahead and file a new bug anyway.  But don't comment in current bugs if you're not sure your page shows that bug.  Many layout bugs have similar symptoms when the causes are completely different.

Bill, when you're going to try and diagnose a page, you actually have to create a simplified testcase, not just skim the source code looking for relevant keywords.  See http://www.mozilla.org/newlayout/bugathon.html#testcase .

Sorry if I sound a bit harsh; I know Bugzilla can be hard to figure out.  Thanks for trying to help out.
Comment 153 Bill Gianopoulos [:WG9s] 2006-06-29 16:50:33 PDT
(In reply to comment #152)
> Chris, the bug on your page is bug 324956, not this one.
> 
> There are many bugs that cause the symptom of cut-off content.  If you have a
> webpage that doesn't work and you don't have a simplified testcase (see
> http://www.mozilla.org/newlayout/bugathon.html#testcase), please create one. 
> If you're unable to do that, go ahead and file a new bug anyway.  But don't
> comment in current bugs if you're not sure your page shows that bug.  Many
> layout bugs have similar symptoms when the causes are completely different.
> 
> Bill, when you're going to try and diagnose a page, you actually have to create
> a simplified testcase, not just skim the source code looking for relevant
> keywords.  See http://www.mozilla.org/newlayout/bugathon.html#testcase .
> 
> Sorry if I sound a bit harsh; I know Bugzilla can be hard to figure out. 
> Thanks for trying to help out.
> 

You're absolutely correct.  I saved the page and removed the absolutely positioned div and it still does not print the second page.  I should have tried this before replying.  My bad.
Comment 154 Gregr 2006-07-28 01:30:58 PDT
Here's the workaround I use for this bug
As it's not possible (unfortunatlly) to fix code on all the sites on www I use user style sheet
Content of <profile>/chrome/userContent.css :
@media print {
 	* {
 	position: relative !important;
 	}
} 

Print include sometimes a lot of white space but all the content is printed (no more dataloss).
It's a workaround not a real fix
Comment 155 James Napolitano 2006-08-27 14:19:25 PDT
(In reply to comment #146)
> Robert O'Callahan (Novell) comment #111:
> > I definitely want to get this done for 1.9, but it'll have to wait for the
> > reflow branch to land. (I'd like to do this in conjunction with refactoring
> > absolute positioning so any frame can be an abs-pos container.)
> 
> bz, roc, which bug is this?  And shouldn't it be set to block this bug?  Bug
> 261196?
> 

The reflow branch is described at http://wiki.mozilla.org/Gecko:Reflow_Refactoring, where you can check on its status.  Reflow refactoring is one of several major architectural changes the Mozilla developers are hard at work on on the trunk (to be Gecko 1.9 and Firefox 3.0).  These changes will simplify the codebase, fix bugs, and make bugs like this one much easier to fix.  Mozilla's printing code has been neglected for far too long, yes, but there are plans to fix this in 1.9.  See for example the comments in Bug 331415.
Comment 156 Jo Hermans 2006-08-30 07:30:40 PDT
*** Bug 350709 has been marked as a duplicate of this bug. ***
Comment 157 Knud Berggreen 2006-09-16 08:23:49 PDT
I just get a new version (1.5.0.7 - Danish) and this bug is still not fixed!

I still just get the first page out of four when printing.

It is really i BIG problem. Firefox will never be THE browser with such a bug.
I still think that this bug ought to have been solved for loooong time ago!
Comment 158 Pavel Antiperovitch 2006-09-16 20:02:46 PDT
indeed, not being able to print more than one page w/ absolute elements is quite a large problem.
Comment 159 Matt 2006-10-05 11:16:12 PDT
This URL also has the problem:
http://butunclebob.com/ArticleS.UncleBob.CleanCodeArgs

IE6 and IE7 do a better job, with the first 4 pages being blank and the other 20 pages being okay. Safari and Konqueror both work correctly.

I'll pay $100 for this to be fixed in 2.0 or 2.0.1 with an automated test added that fails when the bug is present and passes when the bug is fixed.
Comment 160 Scott Willeke 2006-10-05 14:45:17 PDT
I'll add another $100 to mozilla.com/org if this bug is fixed in 2.0 or 2.0.1 and has an appropriate regression test.
Comment 161 Craig Reynolds 2006-10-05 15:05:02 PDT
Sorry for the off-topic observation, but it is pretty ironic that the content of the page Matt mentions (as exhibiting the symptom of this bug) happens to pretty well describe why this bug has gone unfixed for four years, and why it would "cost" significantly more than $200 to fix.

Disclaimer: I'm no expert but that is what I have gleaned from listening to many comments on this bug.
Comment 162 Pavel Antiperovitch 2006-10-05 15:41:49 PDT
regardless, it should be fixed, it's a pretty big one that limits quite a bit.

It's very upsetting to see such a big bug present, and no big rush to fix it.
Comment 163 Wayne Mery (:wsmwk, NI for questions) 2006-10-05 15:48:06 PDT
*** Bug 270291 has been marked as a duplicate of this bug. ***
Comment 164 Scott Willeke 2006-10-05 16:09:11 PDT
Just to be clear I offer to contribute money for the fix with great respect for Mozilla and especially for the developers of the products. I am not trying to trivialize the complexity of the solution by offering "only" $100 to have this _bug_ fixed (in a "free" product). I have reviewed the related code and know that the solution is not trivial.

I also think Mozilla has more motivation than just $200 to fix a four year old bug. It is a bug that is very noticeable and common, with 124 votes, and it works in competing products; including Safari/Konqueror (based on comments in this post), and Microsoft Internet Explorer (reasonably well in most cases).

Above all else, I think offering financial incentives -however small- is an equitable and respectful way to ask for a fix or feature. Especially for open source products.
Comment 165 Andreas Lange 2006-10-08 13:14:21 PDT
Just to point it out and spare ourselves some comments: this will not be fixed in Firefox 2.x!

Comment 110 and comment 111 contains the latest status for this bug. Any work here is pointless until the reflow rewrite branch (see comment 155) lands. This is slated for Gecko 1.9, which will be the basis for Firefox 3. 

Firefox 2 is available as Release Candidate now. The stage when messy changes to the core layout engine (as a fix to this bug requires) should be made passed something like half a year ago.

Offering financial incentive is not a bad idea. But there is no point in making it limited to Firefox 2 when it by far is too late.





Comment 166 Wells 2006-10-13 14:21:52 PDT
While I wish I had the skills necessary to fix a bug like this I don't,
but I have hung around now a year and a half to see what would happen
and I find this bug an excellent case study in the Cathedral and Bazaar
model of software development.  It seems to defy traditional claims that
the bazaar model is a superior development model when it comes to fixing
top100 rated bugs.  The wider community has not hunkered down and come
up with a fix to this critical printing problem. Now the bug fix is slated 
for Firefox 3, if we should be so lucky.  Keep up the good work!

Comment 167 philippe (part-time) 2006-10-21 18:33:45 PDT
*** Bug 357483 has been marked as a duplicate of this bug. ***
Comment 168 Jim Scott 2006-11-02 20:16:44 PST
As may have been reported but I missed it ... in plain language for those of us who know just enough to be dangerous ...

Yahoo! has again changed its coding (we oldtimers remember last time they locked out Netscape printing altogether). Now, printing any Yahoo! email with more than one page of text in the message will cause the print to just run off the page. For example, a message with 1-3/4 pages of text shows up in Preview as three pages; a page with just the Yahoo! header (ie, 80% blank), a page with the email message body (with the text just trailing down right through the footer), and the third page with just the header / footer information (ie, none of the email message body prints here).

I haven't done any real coding since C++ came out (and "Hello, World!" went from 4 LINES of code to 4 PAGES of code)!! I suspect my decision was correct.  :-)

Anyhow, just wanted to add my vote. Being a long-time Netscape/FireFox user, I wish I had the time to learn another programming language to help out here but my time is pretty absorbed trying to find full time work out here in the styx.
Comment 169 Maximilian Ruderburg [:max] (Arctic Revolution) 2006-11-21 23:11:24 PST
*** Bug 361471 has been marked as a duplicate of this bug. ***
Comment 170 Darren Robinson 2006-11-22 11:27:23 PST
Please fix this asap, we've all been waiting for a fix to this for a very long time. And yes its still there in Firefox 2 in case you were in any doubt. damn i wish i had kept up my c programming (or is that so passé by now?!).
Comment 171 Darren Robinson 2006-11-22 11:39:20 PST
Surely this bug should be marked with the keyword "conversion" and possibly "arch" as it certainly is preventing easy conversion of otherwise interested parties, and is, according to those i have heard from, an architectural issue within the print handling code.
Comment 172 Eli Friedman 2006-11-25 17:03:22 PST
*** Bug 330719 has been marked as a duplicate of this bug. ***
Comment 173 Worcester12345 2006-11-27 08:13:09 PST
(In reply to comment #171)
> Surely this bug should be marked with the keyword "conversion" and possibly
> "arch" as it certainly is preventing easy conversion of otherwise interested
> parties, and is, according to those i have heard from, an architectural issue
> within the print handling code.
> 

Also add the "polish" key word.
Comment 174 Robert Hofer 2006-12-09 03:17:01 PST
This bug prevents me from installing Firefox on all my customers PC's: i had the intension, to declare FF as the main platform for my intranet business application; its purpose is mainly to produce printouts. 
check this [url]http://www.hofercomputing.ch/downloads/position_absolute.htm[/url]
Comment 175 Robert Hofer 2006-12-09 03:20:41 PST
(In reply to comment #174)
> This bug prevents me from installing Firefox on all my customers PC's: i had
> the intension, to declare FF as the main platform for my intranet business
> application; its purpose is mainly to produce printouts. 
> check this
> http://www.hofercomputing.ch/downloads/position_absolute.htm
> 

Comment 176 Jim Scott 2006-12-09 08:33:22 PST
Since apparently no one dares to wade into the printing engine code mess, may I kindly suggest that the FF2.1 be re-coded to bypass the print engine and call IE's print engine! The IE print engine works. Can't it be called like any other sub-function?

OR

Perhaps the Opera developers would take pity on us poor FF users and share their solution of the problem?

If we are unable to fix the existing code, perhaps we should look to an external solution, eh?
Comment 177 Phil Randal 2006-12-09 09:56:23 PST
(In reply to comment #176)
> Since apparently no one dares to wade into the printing engine code mess, may I
> kindly suggest that the FF2.1 be re-coded to bypass the print engine and call
> IE's print engine! The IE print engine works. Can't it be called like any other
> sub-function?
> 
> OR
> 
> Perhaps the Opera developers would take pity on us poor FF users and share
> their solution of the problem?
> 
> If we are unable to fix the existing code, perhaps we should look to an
> external solution, eh?

See comment #165.  It's not going to get fixed in 2.x.

On the bright side, the Reflow Branch has been checked in to the trunk, so the work on fixing this can proceed.

There really isn't any need for more "me too" comment spams, no matter how frustrating this problem is.
Comment 178 Jim Scott 2006-12-09 14:25:57 PST
(In reply to comment #177)
> (In reply to comment #176)
> > Since apparently no one dares to wade into the printing engine code mess, may I
> > kindly suggest that the FF2.1 be re-coded to bypass the print engine and call
> > IE's print engine! The IE print engine works. Can't it be called like any other
> > sub-function?
> > 
> > OR
> > 
> > Perhaps the Opera developers would take pity on us poor FF users and share
> > their solution of the problem?
> > 
> > If we are unable to fix the existing code, perhaps we should look to an
> > external solution, eh?
> 
> See comment #165.  It's not going to get fixed in 2.x.
> 
> On the bright side, the Reflow Branch has been checked in to the trunk, so the
> work on fixing this can proceed.
> 
> There really isn't any need for more "me too" comment spams, no matter how
> frustrating this problem is.
> 

Thank you for pointing out #165 as I had overlooked that ONE LINE in nearly 200 posts. On the other hand, I don't know exactly what a "me too comment spam" is but I suspect it is unkind. Where I am from, someone who suggests possible work-arounds for otherwise insurmountable problems gets a bonus instead of Bronx cheers. If you haven't got anything nice to say ...
Comment 179 Kenn 2006-12-12 21:31:05 PST
I have a similar problem that I believe is related to this bug.

When I access my company email (Novell's GroupWise) via my corporate web portal, and I try to print an email, Firefox only prints the displayed contents of the window.

If the email text is bigger than the window, it appears within a scrollable window inside of the mail window.  Printing this results in only the displays contents of the window being printed.  Making the window big enough to view the entire message  isn't always possible.

A fix for this would be very nice indeed.

Currently to print it properly, I have to use IE, or enable IEtab for use with the Groupwise corp portal.
Comment 180 Chris Thompson 2007-01-26 04:38:34 PST
Created attachment 252903 [details]
A screenshot of the problem in action.

The printout looks just the same.
Comment 181 Karin van den Berg 2007-02-07 15:45:54 PST
Don't know if it'll help any but I had a CSS file with body { overflow: auto; } (Don't ask me why that was in there, it was 'inherited') that had this problem. Removing that line from the CSS fixed the issue for the concerning page. 
Comment 182 Stuart Morgan 2007-03-04 17:29:20 PST
*** Bug 372594 has been marked as a duplicate of this bug. ***
Comment 183 Merijn 2007-03-08 01:58:46 PST
This bug is still present in 2.0.0.2 :( Why does this still exist after 5 years?
I love Firefox but today I had to tell a big customer to switch back to Internet Explorer because printing is an essential feature of a browser! 

This bug exists with a large table. It flows over the printview. And when I use:

<div style="page-break-after:always"></div>

This is very useful to insert a page break when generating reports with a large table so you can add a header on each page.

Please fix this so I don't have to tell people to switch back to IE for this.
Comment 184 Charley 2007-03-21 08:39:49 PDT
I also experienced this bug yesterday with 2.0.0.3.  go to http://www.bowflexshop.com/bhg_microsite/products/ultimate2/prdcdovr~115000/Bowflex+Ultimate+2+Home+Gym.jsp , click "Over 95 Exercises" Tab and do print preview. It should be 3 pages, but only shows two.
Comment 185 Nikolaus Rath 2007-03-21 08:50:46 PDT
This is issue is so sad that I can almost laugh about it. 5 years without working printing support. I have had enough.
Comment 186 Ryan VanderMeulen [:RyanVM] 2007-03-21 09:01:05 PDT
To those of you spamming this bug with the "me too" comments, please take a minute to read the Bugzilla Etiquette guidelines.
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

That being said, roc has already said in comment #111 that this is something he wants fixed for Gecko 1.9, which is what will be the core of Firefox 3.0. In other words, the likelihood of a fix ever showing up in Firefox 2.0.x is extremely low - basically zero.  Moreover, the complete lack of useful discussion in this bug should indicate to those with the "me too" comments that nothing has been done to fix this bug, which means it's pointless telling everybody who's CCed to or voted for this bug that you still see it.

They know.

Please, for the sake of all of us who are watching this bug patiently awaiting resolution, stop spamming this bug unless you have something truly useful to say - which at this point basically means "I've got a patch to fix this bug, can somebody review it?"
Comment 187 Chris Lawson (gone) 2007-04-04 07:12:55 PDT
*** Bug 366948 has been marked as a duplicate of this bug. ***
Comment 188 Samuel Sidler (old account; do not CC) 2007-04-30 10:31:38 PDT
*** Bug 379252 has been marked as a duplicate of this bug. ***
Comment 189 Merijn 2007-05-02 04:30:03 PDT
I found a (dirty) workaround.

If you want to print multiple pages it does work like this:

<html>
<body>Page 1</body>
</html>
<div style="page-break-after: always"></div>
<html>
<body>Page 2</body>
</html>
<div style="page-break-after: always"></div>
<html>
<body>Page 3</body>
</html>

I hope this is useful for someone else too.

Best regards,

Merijn
Comment 190 fantasai 2007-07-09 01:24:29 PDT
So, I can't fix this properly before the 1.9 freeze, but I can write a hack using the infrastructure in bug 379349 that'll at least let us paginate abspos elements that appear on the first page. z-order is pretty much guaranteed to be wrong unless roc has some brilliant ideas for it, and there might be some other quirks, but it should be enough for at least getting content on paper for most problematic real-world pages. I've got a prototype in my tree right now: it needs more testing, but I can paginate the testcases here and the websites reported in most of this bug's duplicates.

(Bug 265197, bug 276504, and bug 260024 seem to have z-order troubles; bug 273780, bug 270827, bug 319931, bug 3601471, and bug 379252 still truncate, quite possibly due to tables or overflow settings. The rest either return 404, have adopted a print style sheet, or otherwise paginate properly in my build.)

Requesting blocking status; if drivers consider this is worth taking on for 1.9m7, I'll write up more testcases and a revised patch. Otherwise I'll have to postpone this to another release cycle. Note that what I have here does require the fix to bug 379349, which is a significant change to how we create frame trees for overflowing content.
Comment 191 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2007-07-12 20:52:13 PDT
It's still [wanted-1.9] and not blocking.  The triage of Layout bugs is just me and roc; I'm not sure what you meant by renominating, actually.
Comment 192 Mats Palmgren (vacation) 2007-08-09 10:23:41 PDT
*** Bug 391521 has been marked as a duplicate of this bug. ***
Comment 193 al wilson 2007-08-09 13:26:40 PDT
How about adding another bug heading for "printing" instead of using General?
Comment 194 fantasai 2007-08-09 13:34:36 PDT
Created attachment 276026 [details] [diff] [review]
first pass

So, here's what I'm looking at right now. This is a pretty hacky way of handling these frames: it basically stuffs abspos frames' continuations into the overflow containers list. I haven't yet checked that it doesn't leak or anything.
Comment 195 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2007-08-09 14:58:53 PDT
+  // Because positioned frames have a view, we don't need to repaint

This isn't true anymore (although I know you're not changing anything but the comment). We don't have views for abs-pos frames anymore, in general. There may be a repainting bug here.

+        //XXXfr This is a temporary hack to fix some of our printing dataloss.

What's inadequate about it? Are we not getting the right width for the continuation because it's not being reflowed as an abs-pos frame?
Comment 196 fantasai 2007-08-09 15:38:27 PDT
>  There may be a repainting bug here.

Ok

> What's inadequate about it?

The z-order is probably thoroughly mishandled, and will be even more if we start handling abpos frames that are positioned entirely off the first page.
We also don't have a way to distinguish between normal abspos continuations and true abspos overflow container continuations, which means borders wind up in the wrong places.. although I'm in the middle of tweaking that so it's placed correctly in most cases at least. I haven't really looked into the size/position implications yet, so I can't say what problems we might have there. All I know is that it works well enough for most cases and is a lot better than not printing anything.

I don't know yet what the right way to fix abspos pagination is. I tried looking into that yesterday, and gave up when it seemed like it might mean significantly reworking nsAbsoluteContainingBlock. 
Comment 197 mwu4 2007-08-15 09:50:46 PDT
*** Bug 392298 has been marked as a duplicate of this bug. ***
Comment 198 fantasai 2007-08-17 14:33:52 PDT
Created attachment 277148 [details]
dynamic testcase (multi-col)
Comment 199 fantasai 2007-08-17 16:28:47 PDT
Created attachment 277175 [details] [diff] [review]
patch pass 2

I've got two questions
  1. What should I do about that views comment? Should I be calling an
     invalidate function or just deleting the comment?
  2. The abpos continuations, which are in the overflow containers list, aren't
     painting correctly in the dynamic test case. I know they paint correctly
     in the equivalent test for non-abspos overflow containers, so I don't think
     it's an invalidation problem. My best guess is that there's something wrong
     with nsContainerFrame::DisplayOverflowContainerChildren. I remember you
     saying that the abspos frames need to be in a special display list?
Comment 200 Eli Friedman 2007-08-17 16:40:29 PDT
> I've got two questions
>   1. What should I do about that views comment? Should I be calling an
>      invalidate function or just deleting the comment?

I think you can just get rid of it... abs. pos. frames haven't had views for a while, and nobody has filed any bugs.
Comment 201 fantasai 2007-08-23 14:54:49 PDT
Created attachment 277955 [details] [diff] [review]
patch
Comment 202 Eli Friedman 2007-08-23 15:41:35 PDT
Comment on attachment 277955 [details] [diff] [review]
patch

>   if (IsFrameSpecial(aFrame))
>     aFrame = GetIBContainingBlockFor(aFrame);
> 
>-  mPresShell->FrameNeedsReflow(aFrame, nsIPresShell::eStyleChange,
>-                               NS_FRAME_IS_DIRTY);
>+  do { // Abspos continuations don't get reflowed otherwise
>+    mPresShell->FrameNeedsReflow(aFrame, nsIPresShell::eStyleChange,
>+                                 NS_FRAME_IS_DIRTY);
>+    aFrame = aFrame->GetNextInFlow();
>+  } while (aFrame && (aFrame->GetStateBits() & NS_FRAME_OUT_OF_FLOW)
>+                  && (aFrame->GetStateBits() & NS_FRAME_IS_OVERFLOW_CONTAINER));
>+    //XXXfr revisit this loop/condition when removing float placeholder continuations

If you're doing style re-resolution correctly, this really shouldn't be needed, I think.

>+  // A continuation of an out-of-flow is also an out-of-flow
>+  if (aFrame->GetStateBits() & NS_FRAME_OUT_OF_FLOW) {
>+    newFrame->AddStateBits(NS_FRAME_OUT_OF_FLOW);
>+  }

Where did we do this before (at least for floats)?

>+    // First remove aFrame's next in flow
>+    nsIFrame* nextInFlow = aFrame->GetNextInFlow();
>+    if (nextInFlow) {
>+      nsBlockFrame::DoRemoveOutOfFlowFrame(nextInFlow);
>+    }
>+    // Now remove aFrame
>     // This also destroys the frame.
>     block->RemoveFloat(aFrame);
>   }

Recursing over flow continuations isn't really a great idea; I won't make you change it, though, because it would be messy to fix here.

>-          !!(aFrame->GetStateBits() & NS_FRAME_IS_OVERFLOW_CONTAINER));
>+          !!IS_TRUE_OVERFLOW_CONTAINER(aFrame));

Nit: you don't need the !! for IS_TRUE_OVERFLOW_CONTAINER; it already returns a boolean.

>+      //XXXfr I don't think this is supposed to be necessary, but my testcase fails without it. Help?
>+      frame->Invalidate(frame->GetOverflowRect());
>+

>+  aNextInFlow->Invalidate(aNextInFlow->GetOverflowRect());
>+

I don't know if these are correct.  You might need to check somewhere around here if the frame has moved.

>+    while (oofFrame->GetPrevInFlow())
>+      oofFrame = oofFrame->GetPrevInFlow();
>+  }

Nit: use GetFirstInFlow().

It would be nice to know why style re-resolution isn't re-reflowing/repainting the abs-pos continuations without extra hackery.

Also: please use diff's -p option in the future; it makes reviewing a bit easier.
Comment 203 fantasai 2007-08-24 11:27:24 PDT
Created attachment 278092 [details] [diff] [review]
patch -up12

>  please use diff's -p option in the future

Sorry, I forgot. Here's an update (also fixes your two nits).

>If you're doing style re-resolution correctly, this really shouldn't be needed,

Then I'm not doing style re-resolution correctly. The dirty bit is not getting set on continuations without this loop here, and additionally the abspos first-in-flow blockFrame wasn't returning NS_REFLOW_NEXTINFLOW.

>Where did we do this before (at least for floats)?

nsCSSFrameConstructor::CreatePlaceholderFrameFor

I think I'd like to define a bitmask for bits that get inherited to continuations so they all get taken care of in CreateContinuingFrame, but I decided not to do that here.

> You might need to check somewhere around here if the frame has moved.

The problem I'm running into is that creating a continuation doesn't cause it to be invalidated. The continuation gets reflowed correctly, but its overflow rect doesn't get invalidated for some reason. This works fine for normal overflow continuations, though.
Comment 204 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2007-08-30 23:50:00 PDT
     if (mSkipOverflowContainerChildren) {
       while (cur && (cur->GetPrevInFlow()->GetStateBits()
                      & NS_FRAME_IS_OVERFLOW_CONTAINER)) {
         mPrevOverflowCont = cur;
         cur = cur->GetNextSibling();
       }
+      while (cur && (mWalkOOFFrames == cur->GetStateBits() & NS_FRAME_OUT_OF_FLOW)) {
+        mPrevOverflowCont = cur;
+        cur = cur->GetNextSibling();
+      }

I don't understand. If we're supposed to skip overflow container children, shouldn't we just skip them all regardless of mWalkOOFFrames?

+   * by calling ReflowOverflowContainerChildren.) aWalkOOFFrames is ignored
+   * if aSkipOverflowContainerChildren is true.

I think it should be, but it's not :-)

+++ layout/generic/nsFrame.cpp

Down to here...
Comment 205 fantasai 2007-09-02 00:33:58 PDT
Created attachment 279301 [details] [diff] [review]
patch pass 4

New Improved Version

> If you're doing style re-resolution correctly, this really shouldn't be needed

Ok, I tracked down what was happening. I am re-resolving style correctly here; I traced through that. Only the first in flow gets marked dirty. I think what's happening is that the code relies on the first-in-flow requesting reflow for its next-in-flows if necessary, and that's not happening here. It wouldn't happen for normal overflow containers either, except they currently trigger a REFLOW_NEXTINFLOW in the pull-up code where they shouldn't. (It's marked XXXfr, iirc.)

Updated the invalidation handling. I didn't try to optimize it like in nsBlockFrame; I can try if that's important here.

>> aWalkOOFFrames is ignored if aSkipOverflowContainerChildren is true.
> I think it should be, but it's not :-)

Uh, the comment lied. s/true/false/. :)
Comment 206 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2007-09-03 22:39:33 PDT
+        nsRect dirtyRect = oldOverflow;
+        dirtyRect.MoveTo(oldRect.x, oldRect.y);

Don't you mean MoveBy, or better still,
  nsRect dirtyRect = oldOverflow + oldRect.TopLeft();
?

+        dirtyRect = frame->GetOverflowRect();
+        dirtyRect.MoveTo(rect.x, rect.y);

Ditto

Otherwise I think this is OK. What kind of reftests have you got?
Comment 207 fantasai 2007-09-05 19:32:33 PDT
Created attachment 279840 [details] [diff] [review]
patch pass 5

Fixed. I used MoveBy -- I think it's more readable.
Also fixed a reflowStatus error.

My tests so far have been rather ad-hoc. I'll work on converting them to reftests.
Comment 208 fantasai 2007-09-05 19:42:05 PDT
Created attachment 279841 [details]
Multi-Col Interlaced Abspos and Overflow Pagination [reftest-ready]

This is the most complex testcase I have. It's static, though.
Comment 209 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2007-09-05 21:14:33 PDT
Comment on attachment 279840 [details] [diff] [review]
patch pass 5

okay. More tests would be good, of course. I assume you've run reftests to check it doesn't regress anything (that we have tests for).
Comment 210 fantasai 2007-09-07 22:01:08 PDT
Created attachment 280152 [details]
Interlaced Abspos and Overflow Pagination [reftest-ready]
Comment 211 fantasai 2007-09-29 20:03:46 PDT
Created attachment 282870 [details]
Dynamic Interlaced Abspos and Overflow Pagination [reftest-ready]
Comment 212 fantasai 2007-09-29 20:06:19 PDT
Created attachment 282871 [details] [diff] [review]
patch
Comment 213 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2007-09-30 13:34:33 PDT
Can you describe the changes from the last iteration?
Comment 214 fantasai 2007-09-30 14:43:48 PDT
Created attachment 282918 [details] [diff] [review]
diff patch and patch pass 5

Ok, looking at the diff between the latest patch and patch pass 5:

1. Added code to handle overflow container continuations of auto height blocks.

2. Changed pull-up code to not set incomplete status when an untouched NIF is an overflow container. (The correct OVERFLOW_INCOMPLETE status will be set elsewhere.)

3. Tucked a tracker.Finish call in ReflowChild underneath a null check and made sure the tracker was being passed in from ReflowOverflowContainerChildren.

4. Fixed a couple step-forward errors in the tracker and clarified some comments.

5. Passed aState through several functions so tracker.Finish could be called in ReflowBlock.
Comment 215 Phil Ringnalda (:philor, back in August) 2007-09-30 23:47:13 PDT
*** Bug 398106 has been marked as a duplicate of this bug. ***
Comment 216 Jesse Ruderman 2007-10-01 11:18:03 PDT
I've been using this patch for two days and I haven't noticed any bad side-effects.
Comment 217 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2007-10-01 14:24:46 PDT
Comment on attachment 282871 [details] [diff] [review]
patch

Alright, I'm going to approve this. I'd still like Eli to take a look but it'll have to be after the fact.
Comment 218 fantasai 2007-10-01 20:47:54 PDT
Created attachment 283127 [details]
reftests.zip
Comment 219 Reed Loden [:reed] (use needinfo?) 2007-10-01 23:25:15 PDT
This caused lots of red, so bz told me what I needed to change to fix it.

Checking in layout/generic/nsAbsoluteContainingBlock.cpp;
/cvsroot/mozilla/layout/generic/nsAbsoluteContainingBlock.cpp,v  <--  nsAbsoluteContainingBlock.cpp
new revision: 1.94; previous revision: 1.93
done
Checking in layout/generic/nsAbsoluteContainingBlock.h;
/cvsroot/mozilla/layout/generic/nsAbsoluteContainingBlock.h,v  <--  nsAbsoluteContainingBlock.h
new revision: 1.39; previous revision: 1.38
done
Comment 220 fantasai 2007-10-02 00:38:04 PDT
Created attachment 283148 [details] [diff] [review]
final patch

This is the patch that was checked in. It has a slight change from the r+sr'ed patch above, but roc ok'd the change before I checked in:

replaced
+        if (!IS_TRUE_OVERFLOW_CONTAINER(aState.mNextInFlow))
+          NS_FRAME_SET_INCOMPLETE(aState.mReflowStatus);
with
+        if (IS_TRUE_OVERFLOW_CONTAINER(aState.mNextInFlow))
+          NS_FRAME_SET_OVERFLOW_INCOMPLETE(aState.mReflowStatus);
+        else
+          NS_FRAME_SET_INCOMPLETE(aState.mReflowStatus);
Comment 221 fantasai 2007-10-02 00:44:45 PDT
Created attachment 283152 [details] [diff] [review]
follow-up patch

This fixes the problem reed was working around, namely that I'd been using a DEBUG-only variable in one of the conditionals.
Comment 222 fantasai 2007-10-02 08:16:49 PDT
Fix checked in late last night. Thanks everyone~
Comment 223 Jo Hermans 2007-10-04 01:56:37 PDT
*** Bug 398518 has been marked as a duplicate of this bug. ***
Comment 224 Jo Hermans 2007-10-04 02:01:25 PDT
*** Bug 398452 has been marked as a duplicate of this bug. ***
Comment 225 Jeff Walden [:Waldo] (remove +bmo to email) 2007-10-05 13:29:12 PDT
I assume the reftests in the patch cover at least the basic cases where this bustage was happening?  If so, I'm satisfied enough to mark this in-testsuite+.  :-)
Comment 226 Arie Paap [:wildmyron] 2007-10-11 20:26:00 PDT
*** Bug 235157 has been marked as a duplicate of this bug. ***
Comment 227 Jo Hermans 2007-11-14 03:26:14 PST
*** Bug 403750 has been marked as a duplicate of this bug. ***
Comment 228 Kevin Brosnan 2007-12-01 09:08:36 PST
*** Bug 309105 has been marked as a duplicate of this bug. ***
Comment 229 Horace Vallas 2007-12-01 11:30:23 PST
how do we know when this fix is in a release?  for example, https://bugzilla.mozilla.org/show_bug.cgi?id=398106 was marked as a dup of this bug but the problem still exists in 2.0.0.11
Comment 230 Greg K Nicholson [:gkn] 2007-12-01 11:38:08 PST
This will never be fixed in Firefox 2.x; it's fixed on the trunk, which will become Firefox 3.
Comment 231 Ryan VanderMeulen [:RyanVM] 2007-12-01 11:40:17 PST
You can verify it being fixed for 3.0 by downloading 3.0b1 or waiting for the final release.
Comment 232 Frank Wein [:mcsmurf] 2007-12-14 12:57:19 PST
*** Bug 406749 has been marked as a duplicate of this bug. ***
Comment 233 Robert Hofer 2007-12-15 04:29:42 PST
(In reply to comment #231)
> You can verify it being fixed for 3.0 by downloading 3.0b1 or waiting for the
> final release.

i tested it with a reduced testcase on http://www.hofercomputing.ch/downloads/test.htm
with no success: ie shows correct printpreview, firefox 3 beta shows it wrong!
Comment 234 Wayne Mery (:wsmwk, NI for questions) 2007-12-15 05:12:35 PST
fails also fantasai's testcase attachment 280152 [details] from comment 210

and these too, but they aren't reduced testcases so might be due to multiple bugs
http://www.com-tra.de/shop/de_DE/produkt/id_is_3254_and_Chieftec_MESH_CA-01B-B-SL_Big-Server_ATX_schwarz_solo.html
http://butunclebob.com/ArticleS.UncleBob.CleanCodeArgs

Comment 235 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2007-12-16 19:35:34 PST
Please file followup bugs, CC fantasai and mark them blocking 1.9?
Comment 236 earthsound 2007-12-19 08:17:34 PST
Out of curiosity, how is this marked fixed, with Bug 398332 and Bug 399994 open and still blocking this?
Comment 237 Martijn Wargers [:mwargers] (not working for Mozilla) 2007-12-19 09:15:17 PST
Those were regression that were caused by fixing this bug.
The patch that fixed it can cause all kinds of regressions, but still it means this bug is fixed (though ideally, the regression should be fixed also).
Comment 238 Jason Byrne 2008-02-22 11:05:05 PST
This bug is NOT fixed.  I can't believe this thing has been around since 2002 and still unresolved.  I have been watching and waiting for a fix for at least 3 of those years.

Why can every other browser print correctly paginated pages with absolutely positioned elements but not Firefox?  I love Firefox but have to force the users of my software to use Internet Explorer to print--it's silly.
Comment 239 Jesse Ruderman 2008-02-22 11:31:00 PST
Jason, this is fixed on trunk for Firefox 3.  If you're still seeing problems with printing in Firefox 3 Beta 3, please file a new bug report.
Comment 240 Jim Scott 2008-02-22 11:50:55 PST
Hi Jason. You've committed the same "faux pas" that I am famous for. Regardless, we're over the finish line on the actual printing problem and there's just a few heats left before the end of the meet. Let's leave the remaining runners a chance to concentrate on their lanes, ok? ;-)
Comment 241 Jean-Marc Desperrier 2008-05-21 01:46:28 PDT
(In reply to comment #239)
> Jason, this is fixed on trunk for Firefox 3.  If you're still seeing problems
> with printing in Firefox 3 Beta 3, please file a new bug report.

There are *still* some cases seriously broken for printing.
Check this page for example:
http://aviatechno.free.fr/vilgenis/histoire.php

I will not open a new bug, because this page seems to me to be a mix of bug 166836 and of bug 267029 (for both of those bugs, the included testcase is still broken in Fx 3 2008051906)

Also see bug 159914 that has a very simple testcase that shows that now the page break is sometimes miscalculated for the first page (there's about two or tree lines between the first and the second page are not printed at all)
Comment 242 Isaac 2008-10-15 18:37:02 PDT
I still (20081015 Minefield/3.1b2pre) have a problem printing absolutely positioned divs beyond the first page.  Attaching a test case and a pdf of the output.  Incidentally, if I change them to be relatively positioned they still don't print, but do make the print page count go up correctly, as if it's leaving space for them but not showing them.  Attaching example of that too. Both examples print correctly in Webkit and Opera.
Comment 243 Isaac 2008-10-15 18:38:25 PDT
Created attachment 343340 [details]
Prints correctly on first page, then seems to be bunched up on the first line of the second page
Comment 244 Isaac 2008-10-15 18:39:28 PDT
Created attachment 343341 [details]
PDF showing incorrect output of above
Comment 245 Isaac 2008-10-15 18:41:11 PDT
Created attachment 343342 [details]
PDF showing correct output, as printed from Webkit
Comment 246 Isaac 2008-10-15 18:43:08 PDT
Created attachment 343344 [details]
When div position is changed to relative instead of absolute, still doesn't print after first page, but does add extra blank pages
Comment 247 Carsten Book [:Tomcat] 2008-12-30 04:04:55 PST
*** Bug 411033 has been marked as a duplicate of this bug. ***
Comment 248 bruce korb 2009-10-07 12:27:34 PDT
This bug report may be "resolved fix", but I still see it:
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.14) Gecko/2009090900 SUSE/3.0.14-0.1 Firefox/3.0.14
with an admittedly ancient twiki:
 r88 - 23 Jul 2005 - 14:25:53 - TWikiContributor
I got referred here from twiki:
http://twiki.org/cgi-bin/view/Support/FirefoxPatternSkinPrinting
Comment 249 Chris Lawson (gone) 2009-10-07 12:34:13 PDT
Bruce, since that's a version of Firefox that supposedly has the fix in it, could you come up with a reduced testcase (or even a non-reduced testcase) and file a new bug? It sounds like either the Twiki page refers to the wrong bug (there are a couple Core bugs about this sort of failure to print, and I believe at least one of them has to do with tables, whereas this is frames) or something truly isn't fixed.
Comment 250 Jim Ronback 2009-10-07 13:07:00 PDT
With Firefox 3.5.3 on Windows XP Pro SP3 when trying to print this long web page from: 
http://www.theregister.co.uk/2009/10/05/fraudulent_paypay_certificate_published/print.html
only the first page is printed as 1 of 1.
When I go to the "print story" icon on the top of the page it correctly prints all 3 pages, but with different layout of the ads.
In IE 8.6001.18702 it correctly prints 2 pages with no ads.

The problem is NOT Resolved.
Comment 251 bruce korb 2009-10-07 13:20:32 PDT
bug 521068 has been added to the database
Comment 252 Chris Lawson (gone) 2009-10-07 13:32:55 PDT
Thanks, Bruce.

Jim, please file a new bug for comment 250, too. It's almost certainly not this bug, although I haven't looked at the page code to confirm yet.
Comment 253 Jean-Marc Desperrier 2009-10-08 04:23:56 PDT
We need to stop the spam on this bug.

I understand why there's so much spam. The bug currently is handled partly a a feature bug that is *solved*, and partly as a META bug, which has *many* *unsolved* problem.

I just created the bug 521204 as a new META for page splitting problems.
I'm redirecting the whole meta aspect to bug 521204, which includes a few instruction for triagging page splitting related problem.
Comment 254 nicks_bugzilla 2010-02-11 10:02:57 PST
this definitely is not fixed in ff 3.6.  it works fine in ie 8.  seems pretty simple.  especially since its been here since 2002.
Comment 255 Chris Lawson (gone) 2010-02-11 10:07:16 PST
(In reply to comment #254)
> this definitely is not fixed in ff 3.6.  it works fine in ie 8.  seems pretty
> simple.  especially since its been here since 2002.

Unless you can provide a testcase that demonstrates exactly the problem fixed here, please do not comment on this bug.
Comment 256 nicks_bugzilla 2010-02-11 11:51:19 PST
Sorry Chris, I should have provided more information.  I am not a programmer but I do know a little basic html.  I'm just a firefox user and I'm trying to help some friends and family switch away from Internet Explorer and printing out a page of text is causing a big problem with their acceptance of FF since it works fine in IE.  Opera is not an option since it is unfortunately even less compatible than Firefox.  (Ironically, this issue is not a problem in Opera either.)  

There are a lot of comments above that I do not fully understand, but the website I am trying to print makes use of DIV markers and some CSS, and the symptoms are exactly the same as the first post by  Kevin McCluskey on 2002-06-28, so it certainly seems like the same bug.  The page to be printed consists of a whole bunch of text inside some DIV tags with CSS classes and stuff.  

When you print or print preview it, the first page is fine (slightly cut off on the bottom) but page 2 is entirely empty except for the page header and footer, and no other pages are produced.  The content is not entirely printed.  When printed from Opera or IE 8, four pages (the whole content) print correctly.  

Here is the website I was trying to print: 
http://www.paperblog.fr/551333/biographie-de-jean-genet/

If this is not the right place to post bugs, please advise where I should do so or what process I should follow to help the mozilla community improve Firefox to a usable level?
Comment 257 Darren Robinson 2010-02-12 10:24:11 PST
Just to let you know this bug (and all the similar printing bugs that are still active) affect all mozilla browsers, not just FireFox (SeaMonkey, etc, all suffer the same, so it would seem that the issue lies somewhere deep-in their shared code base.

Haven't posted here for a long time, but thought I'd let you guys know that I'm still here supporting the project, even if I gave up holding my breath for this to be solved...

I think the print engine might just need scrapping and an alternative swapping in - even if its a really simple one, just for testing to see that the other apis and other hooks are behaving.

Just about to download the latest trunk and have another look at these issues.
Comment 258 Darren Robinson 2010-02-12 11:05:39 PST
Still here in:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100205 SeaMonkey/2.0.3

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a2pre) Gecko/20100211 Minefield/3.7a2pre (.NET CLR 3.5.30729)
Comment 259 Chris Lawson (gone) 2010-02-12 11:09:27 PST
(In reply to comment #258 and comment #257)
> Still here in:
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.7) Gecko/20091221
> Firefox/3.5.7 (.NET CLR 3.5.30729)

Re-read the status whiteboard and my comment 255. Unless you can provide a specific testcase that demonstrates that this bug, as filed, still exists in current nightly builds, DO NOT comment here.
Comment 260 Chris Lawson (gone) 2010-02-12 11:10:54 PST
(In reply to comment #256)
> Sorry Chris, I should have provided more information....

> Here is the website I was trying to print: 
> http://www.paperblog.fr/551333/biographie-de-jean-genet/

You should probably just file a new bug on that site.
Comment 261 Darren Robinson 2010-02-12 12:09:16 PST
Chris:

I presumed that "Gecko/20100211 Minefield/3.7a2pre" was the latest build (the others were included since I have and use them daily!

Downloaded from 
ftp://ftp.mozilla.org/pub/firefox/nightly/latest-trunk/

Tell me if that is not the place to download the latest trunk release.

As for test cases, the last attachment that is attached to this bug
(https://bug154892.bugzilla.mozilla.org/attachment.cgi?id=343344), fails on all of incarnations. As do many of the test cases attached - that is without the issue just posted by,  Jean-Marc Desperrier (as per your comment #260).
Comment 262 Chris Lawson (gone) 2010-02-12 12:37:04 PST
(In reply to comment #261)

> As for test cases, the last attachment that is attached to this bug
> (https://bug154892.bugzilla.mozilla.org/attachment.cgi?id=343344), fails on all
> of incarnations. As do many of the test cases attached - that is without the

That's not the original problem that was filed, and it probably should have been filed as a separate bug as well.
Comment 263 Darren Robinson 2010-02-12 12:50:31 PST
Would it be worth opening another thread for the following attachments, or is there an existing thread that they should be included in?

https://bug154892.bugzilla.mozilla.org/attachment.cgi?id=343340
https://bug154892.bugzilla.mozilla.org/attachment.cgi?id=343344

These do not split the DIVs, but still exhibit the missing page and positioning issues.
Comment 264 Chris Lawson (gone) 2010-02-12 12:54:24 PST
(In reply to comment #263)
> Would it be worth opening another thread for the following attachments, or is
> there an existing thread that they should be included in?
> 
> https://bug154892.bugzilla.mozilla.org/attachment.cgi?id=343340
> https://bug154892.bugzilla.mozilla.org/attachment.cgi?id=343344
> 
> These do not split the DIVs, but still exhibit the missing page and positioning
> issues.

Possibly, but make sure you search first as I strongly suspect that's already filed somewhere.
Comment 265 mwu4 2010-02-13 01:39:30 PST
Please check to see if the testcases in #126, #210, and #211 related to this bug or not, because there is print preview problem in these testcases. Thank you.
Comment 266 mwu4 2010-02-13 07:18:11 PST
(In reply to comment #260)
> (In reply to comment #256)
> > Sorry Chris, I should have provided more information....
> 
> > Here is the website I was trying to print: 
> > http://www.paperblog.fr/551333/biographie-de-jean-genet/
> 
> You should probably just file a new bug on that site.

Sorry, I have filed a similar bug 498223 for the website " http://aviatechno.free.fr/vilgenis/histoire.php ", but there is no response at all. Thank you.
Comment 267 mwu4 2010-02-13 07:25:12 PST
Sorry, again; there is "no solution" at all, not "no response". Thank you.
Comment 268 Brendan Eich [:brendan] 2010-02-13 14:58:36 PST
Please file new bugs for new or even seemingly old *but fixed at least at one point in time* problems -- let this bug rest in peace. Bugs are tools for fixing code, not threads in a forum. Adding comments to resolved bugs does not help new bugs get filed and fixed.

Thanks,

/be
Comment 269 Alpo Värri 2010-06-01 23:34:58 PDT
(In reply to comment #257)
> Just to let you know this bug (and all the similar printing bugs that are still
> active) affect all mozilla browsers, not just FireFox (SeaMonkey, etc, all
> suffer the same, so it would seem that the issue lies somewhere deep-in their
> shared code base.
> 
> I think the print engine might just need scrapping and an alternative swapping
> in - even if its a really simple one, just for testing to see that the other
> apis and other hooks are behaving.

I support the complete checkup of the print engine.

I have been waiting for years to have the printing problems
fixed because every now and then I really need to print things and
often just the first page gets printed. My most recent attempt was
to the page http://www.ideal-ist.net/Countries/GR/PS-GR-4212
which I want to archive as a PDF printout before it disappears.

Alpo Värri, Tampere University of Technology

P.S. Unfortunately those years have gone when I had time
to produce free software myself (EGA2EPS, VGA2EPS) and
I cannot tackle this printing problem myself.
Comment 270 Kevin Bailey 2010-06-09 15:02:09 PDT
How is this marked as RESOLVED FIXED?

Anyway - a WORKAROUND.

When going to print a page do Ctrl-A to select all the text.
Then when printing go to Print Options and tick 'Print Selection Only'

This seems to work OK for me!
Comment 271 Jim Ronback 2010-06-09 16:16:49 PDT
Question for Kevin Bailey on Comment 270 work around. Where do you find print options on Firefox 3.6.3? On my Windows XP and HP 1000 printer dialog there are no print options for printing selected items!!
Comment 272 Kevin Bailey 2010-06-10 03:03:32 PDT
(In reply to comment #271)
> Question for Kevin Bailey on Comment 270 work around. Where do you find print
> options on Firefox 3.6.3? On my Windows XP and HP 1000 printer dialog there are
> no print options for printing selected items!!

Sorry Jim - we're Linux only here!

When printing from FF on Ubuntu we get four tabs of options. One is called Options and the print selected text check box is there.
Comment 273 Kevin Bailey 2010-06-10 03:10:41 PDT
And here is a case where the printing is only printing one page properly and the footer of a second page and that's no matter how many pages should be printed.

Go to:

https://twiki.cern.ch/twiki/bin/view/TWiki/UserDocumentationCategory

in FF 3.6.3 and then select print preview.

This problem is only happening in certain cases - and a slightly older than current version of Twiki seems to be one of those cases.

In Cern's case the version of twiki is

version TWiki-4.3.2, Wed, 02 Sep 2009, build 18148, Plugin API version 1.2

Does this bug need to be re-opened - or is it in fact a different bug which needs to be reported?
Comment 274 Michael Lefevre 2010-06-10 04:01:48 PDT
(In reply to comment #273)
> Does this bug need to be re-opened - or is it in fact a different bug which
> needs to be reported?

There is no value in reopening or commenting on this bug. A bug was fixed here, so by definition any issues that exist in Firefox 3.0 or above are not this bug.  Filing new self-contained bugs mentioning a specific site and a specific issue is what needs to happen, even if the symptoms are similar to the ones discussed here (actually there are already other bugs filed).
Comment 275 Kevin Bailey 2010-06-10 15:54:14 PDT
(In reply to comment #274)
> (In reply to comment #273)
> > Does this bug need to be re-opened - or is it in fact a different bug which
> > needs to be reported?
> 
> There is no value in reopening or commenting on this bug. A bug was fixed here,
> so by definition any issues that exist in Firefox 3.0 or above are not this
> bug.  Filing new self-contained bugs mentioning a specific site and a specific
> issue is what needs to happen, even if the symptoms are similar to the ones
> discussed here (actually there are already other bugs filed).

OK - thanks.

I've added mu comments to bug 279359
Comment 276 Jean-Marc Desperrier 2010-06-11 09:33:12 PDT
I will repeat what I said in comment 253, complementing what Michael said just above. Thanks to those who already follow that procedure.

If you have an incomplete/page splitting printing problem, read meta bug 521204 and follow what it says.

Which means :
- get a look at some of still OPEN bugs that block bug 521204
- if you discover your problem is in fact one of those, add a comment to it with a reference to your test case
- if not, then 
    - open a new bug, 
    - *save the page* on which you have the problem so that it can still be tested later,
    - add a link to the saved copy in the bug or add it as an attachement
    - mark your new bug as blocking bug 521204
    - do *not* add a comment here
Comment 277 bruce korb 2010-06-11 09:39:43 PDT
I'll just track bug 521204

Note You need to log in before you can comment on or make changes to this bug.