Closed Bug 154892 Opened 23 years ago Closed 17 years ago

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

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.9beta1

People

(Reporter: kmcclusk, Assigned: fantasai.bugs)

References

(Blocks 3 open bugs,
URL
)

Details

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

Attachments

(17 files, 7 obsolete files)

Reduced test case from espn site
3.60 KB, text/html
Details
kin's test case that probably asserts the patch
142 bytes, text/html
Details
Super simplified tests case
1.03 KB, text/html
Details
A screenshot of the problem in action.
211.76 KB, image/png
Details
dynamic testcase (multi-col)
1.53 KB, application/xhtml+xml
Details
Multi-Col Interlaced Abspos and Overflow Pagination [reftest-ready]
4.16 KB, application/xhtml+xml
Details
Interlaced Abspos and Overflow Pagination [reftest-ready]
4.44 KB, application/xhtml+xml
Details
Dynamic Interlaced Abspos and Overflow Pagination [reftest-ready]
6.45 KB, application/xhtml+xml
Details
patch
73.02 KB, patch
roc
: review+
roc
: superreview+
roc
: approval1.9+
Details | Diff | Splinter Review
diff patch and patch pass 5
29.04 KB, patch
Details | Diff | Splinter Review
reftests.zip
7.10 KB, application/zip
Details
final patch
66.11 KB, patch
Details | Diff | Splinter Review
follow-up patch
15.68 KB, patch
roc
: superreview+
roc
: approval1.9+
Details | Diff | Splinter Review
Prints correctly on first page, then seems to be bunched up on the first line of the second page
13.86 KB, text/html
Details
PDF showing incorrect output of above
8.94 KB, image/pdf
Details
PDF showing correct output, as printed from Webkit
12.77 KB, image/pdf
Details
When div position is changed to relative instead of absolute, still doesn't print after first page, but does add extra blank pages
13.86 KB, text/html
Details
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.
Keywords: dataloss, nsbeta1+, top100, topembed
Priority: -- → P1
Target Milestone: --- → mozilla1.0.1
Whiteboard: [adt2]
petersen: Chris we need a reduced test case for this page. Thanks
Whiteboard: [adt2] → [adt2][testcase]
Status: NEW → ASSIGNED
Working on testcase
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.
Keywords: testcase
This is a known problem. We don't yet split absolutely positioned elements.
Removing [testcase] since a reduced testcase has been attached.
Whiteboard: [adt2][testcase] → [adt2]
The fix for this will large and risky. Marking nsbeta1-.
Keywords: nsbeta1+ → nsbeta1-
Clearing nsbeta1-, setting target to 1.2a.
Keywords: nsbeta1- → nsbeta1
Target Milestone: mozilla1.0.1 → mozilla1.2alpha
Still occurs in the OS X 2002-07-31-05 NB.
nsbeta1+
Keywords: nsbeta1 → nsbeta1+
Target Milestone: mozilla1.2alpha → mozilla1.2beta
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
Blocks: 122750
Blocks: 127527
Blocks: 149155
Blocks: 75213
Blocks: 166836
Keywords: topembed → topembed+
Could anybody check if bug 170848 is a dup of this one?
Whiteboard: [adt2] → [adt2] PATCH
Attachment #105081 - Flags: superreview?(kin)
Attachment #105081 - Flags: review?(bzbarsky)
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...
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.
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 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?
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...
Attachment #105081 - Flags: review?(bzbarsky) → review?(jkeiser)
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; + }
-> Kin
Assignee: karnaze → kin
Status: ASSIGNED → NEW
Target Milestone: mozilla1.2beta → mozilla1.4alpha
*** Bug 188167 has been marked as a duplicate of this bug. ***
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
Target Milestone: mozilla1.4alpha → mozilla1.5alpha
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!
Target Milestone: mozilla1.5alpha → mozilla1.6alpha
*** Bug 207962 has been marked as a duplicate of this bug. ***
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?
Too large a change for 1.5. This is going to need vetting in an alpha cycle.
Flags: blocking1.5? → blocking1.5-
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.
*** 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. ***
*** 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. ***
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.
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).
*** Bug 234023 has been marked as a duplicate of this bug. ***
Blocks: 234080
*** Bug 237970 has been marked as a duplicate of this bug. ***
*** Bug 238004 has been marked as a duplicate of this bug. ***
Blocks: 235157
*** Bug 240715 has been marked as a duplicate of this bug. ***
*** Bug 241695 has been marked as a duplicate of this bug. ***
*** Bug 242227 has been marked as a duplicate of this bug. ***
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/
*** Bug 240035 has been marked as a duplicate of this bug. ***
*** Bug 244480 has been marked as a duplicate of this bug. ***
(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).
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.
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.
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.
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?
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)
*** Bug 242606 has been marked as a duplicate of this bug. ***
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 → ---
*** Bug 251571 has been marked as a duplicate of this bug. ***
Flags: blocking1.8a2? → blocking1.8a3?
Flags: blocking-aviary1.0RC1?
Flags: blocking-aviary1.0RC1-
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0-
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/
Flags: blocking1.8a3?
Flags: blocking1.8a3-
Flags: blocking1.7.3?
Flags: blocking1.7.3-
Flags: blocking1.5-
*** Bug 256203 has been marked as a duplicate of this bug. ***
*** Bug 258501 has been marked as a duplicate of this bug. ***
*** Bug 242135 has been marked as a duplicate of this bug. ***
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" ????
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. ***
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?
> 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
(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.
Blocks: 263260
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!
*** Bug 265197 has been marked as a duplicate of this bug. ***
No longer blocks: 263260
*** Bug 263260 has been marked as a duplicate of this bug. ***
Blocks: 267029
Blocks: 179135
*** Bug 269993 has been marked as a duplicate of this bug. ***
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>.
Blocks: 270291
*** Bug 271311 has been marked as a duplicate of this bug. ***
*** Bug 274961 has been marked as a duplicate of this bug. ***
*** Bug 277133 has been marked as a duplicate of this bug. ***
*** Bug 274684 has been marked as a duplicate of this bug. ***
*** Bug 276504 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.1?
*** Bug 278952 has been marked as a duplicate of this bug. ***
Blocks: 278251
*** Bug 280753 has been marked as a duplicate of this bug. ***
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.
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.
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.
is "absolute positioned div" styling part of the CSS standard?
div#navbar { position: absolute; /* ... */ } Of course it's part of the CSS 2.x standard.
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.
Blocks: 270827
*** Bug 205486 has been marked as a duplicate of this bug. ***
*** Bug 288635 has been marked as a duplicate of this bug. ***
*** Bug 265355 has been marked as a duplicate of this bug. ***
*** Bug 289414 has been marked as a duplicate of this bug. ***
*** Bug 266504 has been marked as a duplicate of this bug. ***
*** Bug 290503 has been marked as a duplicate of this bug. ***
*** Bug 292716 has been marked as a duplicate of this bug. ***
*** Bug 248440 has been marked as a duplicate of this bug. ***
*** Bug 267745 has been marked as a duplicate of this bug. ***
*** Bug 260024 has been marked as a duplicate of this bug. ***
*** Bug 267709 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
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?
No longer blocks: majorbugs
*** Bug 296867 has been marked as a duplicate of this bug. ***
Can we start to gather some information about the mozilla codebase to fix this? does anyone know why this happens?
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.
*** 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. ***
*** Bug 299076 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.1? → blocking-aviary1.1-
*** Bug 300728 has been marked as a duplicate of this bug. ***
For what it is worth, Firefox does not have this problem. Loss of text/pictures also occurs when creating PDF.
(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. ***
*** Bug 303002 has been marked as a duplicate of this bug. ***
*** Bug 302763 has been marked as a duplicate of this bug. ***
*** Bug 304399 has been marked as a duplicate of this bug. ***
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?
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?
As of 1 Sep 2005, Print Preview hangs using the original URL. (Site changes constantly though.)
Flags: blocking-aviary2.0?
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...)
*** Bug 260069 has been marked as a duplicate of this bug. ***
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...
*** Bug 310555 has been marked as a duplicate of this bug. ***
*** Bug 272998 has been marked as a duplicate of this bug. ***
*** Bug 260423 has been marked as a duplicate of this bug. ***
*** Bug 312412 has been marked as a duplicate of this bug. ***
*** Bug 273780 has been marked as a duplicate of this bug. ***
*** Bug 315763 has been marked as a duplicate of this bug. ***
www.csszengarden.com uses media="screen" to work around this problem. It disables all styles leaving the validated html to be printed.
*** Bug 270827 has been marked as a duplicate of this bug. ***
No longer blocks: 270827
*** Bug 319931 has been marked as a duplicate of this bug. ***
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.
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
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?
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.
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!
*** Bug 325388 has been marked as a duplicate of this bug. ***
*** Bug 327112 has been marked as a duplicate of this bug. ***
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?!
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.
*** Bug 327736 has been marked as a duplicate of this bug. ***
65 or so dupes so far ...
*** Bug 328123 has been marked as a duplicate of this bug. ***
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. ***
*** Bug 337183 has been marked as a duplicate of this bug. ***
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
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?
Blocks: 325388
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-
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.
*** Bug 341936 has been marked as a duplicate of this bug. ***
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.
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.
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
Flags: blocking1.9a1? → blocking1.9-
Whiteboard: [adt2] PATCH → [adt2] PATCH [wanted-1.9]
(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
*** Bug 350709 has been marked as a duplicate of this bug. ***
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!
indeed, not being able to print more than one page w/ absolute elements is quite a large problem.
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.
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.
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.
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
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.
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
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. ***
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. ***
No longer blocks: 325388
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?!).
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]
*** Bug 330719 has been marked as a duplicate of this bug. ***
Status: ASSIGNED → NEW
(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.
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]
(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 >
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?
(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.
(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 ...
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.
The printout looks just the same.
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.
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.
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.
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?"
Blocks: 103890
Depends on: 379349
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: nobody → fantasai.bugs
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-
Target Milestone: --- → mozilla1.9 M8
How about adding another bug heading for "printing" instead of using General?
Attached patch first pass (obsolete) — — Splinter Review
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?
> 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.
Attached patch patch pass 2 (obsolete) — — Splinter Review
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)
> 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.
Attached patch patch (obsolete) — — Splinter Review
Attachment #277175 - Attachment is obsolete: true
Attachment #277955 - Flags: superreview?(roc)
Attachment #277955 - Flags: review?(sharparrow1)
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.
Attached patch patch -up12 (obsolete) — — Splinter Review
> 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...
Attached patch patch pass 4 (obsolete) — — Splinter Review
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?
Attached patch patch pass 5 (obsolete) — — Splinter Review
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)
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+
Attached patch patch — — Splinter Review
Attachment #279840 - Attachment is obsolete: true
Attachment #282871 - Flags: superreview?(roc)
Attachment #282871 - Flags: review?(sharparrow1)
Attachment #279840 - Flags: review?(sharparrow1)
Blocks: 394237
Can you describe the changes from the last iteration?
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.
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+
Attached file 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
Attached patch final patch — — Splinter Review
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
Attached patch follow-up patch — — Splinter Review
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+
Fix checked in late last night. Thanks everyone~
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Depends on: 398322
Depends on: 398332
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+
Depends on: 399994
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.
(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!
Please file followup bugs, CC fantasai and mark them blocking 1.9?
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
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.
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.
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)
Depends on: 450509
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.
No longer blocks: 267029
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.
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.
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.
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.
No longer blocks: 75213, 103890, 122750, 125824, 149155, 166836, 179135, 234080, 235157, 257261, 278251
Blocks: 538708
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.
See Also: → https://launchpad.net/bugs/17682
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?
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.
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.
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.
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.
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.
(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.
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
(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.
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!
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!!
(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.
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?
(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).
(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
I'll just track bug 521204
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-

Bugbug thinks this bug is a regression, but please revert this change in case of error.

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

Attachment

General

Creator:
Created:
Updated:
Size: