Bug 100396 – [chromium] Regression: navigating between composited pages doesn't cause redraw until scrolled

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Kenneth Russell]

( 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.

[James Robinson]

Created attachment 170720 [details]
Patch

[Adrienne Walker]

Comment on attachment 170720 [details]
Patch

R=me.

[WebKit Review Bot]

Comment on attachment 170720 [details]
Patch

Clearing flags on attachment: 170720

Committed r132533: <http://trac.webkit.org/changeset/132533>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.