Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Splitting Absolutely positioned frames not implemented - Missing second page of content when printing or print previewing this site

RESOLVED FIXED in mozilla1.9beta1

Status

()

Core
Layout
--
critical
RESOLVED FIXED
15 years ago
2 years ago

People

(Reporter: Kevin McCluskey (gone), Assigned: fantasai)

Tracking

(Blocks: 3 bugs, 4 keywords)

Trunk
mozilla1.9beta1
dataloss, testcase, top100, topembed+
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: don't spam the bug [adt2] PATCH, URL)

Attachments

(17 attachments, 7 obsolete attachments)

3.60 KB, text/html
Details
142 bytes, text/html
Details
1.03 KB, text/html
Details
211.76 KB, image/png
Details
1.53 KB, application/xhtml+xml
Details
4.16 KB, application/xhtml+xml
Details
4.44 KB, application/xhtml+xml
Details
6.45 KB, application/xhtml+xml
Details
73.02 KB, patch
roc
: review+
Details | Diff | Splinter Review
29.04 KB, patch
Details | Diff | Splinter Review
7.10 KB, application/zip
Details
66.11 KB, patch
Details | Diff | Splinter Review
15.68 KB, patch
Details | Diff | Splinter Review
13.86 KB, text/html
Details
8.94 KB, image/pdf
Details
12.77 KB, image/pdf
Details
13.86 KB, text/html
Details
(Reporter)

Description

15 years ago
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.
(Reporter)

Updated

15 years ago
Keywords: dataloss, nsbeta1+, top100, topembed
Priority: -- → P1
Target Milestone: --- → mozilla1.0.1
(Reporter)

Updated

15 years ago
Whiteboard: [adt2]
(Reporter)

Comment 1

15 years ago
petersen: Chris we need a reduced test case for this page. Thanks
Whiteboard: [adt2] → [adt2][testcase]

Updated

15 years ago
Status: NEW → ASSIGNED

Comment 2

15 years ago
Working on testcase

Comment 3

15 years ago
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.

Updated

15 years ago
Keywords: testcase

Comment 4

15 years ago
This is a known problem. We don't yet split absolutely positioned elements.

Comment 5

15 years ago
Removing [testcase] since a reduced testcase has been attached.
Whiteboard: [adt2][testcase] → [adt2]
(Reporter)

Comment 6

15 years ago
The fix for this will large and risky. Marking nsbeta1-.
Keywords: nsbeta1+ → nsbeta1-
(Reporter)

Comment 7

15 years ago
Clearing nsbeta1-, setting target to 1.2a.
Keywords: nsbeta1- → nsbeta1
Target Milestone: mozilla1.0.1 → mozilla1.2alpha

Comment 8

15 years ago
Still occurs in the OS X 2002-07-31-05 NB.
(Reporter)

Comment 9

15 years ago
nsbeta1+
Keywords: nsbeta1 → nsbeta1+
Target Milestone: mozilla1.2alpha → mozilla1.2beta

Updated

15 years ago
Summary: Missing second page of content when printing or print previewing this site → Splitting Absolutely positioned frames not implemented - Missing second page of content when printing or print previewing this site

Updated

15 years ago
Blocks: 122750

Updated

15 years ago
Blocks: 127527

Updated

15 years ago
Blocks: 149155

Updated

15 years ago
Blocks: 75213

Updated

15 years ago
Blocks: 166836

Updated

15 years ago
Keywords: topembed → topembed+

Comment 10

15 years ago
Could anybody check if bug 170848 is a dup of this one?

Comment 11

15 years ago
Created attachment 105081 [details] [diff] [review]
patch to implement splitting absolutely positioned elements

Updated

15 years ago
Whiteboard: [adt2] → [adt2] PATCH

Updated

15 years ago
Attachment #105081 - Flags: superreview?(kin)
Attachment #105081 - Flags: review?(bzbarsky)

Comment 12

15 years ago
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

15 years ago
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

15 years ago
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

15 years ago
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

15 years ago
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... 

Updated

15 years ago
Attachment #105081 - Flags: review?(bzbarsky) → review?(jkeiser)

Comment 17

15 years ago
Created attachment 108127 [details]
kin's test case that probably asserts the patch

