https://codereview.chromium.org/2063473002 is in that range too, and feels a bit more likely. It was just reverted in https://codereview.chromium.org/2101823002/ .

Does this repro top-of-trunk?

On top-of-trunk, the issue still reproducing. Reverting the CL 
"""
Increase PDF display timeouts
"""
fixes the problem.

Link to CL: https://codereview.chromium.org/2057143003

Does the flickering continue indefinitely? I'm sometimes seeing some flicker during the transition from one page size to another but it doesn't seem any better or worse than on stable.

I'm unable to repro on Windows so maybe this is Mac only - I'll try on a Mac soon.

Does it happen with print-preview with other PDFs?

I tried on OSX with canary and with stable and I'm not sure I can see the difference.

On stable (with 'background graphics' option set) when I change the page size I see a quick fade-out/fade-in animation, with the fade-in returning to exactly the same image, and then the image 'jumps' to the new page size.

On canary the behavior is somewhat different but not obviously better or worse. A few observations:

1) It's not clear what is *supposed* to be happening. I assume that the image is supposed to fade out from the current setting and then fade in with the new setting, but that is not happening on any version.
2) Since my CL just changed the timeouts it is likely that the behavior is highly dependent on the PDF being displayed and the speed of the machine being used.

My guess is that the animation between pages has always tried to run at 60 fps. Previously it would, on some machine/PDF combinations, timeout and therefore hit 0 fps, meaning that there was no flicker because none of the desired frames ever got displayed.

Now that the timeout is increased the animation runs at a low but non-zero frame rate on many PDFs, which is different and not clearly better. It would be helpful to test with some very large and very simple PDFs. A good example of a large PDF is https://upload.wikimedia.org/wikipedia/commons/f/fd/West_Bank_Access_Restrictions.pdf

It's not clear that the print preview animation for PDFs is a good idea, since there is no guarantee that any particular frame rate is maintainable.

Some other good test PDFs include:

 crbug.com/318175  - http://www.valvesoftware.com/publications/2011/ValveXperf-Dawson.pdf
 crbug.com/318175  - http://media.steampowered.com/store/steammachines/SteamMachinesBroc_WEB.PDF
crbug.com/582752 - https://upload.wikimedia.org/wikipedia/commons/f/fd/West_Bank_Access_Restrictions.pdf
 crbug.com/523915  - https://people.apache.org/~xli/presentations/history_Intel_CPU.pdf
crbug.com/617365 - https://www.ets.org/Media/Tests/GRE/pdf/gre_research_validity_data.pdf
 crbug.com/619117  - http://www.suncadiaresort.com/assets/pdfs/June%202016_Activity%20Guide_web.pdf
 crbug.com/439283  - http://www2.futureware.at/novena/01docmap.pdf

Some feedback from somebody who knows more about the print preview animations would be helpful.

Ping! Can I get more details of the regression, perhaps a video showing the flickering? I cannot reproduce the problem on Mac and I can't evaluate whether it is a fatal problem or a minor issue.

My CL makes scrolling on many PDFs dramatically better so making one situation slightly worse should not necessarily have a veto.

With respect to comment 6:

Kindly refer the attached video. 

Deleted: Actual_Result.mov 2.2 MB

Actual_Result.mov 2.2 MB Download

Deleted: Expected_Result.mov 2.5 MB

Expected_Result.mov 2.5 MB Download

Issue can be seen on mac 10.11.5 latest canary version 54.0.2787.0

Please find the video showing actual and expected result

Deleted: Expected_Result.mov 2.5 MB

Expected_Result.mov 2.5 MB Download

Deleted: Actual_Result.mov 2.2 MB

Actual_Result.mov 2.2 MB Download

Thanks. The videos are very helpful. I had to watch them at 0.25x to understand what is going on but it does make more sense now.

In Expected_Result.mov I see that the image fades out, and then fades back in (to the same image). Then it snaps to the new paper size.

In Actual_Result.mov I see that the image fades out, and then snaps to a window-filling version of the original image. Then it snaps to the new paper size.

My assumption is that what is supposed to happen is that the image is supposed to fade out, and then the new image fade in. This means that the behavior is broken in both cases - my change has perturbed the bug, but hasn't changed it.

alekseys@ - I think this is an existing bug in print_preview_animation.js that has been perturbed by my timeout change. The timeout is presumably not part of the PDF API contract so it seems like print preview should be more resilient to it changing - plus the old behavior does not seem to WAI. Thoughts?

alekseys@: Can get an update on this Blocker issue as per C#9.

pinging again as this is marked as RBS, alekseys@ could you please check and update.

@alekseys -- Could you please provide an update on the issue as there is Stable Release scheduled this week.
Thank You.

Gentle Ping.

@alekseys: Could you please provide us some update as per the comment #9

Thank you.

print_preview_animation.js was not changed in a really long time, if it needs to be adjusted to the new reality, new sequence and timing of events, then yes, we need to fix it. Back then I was working on Print Preview, the new UX design was in the air, so I postponed UI elements changes until it materializes, but priorities changed (apparently). Assigning it to the new code owner.

M53 Stable launch is coming soon.Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix asap so it gets chance to bake in beta before stable promotion. Thank you.

I took a quick look at the code, see if anything stands out (have not worked on print preview for many years).

First, print_preview_animations.js seems responsible for animating various controls on the left (dropdown options, buttons etc), so it is irrelevant to the problem. The code that controls the animation on the right is in preview_area.js (see [1]). Try the following in the dev console

printPreview.previewArea_.setOverlayVisible_(true); // shows the overlay
printPreview.previewArea_.setOverlayVisible_(false);  // hides the overlay

Without being too familiar with the code it seems that the plugin might be the culprit (meaning that the plugin changed its behavior). The JS code is simply registering a callback (line 533), and when it is called, it hides the overlay (line 653). It seems that given the latest changes within the PDF plugin, this callback is called prematurely (the contents of the plugin are still being painted).

Note that the fade-in animation is particularly slow which also contributes to the problem, causing sometimes the flickering to be seen even before the overlay is shown (as opposed to be seen only after it fades out).

[1] https://cs.chromium.org/chromium/src/chrome/browser/resources/print_preview/previewarea/preview_area.js?l=533,653

@thestig: Gentle Ping.

Could you please provide an update on this issue.

Still able to repro this issue on Chrome Canary Version - 54.0.2823.0

Thank you.

It's on my radar, but I haven't had time to look yet.

M53 Stable launch is coming VERY soon.Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix asap so it gets chance to bake in beta before stable promotion later this month. Thank you.

This was next in my queue, but I have a P0 bug to work on, so this may just have to slip a bit. This bug is just a bad animation transition and has no functional impact on printing.

@thestig: Feel free to remove the blocker label if the above issue doesn't fall into blocker category.

Appreciate your help.

Thank you!

@thestig: Gentle Ping.

Could you please provide an update on this issue.

Still able to repro this issue on Chrome Canary Version - 54.0.2835.0

Thank you.

A friendly reminder that M53 Stable is launching VERY soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP (before 5:00 PM PT, Tuesday) so we can take it for this week LAST Beta release for Desktop. Thank you!

Note: Merge has to happen by Friday, August 26th, 5:00 PM PST in order to make into the desktop Stable final build cut. 

Putting to M54.

Still able to reproduce the issue on Chrome Canary Version - 55.0.2872.0

thestig@, Could you please take a look at this

@thestig -- Could you please respond to Comment# 25 and update the issue.
Thank You.

 Issue 762933  has been merged into this issue.

With the New Print Preview UI, there is now a proper transition animation with setting changes, so one no longer sees the flickering. We can probably close this once the New Print Preview UI launches to stable.

New UI has launched to Stable as of M71. Closing this as WontFix, please re-open if this is still an issue in Chrome 71+.