Tall inline-blocks are cropped in print / print-preview

NEW
Unassigned

Status

()

defect
10 years ago
7 months ago

People

(Reporter: web, Unassigned)

Tracking

(Blocks 3 bugs, {productwanted})

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox47 affected, firefox48 affected, firefox49 affected, b2g-v2.6 affected, firefox50 affected)

Details

()

Attachments

(3 attachments)

Reporter

Description

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

div.{display:inline-block}
 |
 |- 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 2.0.0.20

Updated

10 years ago
Blocks: 521204
Component: General → Printing: Output
Product: Firefox → Core
QA Contact: general → printing
Posted file test case
test case from reporter
Good simple test case, confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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

Comment 5

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

Comment 7

8 years ago
Referred from bug 294991 #42:

One more example for truncating after page 1.
http://www.norfolkline.com/EN/Blank/Terms/

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.
> http://www.norfolkline.com/EN/Blank/Terms/

[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.

Comment 9

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

Comment 10

4 years ago
Posted 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.

[1] https://lists.w3.org/Archives/Public/www-style/2015Oct/0085.html
[2] https://hg.csswg.org/drafts/rev/4e6c166084bb
[3] https://drafts.csswg.org/css-break/#end-block
(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."
 https://hg.csswg.org/drafts/rev/055ad4782c26

fantasai modified the language later on to be more abstract/generic, but I believe the aim is still the same.)

Comment 13

3 years ago
I can confirm this bug on this website: http://www.gewinn.com/management-karriere/weiterbildung-karriere/artikel/online-kursplattformen/

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

.main-section .container .col-xs-9 > div { display: inline-block; }
Blocks: 1302489
FWIW, I just ran into this when making camping reservations at https://secure.itinio.com/sanmateo/memorial-park -- 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.
You need to log in before you can comment on or make changes to this bug.