Closed
Bug 534182
Opened 15 years ago
Closed 3 years ago
Tall inline-block/inline-table/inline-grid/inline-flex are cropped in print / print-preview [fixed by bug 1681052]
Categories
(Core :: Printing: Output, defect, P3)
Core
Printing: Output
Tracking
()
RESOLVED
FIXED
85 Branch
People
(Reporter: web, Assigned: MatsPalmgren_bugz)
References
(Depends on 1 open bug, Blocks 4 open bugs, )
Details
(Keywords: dataloss, productwanted, Whiteboard: [layout:print-triage:p1][layout:backlog])
Attachments
(4 files)
reddit cut.png
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•15 years ago
|
Blocks: 521204
Component: General → Printing: Output
Product: Firefox → Core
QA Contact: general → printing
|
|
||
Comment 1•15 years ago
|
||
test case from reporter
|
||
Comment 2•15 years ago
|
||
Good simple test case, confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
|
||
Comment 3•14 years ago
|
||
|
|
||
Updated•14 years ago
|
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
|
||
Comment 5•14 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.
|
|
||
Comment 6•14 years ago
|
||
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•14 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.
|
|
||
Comment 8•12 years ago
|
||
(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•10 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?
|
Assignee | |
Comment 10•9 years ago
|
||
|
|
||
Comment 11•9 years ago
|
||
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
|
|
||
Comment 12•9 years ago
|
||
(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•9 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; }
|
|
||
Updated•8 years ago
|
status-b2g-v2.6:
--- → affected
status-firefox47:
--- → affected
status-firefox48:
--- → affected
status-firefox49:
--- → affected
status-firefox50:
--- → affected
Keywords: productwanted
|
|
||
Comment 15•6 years ago
|
||
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.
|
|
Assignee | |
Updated•5 years ago
|
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
|
||
Updated•5 years ago
|
Whiteboard: [layout:print-triage:p1]
|
|
||
Updated•5 years ago
|
Whiteboard: [layout:print-triage:p1] → [layout:print-triage:p1][layout:backlog:2020q1]
|
|
||
Updated•5 years ago
|
|
|
||
Updated•5 years ago
|
Whiteboard: [layout:print-triage:p1][layout:backlog:2020q1] → [frag2020]
|
|
||
Updated•5 years ago
|
Whiteboard: [frag2020] → [layout:print-triage:p1][layout:backlog:2020q1][frag2020]
|
|
||
Updated•5 years ago
|
Whiteboard: [layout:print-triage:p1][layout:backlog:2020q1][frag2020] → [layout:print-triage:p1][layout:backlog:2020q1]
|
|
||
Updated•5 years ago
|
Whiteboard: [layout:print-triage:p1][layout:backlog:2020q1] → [layout:print-triage:p1][layout:backlog]
|
|
||
Updated•4 years ago
|
Severity: normal → S2
Priority: P2 → P3
|
||
Comment 20•4 years ago
|
||
Encountered this on Reddit while testing on 82.0b4 on Windows 7 with the new modal.
|
|
||
Comment 22•3 years ago
|
||
We've shipped a mitigation for this issue in bug 1681052. It won't handle all cases perfectly -- e.g. it might cut a line of text in half -- but there shouldn't be as much missing content due to this bug anymore.
The spec text from comment 11 still exists and has been extended a bit:
Since line boxes contain no possible break points, inline-block and inline-table boxes (and other inline-level display types that establish an independent formatting context) may also be considered monolithic: that is, in the cases where a single line box is too large to fit within its fragmentainer even by itself and the UA chooses to split the line box, it may fragment such boxes or it may treat them as monolithic.
https://drafts.csswg.org/css-break/#end-block
Also, a bit further along, the spec says:
[...] the UA may also fragment the contents of monolithic elements by slicing the element’s graphical representation.
https://drafts.csswg.org/css-break/#unforced-breaks
So: given the following...
- Our new behavior as of bug 1681052 is matching these two bits of spec text (treating inline-* content as monolithic and slicing its graphical representation)
- We believe our approach mitigates the dataloss that we were reporting here
- The three testcases all pass (all of the content is visible in print preview)
...I think we can close this as FIXED-by-bug 1681052. If there are any remaining issues associated with this bug, we should spin them off to their own bug reports and give them individual consideration/treatment.
Status: NEW → RESOLVED
Closed: 3 years ago
Depends on: 1681052
Resolution: --- → FIXED
Summary: Tall inline-block/inline-table/inline-grid/inline-flex are cropped in print / print-preview → Tall inline-block/inline-table/inline-grid/inline-flex are cropped in print / print-preview [fixed by bug 1681052]
|
||
Updated•3 years ago
|
Assignee: nobody → mats
Target Milestone: --- → 85 Branch
You need to log in
before you can comment on or make changes to this bug.
Description
•