Open Bug 939897 Opened 11 years ago Updated 3 days ago

[meta] Support shifting / splitting flex items between continuations of a fragmented flex container (flexbox content truncated when printing)

Categories

(Core :: Layout: Flexbox, task, P1)

Product:
Core
Component:
Layout: Flexbox
Type:
task

Tracking

()

People

(Reporter: dholbert, Unassigned)

References

(Depends on 4 open bugs, Blocks 2 open bugs)

Details

(Keywords: meta, Whiteboard: [frag2020][layout:backlog])

Attachments

(4 files)

display:flex; flex-flow:row; printing testcase
19.32 KB, text/html
Details
939897 - Support shifting - splitting flex items between continuations of a fragmented flex container.pdf
335.23 KB, application/pdf
Details
Bug 1315994 Firefox vs Chrome.png
458.36 KB, image/png
Details
Bug 1807406 Firefox vs Chrome.png
822.65 KB, image/png
Details 
The current patch stack on bug 811024 lets us split flex containers, but doesn't actually split the children or push any children out of the container's first continuation.

I'm filing this bug on splitting/pushing the children.
Summary: Support shifting / splitting flex items between continuations of the container → Support shifting / splitting flex items between continuations of a fragmented flex container
Blocks: 856235
Depends on: 969147
Depends on: 983427
I moved the testcease also. This bug was with the floated div in the past which one is fixed already, so this should be something similar.
Blocks: 1089549
Blocks: 521204
Blocks: 1233125
Walmart is now using display:flex for the main content element on its product pages, so this issue may become more salient. E.g.:

How can I print out this product's warranty information on walmart.com?
https://support.mozilla.org/questions/1130124
Google is now using display:flex on its "printable" directions, so we may start seeing more support questions related to truncated content. E.g.:

