Printing cut off in overflow:hidden && display:flex containers
Categories
(Core :: Printing: Output, defect)
Tracking
()
People
(Reporter: github.tbart, Unassigned)
References
Details
Attachments
(3 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36
Steps to reproduce:
On certain pages, content is wrapped in multiple elements with both overflow:hidden and display:flex at the same time.
A (hopefully complete) reduced testcase, based on #823464 and a real-life testcase are attached.
Trying to print the whole content.
This is very similar to #823464 and possibly also to
#615803
#588288
#1602484
The display:flex part however is new/never mentioned in other reports I found.
Actual results:
The print preview is cut off.
Expected results:
Print should cover all the content seen in "normal" web view mode (as other browsers do).
Removing either overflow:hidden or display:flex solves the problem.
|
Reporter | |
Comment 1•5 years ago
|
||
|
||
Comment 2•5 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
|
||
Comment 3•5 years ago
|
||
What version of Firefox are you using? The UA string you posted doesn't look correct.
|
||
Comment 4•5 years ago
|
||
Your first attached testcase ("simple") renders just fine for me in Print Preview, for what it's worth. Could you provide more information about what's broken in that testcase? Note that that one also doesn't use flexbox (though the flexbox issue sounds like something that would've been fixed by bug 1633031 or a related bug, in or around Firefox 81, perhaps -- are you by any chance running a Firefox version that's older than Firefox 81?)
In your second testcase ("production"), I do see clipping -- it stops at 1 page in Print Preview -- but I see the exact same issue in Chrome.
Also, that second testcase starts printing all the pages for me (in Firefox as well as Chrome) if I add <!DOCTYPE html> to it, as a first line, to trigger standards-mode. So there must be some quirks-mode[1] behavior that's coming into play there, probably related to the height:100% that the testcase uses on the .main-container no-primary element (which skips a few auto-height parents and resolves against the viewport or printed-page-height in quirks-mode). If this bug is affecting a production website that you work on, I'd strongly suggest that you use <!DOCTYPE html> to trigger standards-mode in all browsers, which gives more predictable & reliably interoperable behavior. (See https://quirks.spec.whatwg.org/#introduction for more info on the legacy quirks-mode rendering that gets triggered if you don't declare a doctype.)
In any case: for now, I can't reproduce any sort of compatibility issue here -- testcase 1 seems to be WORKSFORME and testcase 2 seems to be INVALID (in the sense that it seems to be applying a cross-browser quirks-mode behavior that we share with other browsers). So I'm not sure there's actually a bug to be fixed here. Reporter: would you mind responding to the questions above and providing more info, if you are seeing a behavior-difference between e.g. Firefox and Chrome here?
|
|
||
Comment 5•5 years ago
|
||
Actually -- sorry, for the second testcase, I do still see breakage in Firefox release (version 84.0.2) even after adding a doctype, and I see breakage in nightly as well if I turn off the about:config pref layout.display-list.improve-fragmentation.
So there was indeed an issue that was hiding here, and it was fixed by the functionality that's behind the layout.display-list.improve-fragmentation about:config pref. Happily, that functionality is riding the trains to release via bug 1681052, and it should be fixed in Firefox beta 86, the beta version that went out this week.
So: reporter, if you wouldn't mind testing Firefox Beta[1] to see if you still see a discrepancy between Firefox and Chrome there, that would be great. (And as noted above, you might first need to add <!DOCTYPE html> in order to actually get anything beyond the first page in either Firefox or Chrome.)
[1] available at https://www.mozilla.org/firefox/channel/desktop/
|
|
||
Comment 6•5 years ago
|
||
(For convenience, here's the "production_site" testcase, with <!DOCTYPE html> added and no other changes. As noted above, this change is required in order to get >1 page of output in Chrome, as well as in Firefox builds that have the fragmentation-fallback feature enabled.
|
|
||
Updated•5 years ago
|
|
|
||
Comment 7•5 years ago
|
||
Resolving as FIXED by bug 1640197 (which is shipping to release in 86 via bug 1681052 as noted above), since the only compatibility issue that I could here seems to be addressed by that, as noted in comment 5.
Please reopen if you still see discrepancies between Firefox & other browsers in version 86 or newer, though. Thanks!
|
|
Reporter | |
Comment 8•5 years ago
|
||
Sorry for the late answer - something in my setup prevented me from getting email notifications.
The <!DOCTYPE html> has fallen prey to the reduction process for a minimal test case. It is part of the original markup.
However - and here come the good news - I can confirm that the currently available 86b9 does indeed fix the problem both on the simple testcase and on the production site!
Thanks a bunch!
|
|
||
Comment 9•5 years ago
|
||
Thanks for confirming that! Good to hear that it's indeed fixed.
Description
•