Unable to reproduce the issue on Mac OS 10.11.6 using chrome stable M52-52.0.2743.116 by following steps mentioned in the original comment. By entering window.print()in the console the print preview dialog pops up immediately as expected.

madskonradsen@- Could you please confirm is this issue seen on incognito mode as well? Please try rechecking it by creating a new profile under chrome://settings with no apps or extensions in your browser. If issue still persists please let us know on which OS platform you are seeing this issue.

Thanks!

Deleted: PrintPreview.mp4 1.1 MB

	PrintPreview.mp4 1.1 MB View Download

Attached the DOM(and CSS) in question. It renders pretty fast, but as soon as it comes to print-preview it takes 20+ with the "PDF printer" and significantly more with a Generic PostScript printer.

Seeing it on: macOS 10.11.3 (15D21)

Deleted: hey6.css 1.8 MB

hey6.css 1.8 MB View Download

Deleted: index.htm 3.2 MB

index.htm 3.2 MB View Download

Moving to UI>Browser>PrintPreview as it only affects printing.

eae: But there's nothing to fix on the printing side. We just tell Blink to redo the layout for printing.

Did this use to work better? And can you test in Chrome Canary as well (https://www.google.com/chrome/browser/canary.html)?

I tried on Linux here and it's always fast - ~2 seconds to render the print preview. Will try Mac next.

Do you have any extensions installed that might effect rendering? Try turning off all extensions and see if that makes a difference?

Equally fast on Mac.

thestig: Doesn't reproduce without print preview even with the exact same set of styles. Might be the PDF generation that is slow?

eae: Thanks for checking. Doesn't repro for me at all. Both display to screen and print preview rendering are fast here.

thestig: Interesting. Thanks!
cbiesinger: Any idea what might cause this behavior? Have we fixed any flexbox performance bugs lately?

cbiesinger: Were you able to repro? I tried 52.x (same as bug reporter), and also Chromium commits near [300000, 350000, 400000] and couldn't repro.

Using the supplied HTML/CSS and a completely clean Canary, it took 44 secs to render the print-preview when using the PDF Printer, and 42 seconds when generating the print-preview with a Generic PostScript printer as the "output".

We have not fixed perf bugs that recently; I did fix one in either 52/53 -- I forgot the exact release. But since Mads says this reproduces in Canary that's not it.

I can't reproduce on Linux in stable (52.0.2743.116) or dev (54.0.2840.6). And I can't reproduce on Windows with Canary 55.0.2845.0

Maybe it depends on the selected printer (affecting certain settings)? What paper size are you using? What are the other settings?

Hmm... But you can't reproduce with the supplied HTML and CSS-file and selecting PDF printer as target? I have tried on multiple computers(all Macs) with the same result... The fastest time I have experienced was 22 seconds on a completely new MacBook Pro.

I personally can't, but I also don't have a Mac available to test :/

Oh, of course I cannot repro. The provided example has a typo in index.htm and references "hey6.cs" instead of "hey6.css".

Looks like this regressed. Bisecting...

I'm sorry, I was a bit too quick. Here are the files again, with the reference corrected. Regressed? Were you able to reproduce anyway?

Deleted: index.htm 3.2 MB

index.htm 3.2 MB View Download

Deleted: hey6.css 1.8 MB

hey6.css 1.8 MB View Download

I just ernamed hey6.css to hey6.cs locally. I can reproduce.

https://chromium.googlesource.com/chromium/src/+log/8ee7ead3..99083a79 -> r333606 -> https://chromium.googlesource.com/chromium/blink/+log/0363313..4b91fed -> https://chromium.googlesource.com/chromium/blink/+/f879c1c0e892586c673f2552d65da646fc50c005 ?

Can we add a Blink component now? I really don't understand the Blink component rejection for printing bugs.

Could be the same as  bug 487026 . That one was reported for tables, but there may be similar issues for flexbox, because flexbox too does re-layout a lot, and that's currently very expensive when fragmenting into pages or columns, because we don't skip subtrees that haven't been marked for layout (which is a very important optimization).

Bisect leads to Morten's change

Right. So it's definitely the same as  bug 487026 , then. Mark as duplicate?

The issue persists in Canary Version 56.0.2908.0 canary (64-bit).
Might not be a duplicate, or the issue might have focused solely on table.

Looks like the fix for  bug 487026  didn't improve the situation here at all.

I suspect that bug 606350 needs to be fixed first. If we're lucky, fixing that will also fix this bug. :)

Attaching a simplified demo. I haven't reduced hey6.css (previously uploaded to this bug report), and my demo depends on it. I've just reduced the HTML so far.

It seems that the "Vis udskrift" overlay block in the original testcase actually doesn't contribute a lot to the slowness, while the stuff underneath (which even appears to be unprintable) does. So that's what my demo is based on.

Deleted: demo.html 2.6 KB

demo.html 2.6 KB View Download

Demo without dependency on hey6.css. Quite a lot of the slowness disappeared as I picked apart hey6.css, but I still think there's something here. Deeply nested flexboxes seems to be the problem, as suspected.

Deleted: demo2.html 2.6 KB

demo2.html 2.6 KB View Download

Back to demo.html - if I disable the cloning script, so that we only get one item (one column in one row), LayoutFlexibleBox::Layout() is invoked around 500 times when laying out for printing, while it's around 70 times when laying out for screen. It's also higher for printing than for screen with demo2.html, but the difference is not as big as it is for demo.html.

So I guess we're struggling a lot with vertical alignment and stretching when printing. I think the spec says that we shouldn't even attempt to do those things when fragmenting (printing, multicol), since it's pretty much impossible: stretching and re-alignment affects fragmenting (i.e. where we break to the next page), which in turn affects how we should stretch and align, which affects fragmenting, .... Circular dependencies.

Disabling the code responsible for causing multiple layout passes in flexbox "fixes" the performance problem.

I just tried the following, as an experiment: https://codereview.chromium.org/2869983003/patch/1/10001

This strongly suggests that we need to fix bug 606350 before we can fix this bug.

I hope this gets prioritised soon as I have a few thousand users affected by it.

The assigned owner "mstensho@opera.com" is not able to receive e-mails, please re-triage.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Hmm... The issue is very much triaged by Morten. Looking at Mortens twitter, he resigned from Opera to continue his work at Google, congrats on that! What's the process to get this back on track?

Blink>Layout folks need to retriage this bug. I have no idea what Morten is doing.

Is there any progress on this?

The bug is now 2 years and 7 months old. Any intent to prioritizing it? :)