When printing maps with directions from Google Maps, I can only print part of the directions.
https://support.mozilla.org/questions/1132728
Blocks: 1288734
Blocks: 1302489
This is likely the reason that bugzilla.mozilla.org itself (e.g. this bug page) is now truncated to one page of output, when printed/print-previewed.
Summary: Support shifting / splitting flex items between continuations of a fragmented flex container → Support shifting / splitting flex items between continuations of a fragmented flex container (flexbox content trunctated when printing)
Sorry if this is the wrong place for this comment, but THIS page itself (https://bugzilla.mozilla.org/show_bug.cgi?id=939897) only prints page 1 in firefox now as #wrapper uses display:flex.

With the popularity of flexbox, Firefox can't print a sizeable portion of the web.

Blocks: 1559961

I updated a system's front-end to bootstrap 4 for a company, and they have many long printable pages. They have been using Firefox for the past 8 years because I recommended it to them. Now I have to tell them to move to Chrome because of this bug.

Summary: Support shifting / splitting flex items between continuations of a fragmented flex container (flexbox content trunctated when printing) → Support shifting / splitting flex items between continuations of a fragmented flex container (flexbox content truncated when printing)
Priority: -- → P2
Whiteboard: [layout:backlog]
Blocks: 1315994
Blocks: 1303221
Whiteboard: [layout:backlog] → [layout:backlog][layout:print-triage:p1]
Blocks: 1565186

I confirm that this bug affects projects like Bootstrap4 and all the projects based on it (e.g. GlobaLeaks) as reported here:

Blocks: 1601429

Reassigning to reflect current ownership.

Assignee: dholbert → aethanyc
Whiteboard: [layout:backlog][layout:print-triage:p1] → [layout:backlog:2020q1][layout:print-triage:p1]
Blocks: 1613188
Whiteboard: [layout:backlog:2020q1][layout:print-triage:p1] → [frag2020]
Whiteboard: [frag2020] → [frag2020][layout:backlog]

This bug collects a lot of duplicates, and can have more before we fix it completely. To reduce the distraction and to break this bug into smaller tasks, I'd like to transform this bug into a meta bug. All the development should happen in the dependencies.

Component: Layout → Layout: Flexbox
Keywords: meta
Summary: Support shifting / splitting flex items between continuations of a fragmented flex container (flexbox content truncated when printing) → [meta] Support shifting / splitting flex items between continuations of a fragmented flex container (flexbox content truncated when printing)

Printing a page is the most basic/fundamental functionality. Yet, this bug has been 7 years old and still exists in the most recent v75.0. If it doesn't get fixed, there will have more "duplicates" to come, or maybe it's time to move to another browser...

(In reply to ynotswim from comment #52)

Printing a page is the most basic/fundamental functionality. Yet, this bug has been 7 years old and still exists in the most recent v75.0. If it doesn't get fixed, there will have more "duplicates" to come, or maybe it's time to move to another browser...

We are working on fixing this right now. It's one of our highest-priority projects at the moment.

(In reply to Sean Voisen (:svoisen) from comment #53)

(In reply to ynotswim from comment #52)

Printing a page is the most basic/fundamental functionality. Yet, this bug has been 7 years old and still exists in the most recent v75.0. If it doesn't get fixed, there will have more "duplicates" to come, or maybe it's time to move to another browser...

We are working on fixing this right now. It's one of our highest-priority projects at the moment.

Hi,

Since you are working now on this bug that affects printing, please also take a look at bug 1604474, that also affects printing.
On bug 1604474, seems that some of the testcases are duplicates of bug 939897, but there are other testcases (for instance, the doomworld.com testcase) that are not a duplicate of bug 939897.

Like ynotswim said, printing is a fundamental functionality. Every time I want to print a webpage, I have to use Chrome, and this goes on for years now.
Firefox is provided free of charge, and it's my favourite browser since it came out. I'm not complaining about the people that make Firefox, I thank you for all your efforts.

There is also the bug 1201473, that doesn't seem to be a duplicate of bug 939897 and that it seems to affect printing.

Thank you.

(In reply to filipemaia from comment #54)

(In reply to Sean Voisen (:svoisen) from comment #53)

(In reply to ynotswim from comment #52)

Printing a page is the most basic/fundamental functionality. Yet, this bug has been 7 years old and still exists in the most recent v75.0. If it doesn't get fixed, there will have more "duplicates" to come, or maybe it's time to move to another browser...

We are working on fixing this right now. It's one of our highest-priority projects at the moment.

Hi,

Since you are working now on this bug that affects printing, please also take a look at bug 1604474, that also affects printing.
On bug 1604474, seems that some of the testcases are duplicates of bug 939897, but there are other testcases (for instance, the doomworld.com testcase) that are not a duplicate of bug 939897.

Thanks, we will revisit the other testcases on that bug.

Like ynotswim said, printing is a fundamental functionality. Every time I want to print a webpage, I have to use Chrome, and this goes on for years now.
Firefox is provided free of charge, and it's my favourite browser since it came out. I'm not complaining about the people that make Firefox, I thank you for all your efforts.

Agreed, there are various cases where printing in Firefox needs improvement, and over the course of the next several months you should start to see changes for the better. If you want to track the work we are doing that is focused on printing, you can follow this wiki page: https://wiki.mozilla.org/Platform/Layout/Printing_and_fragmentation

Depends on: 1635225

Now that we triage by severity, setting priority to P1 to reflect backlog prioritization on this bug as either in-progress, or planned development in the near term. See https://wiki.mozilla.org/Platform/Layout#Backlog_Tracking_in_Bugzilla

Priority: P2 → P1
Severity: normal → S2
Type: defect → task
No longer blocks: 1613188

Unassign myself because this bug turns into a meta bug. That is, development / patches will be in bugs blocking this one.

Assignee: aethanyc → nobody
Status: ASSIGNED → NEW

Greetings. I'm still having problems in FF 79 with Firefox's inability to render a complete printout of countless webpages. Is this long-standing issue anywhere near being resolved? If it goes on much longer it will be competing with Homer's Odyssey. I went to create a pdf of a webpage this evening, but as usual FF only gave me a 2-page pdf (pages 1 and 17). Once again I had to turn to Safari which provided me with a complete pdf of all 17 pages. If it's necessary for me to attach the 2 pdfs I made which demonstrate the disparity between FF's version and Safari's version I'll be happy to do that. I assume you already have copious examples of webpages that do not print out fully when using FF so I will not attach them here unless they are requested. Please let me know if this issue will ever be resolved or if I should just abandon Firefox and stick with Safari. We Firefox fans are loyal, but this is really pushing it. Thank you.

Re comment 59:

Hi youngjane1118,

It definitely helps if you could file a bug under "Printing: Output" component via https://bugzilla.mozilla.org/enter_bug.cgi?product=Core, and attach the URL of the webpage in the description that Firefox failed to produce the correct pdf. It could help us understand the possible cause and adjust the priority if the same root cause is showing up more frequently. Thanks!

(In reply to youngjane1118@hotmail.com from comment #59)

I went to create a pdf of a webpage this evening, but as usual FF only gave me a 2-page pdf (pages 1 and 17). Once again I had to turn to Safari which provided me with a complete pdf of all 17 pages.

As a temporary workaround, you could try an extension:

  • Print Edit WE: part of the Recommended add-ons program. On its toolbar, look for Tools > Fix Page Breaks.
  • Printable – The Print Doctor: this is my extension and I look forward to it becoming obsolete. Often a click on the first button is all you need to get a printable layout.
Depends on: park-wta
Depends on: 1677339

Just noticed a similar issue to 1615274 on https://zajno.com/

Webcompat Priority: --- → ?
Depends on: 1742024
Depends on: 1739561
Webcompat Priority: ? → P1

Given the improvements from bug 1622935, this isn't as severe anymore; we can drop this to S3.

Severity: S2 → S3
See Also: → 1775142
See Also: 1775142 →
Blocks: 1885849
Webcompat Priority: P1 → ?

RE the WebCompat Priority tweak -- I think we can unset that flag entirely at this point -- doing so.

The one associated WebCompat issue ( https://webcompat.com/issues/26052 ) is worksforme in current Nightly; and most of the pain here was addressed in helper-bug 1622935 per comment 63.

Webcompat Priority: ? → ---

Following the OKR task requested, we have performed QA testing on related bugs mentioned in the META bug. Below are the results:

Investigated the following opened bugs for META 939897:

These are opened corresponding bugs in the meta bug.

Investigated the following closed bugs:

reproducible:

can't test:

  • 969147 no test cases, links available for QA testing
  • 983427 no test cases, links available for QA testing
  • 1620490 no test cases, links available for QA testing
  • 1633028 no test cases, links available for QA testing
  • 1633031 no test cases, links available for QA testing

fixed:

invalid:

Please let us know if more info is required

(In reply to Raul Bucata from comment #65)

Following the OKR task requested, we have performed QA testing on related bugs mentioned in the META bug. Below are the results:

Thanks, this is super thorough and handy!

Request for the future: rather than using markdown with [](), it'd be slightly more informative to write these comments just using bugzilla's auto-linkification of "bug nnn" (no manual linkification needed). If you do that, Bugzilla will helpfully add strikethroughs for closed bugs, and it'll also show a tooltip for the bug title/status when you hover the bug link. Whereas the bugs in comment 65 have no tooltip and no indication of whether they're currently open or closed (other than the headings that you added).

Anyway, doing a quick pass over your closed-but-reproducible bugs (the most interesting /attention-worthy category in comment 65):

Investigated the following closed bugs:

reproducible:

  • 811024 based on test case shows broken icons in Chrome, but not in Firefox

[not worried] This broken icons presence/absence is just a behavior difference between how Chrome and Firefox show img elements with no src attribute (not a bug, not related to flex fragmentation). Reduced testcase for that is data:text/html,<img src="" style="border:1px solid black;height:100px;width:100px">and it's not worrisome.

  • 1843228 based on test case reproduces, as the layout is not the same (no overlapping elements though)

[not worried] At first glance, this "layout is not the same" thing is just due to font differences or similar, which cause the amount-of-content-that-fits-in-a-column to be different.

Can you elaborate on what reproduces here? When I print-preview the testcase attached there (the one that you linked), I see all 68 rows. The printout is not truncated or obviously broken. (The only issue I see is that some borders are missing between rows -- not sure if that's the issue you were seeing, but that's bug 1775345 (which is a duped to an older more-general bug).

Can you elaborate on what you mean by "somehow reproducible" here? As above, I don't see any issue aside from the missing borders (which is bug 1775345)

Can you elaborate? The "test case" that you linked here is not actually a testcase; it's a PDF printout that the reporter attached when filing the bug, showing how Firefox at-the-time printed the site. The real testcase for that bug is https://getbootstrap.com/docs/4.0/layout/grid/ and it seems to have changed since the bug was filed (the content is different from what's shown in that PDF); but in any case I'm not seeing any issues when I print-preview it in current Nightly.

Flags: needinfo?(rbucata)
Flags: needinfo?(rbucata)

Thanks, Daniel for the reply and extra info. We have made these comments first on GitHub, where we have an OKR set in place for this task, after investigating x amount of reports in a given day. Copying the comments when all investigations were completed felt much easier and less time-consuming. But we will take that into consideration for future reference.

Investigations were done from the Webcompat point of view, meaning that any differences compared to Chrome as considered reproducible.

  • Regarding Bug 1089549: yes, some borders are missing when in print preview.
  • Regarding Bug 1807406: besides the missing border, the layout seems different. For example, the first paragraph in Firefox has 6 words in the last row( "fugiat quo voluptas nulla pariatur"), compared to just one in Chrome ("pariatur"). Also, the pagination is misplaced, and the timestamp.
  • Regarding Bug 1315994: some borders are missing or are not bolded enough, for example inside the search field, and the first image is missing as well.

I have attached screenshots for the last 2 mentioned bugs.

Please let me know if you need extra info.

(In reply to Raul Bucata from comment #69)

Thanks, Daniel for the reply and extra info. We have made these comments first on GitHub, where we have an OKR set in place for this task, after investigating x amount of reports in a given day. Copying the comments when all investigations were completed felt much easier and less time-consuming. But we will take that into consideration for future reference.

Ah, that makes sense RE the bug linkification; never mind then.

Thanks for the additional details. Fortunately, none of the differences are particularly concerning or relevant to the implementation internals here. I'll add notes below, to close the loop on them.

  • Regarding Bug 1089549: yes, some borders are missing when in print preview.
    [...]
  • Regarding Bug 1315994: some borders are missing or are not bolded enough, for example inside the search field, and the first image is missing as well.

The missing/faint borders there are bug 1775345, yeah.

The image (an ad) is there for me in Firefox-with-a-fresh-profile, when I view the page in a regular browser as well as print-preview. Perhaps you've got an ad-blocker in the Firefox profile that you were using, which successfully blocked that ad image? (The image does disappear if I use uBlock origin, for example.) If you're not using an ad-blocker, maybe the ad was just on a delayed load and wasn't ready yet when you print-previewed; there are a bunch of things that could have gone wrong, but when it's there it does render properly in print-preview on my end.

  • Regarding Bug 1807406: besides the missing border, the layout seems different. For example, the first paragraph in Firefox has 6 words in the last row( "fugiat quo voluptas nulla pariatur"), compared to just one in Chrome ("pariatur"). Also, the pagination is misplaced, and the timestamp.

The linewrapping differences and page-breaking (how many paragraphs / how much space remains after the last paragraph) aren't concerning there; those are almost certainly just from browser-specific font selection differences (which then impacts how many words fit on a line, and the height of each paragraph; and how many table-rows-with-a-paragraph fit on a page before we have to force a page-break).

The headers/footers (including timestamp) are metadata that the browser adds to a printed page, at a location that the browser decides on itself; they're not part of the web content. (The fact that we place them right at the edge is arguably not-great; that's bug 1669910.)

Thanks for the reply and the insightful information. Glad we could help.

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

Attachment

General

Creator:
Created:
Updated:
Size: