I see the same issue in Chrome 56.0.2906.0. Print -> "Loading preview..." never ends, even when trying to print something as simple as www.google.com.

I clicked Print, but nothing happens.

I'm a Googler on the corp network, and had selected one of our crop printers.

Deleted: Print preview never ends.png 69.6 KB

	Print preview never ends.png 69.6 KB View Download

Unable to reproduce the issue on Linux chrome version 54.0.2840.90 and dev 56.0.2906.0 - Printed successfully

 dandv@, Could you please recheck the same and update the thread.

Original bug reporter: This might be  bug 487026  or bug 640187. Please try 56.0.2906.0 or newer and see if the situation has improved. If not, mstensho can help you out if you share the email in question with them privately.

re: comment 1- Please file a new bug. In your case, the print preview never finishes, which is a different bug altogether.

Regarding the slowness - Printing dialogs, whether it be print preview or the system dialog, needs to know how many pages of paper a webpage would print to. Otherwise the printing dialogs cannot verify is the user's page range input is valid or not. In this bug, and some of the bugs I referred to, the webpage layout is unfortunately extremely slow.

Out of curiosity, when the print preview took minutes, what kind of computer did this take place on? Was the CPU a Core 2 Duo or something like that?

One thing is the excessive slowness in rendering the preview and/or calculating the number of pages, another thing is freezing the whole browser because something is taking long.

Correct me if I'm wrong: the bugs you mention, of which one is fixed, only address the first kind of issue. Even if all bugs making the computation slower than it should were fixed, a page may still legittimately take long to render if, for example, it's content is hugely complex. So responsiveness of the UI, visual feedback about ongoing progress (not necessarily a percentage or completion or estimated time but at least the *fact* that it is in progress) and possibility to interrupt and cancel it immediately, are a MUST.

> Out of curiosity, when the print preview took minutes, what kind of computer 
> did this take place on? Was the CPU a Core 2 Duo or something like that?

An i7

Sure, we can certainly assume the rendering is slow and try to make the UI more responsive, or rather, not let it get stuck.

 Bug 487026  can be simulated by putting a long sleep() right before the printBegin() call in PrepareFrameAndViewForPrint. One can actually cancel out of print preview by pressing Esc. (Assuming the keyboard has such a key. ;)) Though there's no way to do it by clicking.

However, even if we do that, the renderer is still stuck doing whatever its doing. So the experience the user sees once they exit print preview is still poor because the renderer is stuck in Blink and cannot get out until it finishes. There needs to be some way of signaling to Blink (or have Blink periodically call a callback to check) that it is time to stop printing and get on with things... and have it then successfully bail out.

i.e. making the Print Preview cancel button stay enabled and act as Esc is easy. Getting Blink to stop what it is doing is harder. We need someone who actually understands Blink for input on whether that is a good idea / is feasible.

> One can actually cancel out of print preview by pressing Esc

I think you missed the point.

If you follow my steps 1-4 skipping step 3, that is, you click on "print with system dialog" while Google Chrome's Fancy Print Preview is still rendering, then a series of things are completely screwed up:

i. This should abort rendering the print preview in the first place, and it doesn't
ii. I am not supposed to know that hitting the Esc key will do anything
iii. What the Esc key does in this case is completely screwed up: it looks like it aborts the "print with system dialog", it ALSO exits the print preview completely (which is unexpected), but then, at a later time, the system printing window pops up when you thought you had given up printing minutes ago and completely forgot about it.


> Sure, we can certainly assume the rendering is slow and try to make the
> UI more responsive, or rather, not let it get stuck.

Not sure what you mean. If by "not let it get stuck" you mean not let the UI get stuck because a given task is slow, then that is the same as "assume the rendering is slow and try to make the UI more responsive", that is, fix the bug I'm talking about.
If, otoh, by "not let it get stuck" you mean "not let the rendering get stuck", i.e. "not let it be insanely slow", then sure, you have to do that, but that's not enough. No matter how fast the rendering is, you can never, ever assume it to be always instantaneous ("instantaneous" meaning something below a perceivable duration, that is, in practice, a few milliseconds or less), that is, you HAVE to acknowledge that there can be cases where it will take long (again, even if "long" means more than a few milliseconds), and you mustn't let that cause the UI to become unresponsive.

In other words:
"we can certainly assume the rendering is slow and try to make the UI more responsive, or rather, not let it get stuck."
Either both mean the same thing, or you have to do both.

I don't think I missed the point. Please stop assuming the worst.

i. That's exactly what I'm talking about. Blink is still rendering the print preview. There's no mechanism to abort right now.
ii. I acknowledged this. To repeat: "Though there's no way to do it by clicking."
iii. Ah, I didn't wait long around long enough to see that happen. Will keep that in mind.


By "not let it get stuck" I mean what you want it to mean. Note I said to simulate slowless by putting in a long sleep(). That means I'm artificially creating renderer slowness.

Attaching a trace (https://www.chromium.org/developers/how-tos/trace-event-profiling-tool) would be helpful so that we can understand where the slowness comes from.

No feedback in three months, closing issue. Please comment to reopen.