Created attachment 390306 [details]
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).
Created attachment 390315 [details]
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).
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).
Might want to check if those test failures are real.
*** Bug 204828 has been marked as a duplicate of this bug. ***
Created attachment 390704 [details]
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.
Also, according to the A/b bots, this is a 1.75% - 3% improvement on PLT5 for Mac.
Comment on attachment 390704 [details]
Clearing flags on attachment: 390704
Committed r256577: <https://trac.webkit.org/changeset/256577>
All reviewed patches have been landed. Closing bug.