Open Bug 534182 Opened 12 years ago Updated 5 months ago

Tall inline-block/inline-table/inline-grid/inline-flex are cropped in print / print-preview


(Core :: Printing: Output, defect, P3)




Tracking Status
firefox47 --- affected
firefox48 --- affected
firefox49 --- affected
b2g-v2.6 --- affected
firefox50 --- affected


(Reporter: web, Unassigned)


(Depends on 1 open bug, Blocks 3 open bugs, )


(Keywords: dataloss, productwanted, Whiteboard: [layout:print-triage:p1][layout:backlog])


(4 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; ru; rv: Gecko/20091102 Firefox/3.5.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; ru; rv: Gecko/20091102 Firefox/3.5.5

 |- table
     |- tr
     |  [many-many tr]
     |- tr

When printing table rendered at one page but should at number of pages.

Reproducible: Always

Steps to Reproduce:
1. Create div
2. Add style to div {display:-moz-inline-stack;display:inline-block;}
3. Insert long table in div (one hundred lines)
4. Click print-preview
Actual Results:  
Table crop by page and render at only one page

Expected Results:  
Table render at few pages

Appear in Fx 3.5.5 and Fx
Blocks: 521204
Component: General → Printing: Output
Product: Firefox → Core
QA Contact: general → printing
Attached file test case
test case from reporter
Good simple test case, confirming.
Ever confirmed: true
Attached file testcase 2
OS: Windows Vista → All
Hardware: x86 → All
Summary: Long table wrapped by inline-block element crops in print-preview. → Tall inline-blocks are cropped in print / print-preview
Version: unspecified → Trunk
Duplicate of this bug: 647870
This bug importance should be designated as Major since it prevents FireFox from being seriously considered for business use since printing hard copy is not reliable.
There's actually a whole category of 'missing page content when printing' bugs, and they're tracked by bug 521204.  If your criterion for 'business use' is to be able to print every page on the internet without any missing content, then you'll want to wait until all of that metabug's dependencies are resolved (and get a magazine to read while you wait). :)  But seriously, we *are* working on fixing those sorts of bugs - e.g. bz did some great work to fix bug 129941 for Firefox 4, which wiped out a huge percentage of these issues.

Unfortunately, this bug here will be nontrivial to solve, according to fantasai, who knows our page-splitting code better than anyone.  She says this will require some serious refactoring / code-rewriting to fix.

If you depend on being able to print a particular page in Firefox, and that page suffers from this bug, your best bet in the near term is probably to remove the 'inline-block' styling, either on the server (if you control the site) or dynamically on the client side via an add-on like Stylish.
Referred from bug 294991 #42:

One more example for truncating after page 1.

It happens with Firefox 3.6 and 4.0, and seemingly also 5.0 aurora.
Works with Opera.
(In reply to Dirk Schoettler from comment #7)
> One more example for truncating after page 1.

[just now saw this comment]

This page is no longer available, so I can't be sure what was going on there. But in the future, please file separate bugs in a case like that, rather than posting the URL on an existing bug.  At least in the case of printing-truncation, it's frequently a different underlying issue -- per comment 6, there are lots of different reasons this can happen. So -- unless you've actually done some analysis to figure out whether it's the same underlying bug or not[1], it's best to file new bugs and then mark them as duplicates after-the-fact (if necessary), so that we don't end up with one bug covering multiple similar-looking-but-different-under-the-hood issues.

[1] Figuring out whether it's the same underlying bug would be, e.g. in the case of this bug, looking for an inline-block in the page-source, and then seeing if the bug goes away when you change that element's style to be a block instead of an inline-block.
(In reply to Daniel Holbert [:dholbert] from comment #6)
> ...your best bet in the near term...

So this bug was reported in 2009 and this response was in April 2011, and at least one person felt it should be designated Major (back in 2011) and now it's late 2014, could somebody maybe clarify the limits of "near-term" for me?
Attached file testcase #3
In a recent CSSWG meeting[1], the CSSWG resolved to make an update[2] to the css-break draft[3] (which describes how web content should be split, including printing).

The new spec text is:
> Since line boxes contain no possible break points,
> inline-block and inline-table boxes (and other
> inline-level display types that establish a new
> formatting context) may also be considered monolithic.
...and "monolithic" is defined higher up as "contain[ing] no possible break points."

So, I think this means we're doing what the spec (now) calls for here.

(The initial version of the new spec-text was simply "Note: Since line boxes cannot be broken, 'inline-block' and 'inline-table' boxes cannot be fragmented."

fantasai modified the language later on to be more abstract/generic, but I believe the aim is still the same.)
I can confirm this bug on this website:

Activating/Deactivating the following in our CSS seems to fix the problem:

.main-section .container .col-xs-9 > div { display: inline-block; }
Duplicate of this bug: 728891
Blocks: 1302489
FWIW, I just ran into this when making camping reservations at -- the "print your confirmation / park policies / directions" page at the end of the checkout process has an element <div id="formContainer"> which is "display:inline-block" and has ~6 pages' worth of content, but it gets truncated at the first page.  So the directions/policies/etc. don't end up getting printed, despite this being a page that the site asks you to print.
Blocks: 1017137
Keywords: dataloss
Priority: -- → P2
Summary: Tall inline-blocks are cropped in print / print-preview → Tall inline-block/inline-table/inline-grid/inline-flex are cropped in print / print-preview
Whiteboard: [layout:print-triage:p1]
Blocks: 1601429
Blocks: 1479119
Depends on: 1250348
Duplicate of this bug: 1610618
Whiteboard: [layout:print-triage:p1] → [layout:print-triage:p1][layout:backlog:2020q1]
See Also: → 1615274
Whiteboard: [layout:print-triage:p1][layout:backlog:2020q1] → [frag2020]
Whiteboard: [frag2020] → [layout:print-triage:p1][layout:backlog:2020q1][frag2020]
Whiteboard: [layout:print-triage:p1][layout:backlog:2020q1][frag2020] → [layout:print-triage:p1][layout:backlog:2020q1]
Whiteboard: [layout:print-triage:p1][layout:backlog:2020q1] → [layout:print-triage:p1][layout:backlog]
Duplicate of this bug: 1627642
Duplicate of this bug: 1627508
Duplicate of this bug: 1627508
Severity: normal → S2
Priority: P2 → P3
Attached image reddit cut.png

Encountered this on Reddit while testing on 82.0b4 on Windows 7 with the new modal.

Duplicate of this bug: 1666825
You need to log in before you can comment on or make changes to this bug.