( copied from http://crbug.com/157913 ) What steps will reproduce the problem? 1. Launch Chrome with --force-compositing-mode (note: does not repro on Linux, where it looks like force-compositing-mode has been explicitly disabled) 2. Navigate to https://chromiumcodereview.appspot.com/11266023 3. Click any of the "View" links under the side-by-side diffs column What is the expected output? What do you see instead? Expect that the new page is displayed. Instead, the old page continues to be drawn until scrolled. Bisecting indicates a WebKit roll: You are probably looking for a change made after 163537 (known good), but no later than 163543 (first known bad). WEBKIT CHANGELOG URL: http://trac.webkit.org/log/trunk/?rev=132193&stop_rev=132013&verbose=on&limit=10000 CHANGELOG URL: http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=/trunk/src&range=163537%3A163543 and investigation of the WebKit revisions points to: [chromium] Suppress compositor invalidations during FrameView recreation in force-compositing-mode https://bugs.webkit.org/show_bug.cgi?id=99882 http://trac.webkit.org/changeset/132173/trunk This was discovered on Canary on Mac, where I believe the force-compositing-mode experiment is still in place.
Created attachment 170720 [details] Patch
Comment on attachment 170720 [details] Patch R=me.
Comment on attachment 170720 [details] Patch Clearing flags on attachment: 170720 Committed r132533: <http://trac.webkit.org/changeset/132533>
All reviewed patches have been landed. Closing bug.