Flash of white can occur if JS forces an early layout

• Component: Layout and Rendering
• Status: RESOLVED FIXED

[Ben Nham]

Created attachment 390306 [details]
repro case

In https://bugs.webkit.org/show_bug.cgi?id=134833, we added in a hack to force a layer flush on first layout on Mac (rather than waiting for first non-empty layout as we do for all other platforms). This can cause a flash of white if the first layout creates an empty render tree, e.g. if JS forces an empty layout early on in the page. We also see this flash-of-white issue in several real-world webpages on our PLT test suite, e.g. NYT and FB.

We should probably revert this change. This fixes the issue in our PLT content and in the attached repro case (which can be run by executing something like `php -S localhost:8081` and then navigating to http://localhost:8081).

[Radar WebKit Bug Importer]

<rdar://problem/59329999>

[Ben Nham]

Created attachment 390315 [details]
Patch

[Ben Nham]

I've verified that this patch fixes the repro case as well as the flash of white on NYT and FB PLT content.

I'm also kicking off some PLT5 A/B tests to make sure this doesn't cause a perf regression. I don't anticipate one since in theory an extra paint on FirstLayout should not cause DidFirstVisuallyNonEmptyLayout to fire any later (if anything, it could marginally help).

[Ben Nham]

The original reason why we did https://bugs.webkit.org/show_bug.cgi?id=134833 years ago was for a scenario like this:

1. Open Safari with status bar enabled
2. Cmd+F for some text on a page
3. Click on some link with the find bar still open
4. A 20px white gap appears where the status bar used to be

I can no longer repro this issue with the current Safari with the current patch (which is good).

[Antti Koivisto]

Might want to check if those test failures are real.

[Ben Nham]

*** Bug 204828 has been marked as a duplicate of this bug. ***

[Ben Nham]

Created attachment 390704 [details]
Patch

[Ben Nham]

The latest patch should fix the test failures.

* fast/scrolling/rtl-scrollbars-listbox-scroll.html: This test was scrolling a list box from an inline script as the main resource was being parsed. Since the list box is not enough to be considered visually significant, after this patch we don't render the list box until after the inline script executes. Fixed by moving the scrolling code to after the document finishes loading.
* imported/w3c/web-platform-tests/css/css-transitions/before-load-001.html: As the top of this file indicates, this doesn't actually test behavior specified in the standard. It produces different results depending on when first paint occurs. As a result, we had already skipped this test on iOS where it was failing (https://bugs.webkit.org/show_bug.cgi?id=203416). Since this patch makes Mac first paint behave like iOS first paint, I propose skipping this test on Mac as well for now and tracking fixing the test for both iOS and Mac in https://bugs.webkit.org/show_bug.cgi?id=203416.

[Ben Nham]

Also, according to the A/b bots, this is a 1.75% - 3% improvement on PLT5 for Mac.

[WebKit Commit Bot]

Comment on attachment 390704 [details]
Patch

Clearing flags on attachment: 390704

Committed r256577: <https://trac.webkit.org/changeset/256577>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.