Able to reproduce the issue on reported chrome version 67.0.3396.62 and on latest chrome# 69.0.3448.0 using Windows-10, Mac 10.12.6 & Ubuntu 14.04  hence providing Bisect Info
Bisect Info:
================
Good build: 67.0.3371.0
Bad build: 67.0.3372.0

You are probably looking for a change made after 543290 (known good), but no later than 543291 (first known bad).
https://chromium.googlesource.com/chromium/src/+log/63667eca2a1d86f5de61f29c7c5c6417cc351757..3a3c78a924a686ed0d3f90d765b00cdd78453e11
Reviewed-on: https://chromium-review.googlesource.com/923572

@Xianzhu Wang: Please confirm the issue and help in re-assigning if it is not related to your change.
Adding ReleaseBlock-Stable as it is seems a recent break, feel free to remove it if not applicable.

Thanks!

Are you talking about the flash when the facing page is closed and switches to single page? Could we get a screen video to show us the problem?

+pbommana@, could you ptal comment #3 and #4 pls after you're done with bisecting other bug?

Please find the attached screen recording which I am assuming what user's are seeing.

Deleted: Jun 4 2018 12_51 PM.webm 18.8 MB

Jun 4 2018 12_51 PM.webm 18.8 MB Download

Let's target this to M68.

Here's a gif that I forgot to attach to original ticket.

Deleted: glitch.gif 15.5 MB

glitch.gif 15.5 MB Download

Fixing this is really important for us and all our clients, so it would be really great if the fix will get in the earliest version.

Hi eugene.lindeman@flippingbook.com, we may need some time to fix the bug. Before the fix is available (in M68 based on current plan), can you try the following change in the page to workaround the issue:

add "will-change: transform" in:

#publication .page-content .content-container {
    position: relative;
    z-index: 1;
}

This will help the browser to optimize the animation.

Hello, wangxianzhu@!
We'll test it for a bit, but it looks like the workaround is working. Thank you!

I can confirm that this has been fixed using the CSS workaround above provided by wangxianzhu! Much appreciated, I knew it was working yesterday and then today it was messing up and the only change was a chrome update.

eugene.lindeman@, Please confirm can we close this issue as per C#11? 
Thanks..!

We can't close the issue because the underlying bug still exists. The reporter has a workaround that reduces the priority, but we still need to fix the problem.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d7159f19dbe1ac83ad7462c9b8c7f4921b4e5522

commit d7159f19dbe1ac83ad7462c9b8c7f4921b4e5522
Author: Xianzhu Wang <wangxianzhu@chromium.org>
Date: Wed Jun 13 23:35:11 2018

[PE] Detect clip and effect node change in their transform space etc.

Previously, if a clip was between two transforms, and the clip result
was not tight, and the combination of the two transforms didn't change,
we missed raster invalidation for the changed effective clip.

Now check for change of LocalTransformSpace for clip and effect nodes.

Bug:  848782 
Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_slimming_paint_v2;master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: I1b60ecc2bc79cba69c667e188053b024de670361
Reviewed-on: https://chromium-review.googlesource.com/1094202
Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org>
Reviewed-by: Tien-Ren Chen <trchen@chromium.org>
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#567045}
[add] https://crrev.com/d7159f19dbe1ac83ad7462c9b8c7f4921b4e5522/third_party/WebKit/LayoutTests/paint/invalidation/clip/clip-between-changed-transforms-expected.html
[add] https://crrev.com/d7159f19dbe1ac83ad7462c9b8c7f4921b4e5522/third_party/WebKit/LayoutTests/paint/invalidation/clip/clip-between-changed-transforms.html
[modify] https://crrev.com/d7159f19dbe1ac83ad7462c9b8c7f4921b4e5522/third_party/blink/renderer/platform/graphics/paint/clip_paint_property_node.cc
[modify] https://crrev.com/d7159f19dbe1ac83ad7462c9b8c7f4921b4e5522/third_party/blink/renderer/platform/graphics/paint/clip_paint_property_node.h
[modify] https://crrev.com/d7159f19dbe1ac83ad7462c9b8c7f4921b4e5522/third_party/blink/renderer/platform/graphics/paint/effect_paint_property_node.cc
[modify] https://crrev.com/d7159f19dbe1ac83ad7462c9b8c7f4921b4e5522/third_party/blink/renderer/platform/graphics/paint/effect_paint_property_node.h
[modify] https://crrev.com/d7159f19dbe1ac83ad7462c9b8c7f4921b4e5522/third_party/blink/renderer/platform/graphics/paint/paint_property_node.h
[modify] https://crrev.com/d7159f19dbe1ac83ad7462c9b8c7f4921b4e5522/third_party/blink/renderer/platform/graphics/paint/paint_property_node_test.cc
[modify] https://crrev.com/d7159f19dbe1ac83ad7462c9b8c7f4921b4e5522/third_party/blink/renderer/platform/graphics/paint/raster_invalidator.cc
[modify] https://crrev.com/d7159f19dbe1ac83ad7462c9b8c7f4921b4e5522/third_party/blink/renderer/platform/graphics/paint/raster_invalidator_test.cc
[modify] https://crrev.com/d7159f19dbe1ac83ad7462c9b8c7f4921b4e5522/third_party/blink/renderer/platform/graphics/paint/transform_paint_property_node.cc
[modify] https://crrev.com/d7159f19dbe1ac83ad7462c9b8c7f4921b4e5522/third_party/blink/renderer/platform/graphics/paint/transform_paint_property_node.h

Unable to verify the issue on latest chrome canary# 69.0.3480.0, as this somehow is not reproducible on reported chrome version# 67.0.3396.62 as per the URL provided in Comment#0.

Thanks!

wangxianzhu@: Shall we get the merge to M-68 as well or will this be safe enough to merge to M-68 so late in the branch?

Vlad can you please merge to M68?

Actually, nevermind. 

This bug requires manual review: We are only 10 days from stable.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), kariahda@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

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

Has this been verified in canary? Seems like fix has been out for a while. How safe is this merge overall and does it have any stability implications?

Since it's present in M67, my recommendation is to wait until M69. Let me know if you disagree. 

If the merge is not required, then is this issue fixed?

I think we say it's fixed. The reporter has a workaround so the impact is mitigated if we keep the bug in M-68.