Comment 18

15 years ago
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;
+    }
(Reporter)

Comment 19

15 years ago
-> Kin
Assignee: karnaze → kin
Status: ASSIGNED → NEW
(Reporter)

Updated

15 years ago
Target Milestone: mozilla1.2beta → mozilla1.4alpha

Comment 20

15 years ago
*** Bug 188167 has been marked as a duplicate of this bug. ***

Comment 21

15 years ago
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.
Severity: normal → critical

Updated

15 years ago
Target Milestone: mozilla1.4alpha → mozilla1.5alpha

Comment 22

15 years ago
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!
(Reporter)

Updated

14 years ago
Target Milestone: mozilla1.5alpha → mozilla1.6alpha

Comment 23

14 years ago
*** Bug 207962 has been marked as a duplicate of this bug. ***

Comment 24

14 years ago
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?
Flags: blocking1.5?

Comment 25

14 years ago
Too large a change for 1.5. This is going to need vetting in an alpha cycle. 
Flags: blocking1.5? → blocking1.5-

Comment 26

14 years ago
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

14 years ago
*** Bug 219274 has been marked as a duplicate of this bug. ***
*** Bug 122750 has been marked as a duplicate of this bug. ***
*** Bug 75213 has been marked as a duplicate of this bug. ***

Comment 30

14 years ago
*** Bug 153332 has been marked as a duplicate of this bug. ***
*** Bug 229900 has been marked as a duplicate of this bug. ***
OS: Windows XP → All
Hardware: PC → All
*** Bug 231483 has been marked as a duplicate of this bug. ***

Comment 33

14 years ago
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

14 years ago
jkeiser is not currently working on Mozilla code, and his suggested rewrite had
some issues that roc raised, last I checked.
(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

14 years ago
*** Bug 234023 has been marked as a duplicate of this bug. ***

Updated

14 years ago
Blocks: 234080

Comment 37

14 years ago
*** Bug 237970 has been marked as a duplicate of this bug. ***

Comment 38

14 years ago
*** Bug 238004 has been marked as a duplicate of this bug. ***

Updated

14 years ago
Blocks: 235157

Comment 39

14 years ago
*** Bug 240715 has been marked as a duplicate of this bug. ***

Comment 40

13 years ago
*** Bug 241695 has been marked as a duplicate of this bug. ***

Comment 41

13 years ago
*** Bug 242227 has been marked as a duplicate of this bug. ***

Comment 42

13 years ago
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

13 years ago
*** Bug 240035 has been marked as a duplicate of this bug. ***

Comment 44

13 years ago
*** Bug 244480 has been marked as a duplicate of this bug. ***

Comment 45

13 years ago
(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

13 years ago
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

13 years ago
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.
Flags: blocking-aviary1.0?
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

13 years ago
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

13 years ago
If this is going to block aviary1.0, it had better block the release candidate,
too, so it's tested enough...

blocking-aviary1.0RC1 ?
Flags: blocking-aviary1.0RC1?

Comment 51

13 years ago
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

13 years ago
*** Bug 242606 has been marked as a duplicate of this bug. ***

Comment 53

13 years ago
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.
Flags: blocking1.8a2?
Flags: blocking1.7.2?
Target Milestone: mozilla1.6alpha → ---

Comment 54

13 years ago
*** Bug 251571 has been marked as a duplicate of this bug. ***

Updated

13 years ago
Flags: blocking1.8a2? → blocking1.8a3?
Flags: blocking-aviary1.0RC1?
Flags: blocking-aviary1.0RC1-
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0-

Comment 55

13 years ago
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/

Updated

13 years ago
Flags: blocking1.8a3?
Flags: blocking1.8a3-
Flags: blocking1.7.3?
Flags: blocking1.7.3-
Flags: blocking1.5-

Comment 56

13 years ago
*** Bug 256203 has been marked as a duplicate of this bug. ***
*** Bug 258501 has been marked as a duplicate of this bug. ***

Comment 58

13 years ago
*** Bug 242135 has been marked as a duplicate of this bug. ***

Comment 59

13 years ago
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

13 years ago
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.
*** Bug 262170 has been marked as a duplicate of this bug. ***

Comment 62

13 years ago
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

13 years ago
> 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.
Assignee: kinmoz → nobody
Priority: P1 → --
QA Contact: chrispetersen → core.layout

Comment 64

13 years ago
(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.

Updated

13 years ago
Blocks: 263260

Comment 65

13 years ago
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

13 years ago
*** Bug 265197 has been marked as a duplicate of this bug. ***

Updated

13 years ago
No longer blocks: 263260

Comment 67

13 years ago
*** Bug 263260 has been marked as a duplicate of this bug. ***

Updated

13 years ago
Blocks: 267029

Updated

13 years ago
Blocks: 179135

Comment 68

13 years ago
*** Bug 269993 has been marked as a duplicate of this bug. ***

Comment 69

13 years ago
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>.

Updated

13 years ago
Blocks: 270291

Comment 70

13 years ago
*** Bug 271311 has been marked as a duplicate of this bug. ***
*** Bug 274961 has been marked as a duplicate of this bug. ***

Comment 72

13 years ago
*** Bug 277133 has been marked as a duplicate of this bug. ***

Comment 73

13 years ago
*** Bug 274684 has been marked as a duplicate of this bug. ***

Comment 74

13 years ago
*** Bug 276504 has been marked as a duplicate of this bug. ***

Updated

13 years ago
Flags: blocking-aviary1.1?
*** Bug 278952 has been marked as a duplicate of this bug. ***

Updated

13 years ago
Blocks: 278251

Comment 76

13 years ago
*** Bug 280753 has been marked as a duplicate of this bug. ***

Comment 77

13 years ago
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

13 years ago
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

13 years ago
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

13 years ago
is "absolute positioned div" styling part of the CSS standard?

Comment 81

13 years ago
div#navbar { position: absolute; /* ... */ }

Of course it's part of the CSS 2.x standard.

Comment 82

13 years ago
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.

Updated

13 years ago
Blocks: 270827

Comment 83

13 years ago
*** Bug 205486 has been marked as a duplicate of this bug. ***
*** Bug 288635 has been marked as a duplicate of this bug. ***

Comment 85

13 years ago
*** Bug 265355 has been marked as a duplicate of this bug. ***

Comment 86

13 years ago
*** Bug 289414 has been marked as a duplicate of this bug. ***

Comment 87

13 years ago
*** Bug 266504 has been marked as a duplicate of this bug. ***
*** Bug 290503 has been marked as a duplicate of this bug. ***

Comment 89

12 years ago
*** Bug 292716 has been marked as a duplicate of this bug. ***

Comment 90

12 years ago
*** Bug 248440 has been marked as a duplicate of this bug. ***

Comment 91

12 years ago
*** Bug 267745 has been marked as a duplicate of this bug. ***

Comment 92

12 years ago
*** Bug 260024 has been marked as a duplicate of this bug. ***

Comment 93

12 years ago
*** Bug 267709 has been marked as a duplicate of this bug. ***

Updated

12 years ago
Blocks: 163993

Comment 94

12 years ago
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?

Updated

12 years ago
No longer blocks: 163993
*** Bug 296867 has been marked as a duplicate of this bug. ***

Comment 96

12 years ago
Can we start to gather some information about the mozilla codebase to fix 
this? does anyone know why this happens? 

Comment 97

12 years ago
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

12 years ago
*** Bug 297423 has been marked as a duplicate of this bug. ***
*** Bug 298179 has been marked as a duplicate of this bug. ***
*** Bug 298946 has been marked as a duplicate of this bug. ***

Comment 101

12 years ago
*** Bug 299076 has been marked as a duplicate of this bug. ***

Updated

12 years ago
Flags: blocking-aviary1.1? → blocking-aviary1.1-
*** Bug 300728 has been marked as a duplicate of this bug. ***

Comment 103

12 years ago
For what it is worth, Firefox does not have this problem. Loss of text/pictures
also occurs when creating PDF.

Comment 104

12 years ago
(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
*** Bug 301880 has been marked as a duplicate of this bug. ***

Comment 106

12 years ago
*** Bug 303002 has been marked as a duplicate of this bug. ***

Comment 107

12 years ago
*** Bug 302763 has been marked as a duplicate of this bug. ***

Comment 108

12 years ago
*** Bug 304399 has been marked as a duplicate of this bug. ***

Updated

12 years ago
Blocks: 125824
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.
Flags: blocking1.9a1?

Comment 110

12 years ago
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.
Keywords: helpwanted
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.)
(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

12 years ago
As of 1 Sep 2005, Print Preview hangs using the original URL. (Site changes
constantly though.)

Updated

12 years ago
Flags: blocking-aviary2.0?

Comment 114

12 years ago
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

12 years ago
*** Bug 260069 has been marked as a duplicate of this bug. ***

Comment 116

12 years ago
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

12 years ago
*** Bug 310555 has been marked as a duplicate of this bug. ***

Comment 118

12 years ago
*** Bug 272998 has been marked as a duplicate of this bug. ***

Comment 119

12 years ago
*** Bug 260423 has been marked as a duplicate of this bug. ***

Comment 120

12 years ago
*** Bug 312412 has been marked as a duplicate of this bug. ***

Comment 121

12 years ago
*** Bug 273780 has been marked as a duplicate of this bug. ***

Comment 122

12 years ago
*** Bug 315763 has been marked as a duplicate of this bug. ***

Comment 123

12 years ago
www.csszengarden.com uses media="screen" to work around this problem. It disables all styles leaving the validated html to be printed.

Comment 124

12 years ago
*** Bug 270827 has been marked as a duplicate of this bug. ***
No longer blocks: 270827

Comment 125

12 years ago
*** Bug 319931 has been marked as a duplicate of this bug. ***

Comment 126

12 years ago
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

12 years ago
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).
bumping nom to core noms
Flags: blocking-aviary2? → blocking1.8.1?
*** Bug 127527 has been marked as a duplicate of this bug. ***
No longer blocks: 127527

Comment 130

12 years ago
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!
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

12 years ago
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

12 years ago
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

12 years ago
*** Bug 325388 has been marked as a duplicate of this bug. ***

Comment 135

12 years ago
*** Bug 327112 has been marked as a duplicate of this bug. ***

Comment 136

12 years ago
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

12 years ago
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

12 years ago
*** Bug 327736 has been marked as a duplicate of this bug. ***

Comment 139

12 years ago
65 or so dupes so far ... 
*** Bug 328123 has been marked as a duplicate of this bug. ***

Comment 141

12 years ago
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. 
*** Bug 330880 has been marked as a duplicate of this bug. ***

Comment 143

11 years ago
*** Bug 337183 has been marked as a duplicate of this bug. ***

Comment 144

11 years ago
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.
Blocks: 257261

Comment 145

11 years ago
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?
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?

Updated

11 years ago
Blocks: 325388

Comment 147

11 years ago
Not going to happen for 1.8.1 (dbaron says it is way too risky at this point).
Flags: blocking1.8.1? → blocking1.8.1-

Comment 148

11 years ago
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

11 years ago
*** Bug 341936 has been marked as a duplicate of this bug. ***

Comment 150

11 years ago
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?
(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

11 years ago
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.
(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

11 years ago
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

Updated

11 years ago
Flags: blocking1.9a1? → blocking1.9-
Whiteboard: [adt2] PATCH → [adt2] PATCH [wanted-1.9]

Comment 155

11 years ago
(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.
Version: Trunk → 1.0 Branch
Version: 1.0 Branch → Trunk

Comment 156

11 years ago
*** Bug 350709 has been marked as a duplicate of this bug. ***

Comment 157

11 years ago
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

11 years ago
indeed, not being able to print more than one page w/ absolute elements is quite a large problem.

Comment 159

11 years ago
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

11 years ago
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

11 years ago
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

11 years ago
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.
*** Bug 270291 has been marked as a duplicate of this bug. ***
No longer blocks: 270291

Comment 164

11 years ago
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

11 years ago
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.





Status: NEW → ASSIGNED

Comment 166

11 years ago
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!

*** Bug 357483 has been marked as a duplicate of this bug. ***

Comment 168

11 years ago
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.
*** Bug 361471 has been marked as a duplicate of this bug. ***

Updated

11 years ago
No longer blocks: 325388

Comment 170

11 years ago
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

11 years ago
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.
Whiteboard: [adt2] PATCH [wanted-1.9] → don't spam the bug [adt2] PATCH [wanted-1.9]

Comment 172

11 years ago
*** Bug 330719 has been marked as a duplicate of this bug. ***
Status: ASSIGNED → NEW

Comment 173

11 years ago
(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

11 years ago
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

11 years ago
(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

11 years ago
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

11 years ago
(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

11 years ago
(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

11 years ago
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

11 years ago
Created attachment 252903 [details]
A screenshot of the problem in action.

The printout looks just the same.

Comment 181

11 years ago
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. 

Updated

11 years ago
Duplicate of this bug: 372594

Comment 183

11 years ago
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

11 years ago
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

11 years ago
This is issue is so sad that I can almost laugh about it. 5 years without working printing support. I have had enough.
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?"

Updated

10 years ago
Duplicate of this bug: 366948

Updated

10 years ago
Blocks: 103890
Duplicate of this bug: 379252
(Assignee)

Updated

10 years ago
Depends on: 379349

Comment 189

10 years ago
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
(Assignee)

Updated

10 years ago
Assignee: nobody → fantasai.bugs
(Assignee)

Comment 190

10 years ago
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.
Status: NEW → ASSIGNED
Flags: blocking1.9- → blocking1.9?
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.
Flags: blocking1.9? → blocking1.9-
(Assignee)

Updated

10 years ago
Target Milestone: --- → mozilla1.9 M8
Duplicate of this bug: 391521

Comment 193

10 years ago
How about adding another bug heading for "printing" instead of using General?
(Assignee)

Comment 194

10 years ago
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.
+  // 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?
(Assignee)

Comment 196

10 years ago
>  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. 

Updated

10 years ago
Duplicate of this bug: 392298
(Assignee)

Comment 198

10 years ago
Created attachment 277148 [details]
dynamic testcase (multi-col)
(Assignee)

Comment 199

10 years ago
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?
Attachment #105081 - Attachment is obsolete: true
Attachment #276026 - Attachment is obsolete: true
Attachment #105081 - Flags: superreview?(kinmoz)
Attachment #105081 - Flags: review?(john)

Comment 200

10 years ago
> 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.
(Assignee)

Comment 201

10 years ago
Created attachment 277955 [details] [diff] [review]
patch
Attachment #277175 - Attachment is obsolete: true
Attachment #277955 - Flags: superreview?(roc)
Attachment #277955 - Flags: review?(sharparrow1)

Comment 202

10 years ago
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.
(Assignee)

Comment 203

10 years ago
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.
Attachment #277955 - Attachment is obsolete: true
Attachment #277955 - Flags: superreview?(roc)
Attachment #277955 - Flags: review?(sharparrow1)
     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...
(Assignee)

Comment 205

10 years ago
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/. :)
Attachment #278092 - Attachment is obsolete: true
Attachment #279301 - Flags: superreview?(roc)
Attachment #279301 - Flags: review?(sharparrow1)
+        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?
(Assignee)

Comment 207

10 years ago
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.
Attachment #279301 - Attachment is obsolete: true
Attachment #279840 - Flags: superreview?(roc)
Attachment #279840 - Flags: review?(sharparrow1)
Attachment #279301 - Flags: superreview?(roc)
Attachment #279301 - Flags: review?(sharparrow1)
(Assignee)

Comment 208

10 years ago
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 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).
Attachment #279840 - Flags: superreview?(roc) → superreview+
(Assignee)

Comment 210

10 years ago
Created attachment 280152 [details]
Interlaced Abspos and Overflow Pagination [reftest-ready]
(Assignee)

Comment 211

10 years ago
Created attachment 282870 [details]
Dynamic Interlaced Abspos and Overflow Pagination [reftest-ready]
(Assignee)

Comment 212

10 years ago
Created attachment 282871 [details] [diff] [review]
patch
Attachment #279840 - Attachment is obsolete: true
Attachment #282871 - Flags: superreview?(roc)
Attachment #282871 - Flags: review?(sharparrow1)
Attachment #279840 - Flags: review?(sharparrow1)

Updated

10 years ago
Blocks: 394237
Can you describe the changes from the last iteration?
(Assignee)

Comment 214

10 years ago
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.
Duplicate of this bug: 398106

Comment 216

10 years ago
I've been using this patch for two days and I haven't noticed any bad side-effects.
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.
Attachment #282871 - Flags: superreview?(roc)
Attachment #282871 - Flags: superreview+
Attachment #282871 - Flags: review?(sharparrow1)
Attachment #282871 - Flags: review+
Attachment #282871 - Flags: approval1.9+
(Assignee)

Comment 218

10 years ago
Created attachment 283127 [details]
reftests.zip
Target Milestone: mozilla1.9 M8 → mozilla1.9 M9
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
(Assignee)

Comment 220

10 years ago
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);
Keywords: helpwanted
(Assignee)

Comment 221

10 years ago
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.
Attachment #283152 - Flags: superreview?(roc)
Attachment #283152 - Flags: superreview?(roc)
Attachment #283152 - Flags: superreview+
Attachment #283152 - Flags: approval1.9+
(Assignee)

Comment 222

10 years ago
Fix checked in late last night. Thanks everyone~
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED

Updated

10 years ago
Depends on: 398322

Updated

10 years ago
Depends on: 398332

Updated

10 years ago
Duplicate of this bug: 398518

Updated

10 years ago
Duplicate of this bug: 398452
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+.  :-)
Flags: in-testsuite+

Updated

10 years ago
Duplicate of this bug: 235157

Updated

10 years ago
Depends on: 399994

Updated

10 years ago
Duplicate of this bug: 403750

Updated

10 years ago
Duplicate of this bug: 309105

Comment 229

10 years ago
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
This will never be fixed in Firefox 2.x; it's fixed on the trunk, which will become Firefox 3.
You can verify it being fixed for 3.0 by downloading 3.0b1 or waiting for the final release.

Updated

10 years ago
Duplicate of this bug: 406749

Comment 233

10 years ago
(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!
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

Please file followup bugs, CC fantasai and mark them blocking 1.9?

Comment 236

10 years ago
Out of curiosity, how is this marked fixed, with Bug 398332 and Bug 399994 open and still blocking this?
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).
Flags: wanted1.9+
Whiteboard: don't spam the bug [adt2] PATCH [wanted-1.9] → don't spam the bug [adt2] PATCH

Comment 238

10 years ago
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

10 years ago
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

10 years ago
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? ;-)
(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)

Updated

9 years ago
Depends on: 450509

Comment 242

9 years ago
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

9 years ago
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

9 years ago
Created attachment 343341 [details]
PDF showing incorrect output of above

Comment 245

9 years ago
Created attachment 343342 [details]
PDF showing correct output, as printed from Webkit

Comment 246

9 years ago
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
Duplicate of this bug: 411033

Updated

9 years ago
No longer blocks: 267029

Comment 248

8 years ago
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
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

8 years ago
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

8 years ago
bug 521068 has been added to the database
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.

Updated

8 years ago
Blocks: 521204
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.

Updated

8 years ago
Blocks: 538708

Comment 254

8 years ago
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.
(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.

Updated

8 years ago

Comment 256

8 years ago
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

8 years ago
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

8 years ago
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)
(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.
(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

8 years ago
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).
(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

8 years ago
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.
(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

8 years ago
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

8 years ago
(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

8 years ago
Sorry, again; there is "no solution" at all, not "no response". Thank you.
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
Blocks: 546559

Comment 269

7 years ago
(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

7 years ago
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

7 years ago
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

7 years ago
(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

7 years ago
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

7 years ago
(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

7 years ago
(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
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

7 years ago
I'll just track bug 521204

Comment 278

7 years ago
https://bugzilla.mozilla.org/show_bug.cgi?id=280661

Updated

2 years ago
Flags: in-testsuite+
Flags: blocking1.9-
Flags: blocking1.8a3-
Flags: blocking1.8.1-
Flags: blocking1.7.5-
Flags: blocking-aviary1.5-
Flags: blocking-aviary1.0PR-
Flags: blocking-aviary1.0-
You need to log in before you can comment on or make changes to this bug.