Bug 215479

When the site is added to home screen, the startup image URL is parsed from <link> tags on the page. For SPA, the startup image would typically have the same background color as the page when it loads.

When you open the site from the home screen, especially the first time that day, the UI goes through the following screens:

- Site icon stretches to fullscreen
- Startup image fades in
- Screen goes full white (#fff) for between a few frames and more than three seconds (when using older devices and opening larger SPAs)
- Content appears on the screen

This behavior is seen regardless of service worker returning cached responses (avoiding the network loading delay), and regardless of the Dark Mode / Light Mode enabled in iOS.

The flash of white, when the startup image and the site content is both dark is very distracting to the user. More so, knowing that this is not something native apps normally do. Even if the splash screen image is brightly colored, this behavior is seen in Dark Mode on iOS, and the SPA that opens may support the CSS dark mode and hence display the site consistent with OS theme, still causing the "flash" effect.

Repeat-loading the site from home screen typically results in the shorter "flash" or in no "flash" occurring at all, especially in modern devices.

This "flash" is caused by the default backgroundColor of WKWebView, which is white.

I see three possible solutions:

1. New <link> or likely <meta> tag to set the background color for sites added to home screen
2. Make the default background color in home screen sites consistent with iOS Dark Mode / Light Mode AND interpret the prefers-color-scheme CSS media query when selecting the startup image from <link> tags, effectively saving two images (if supplied by the dev) and then using the right one for the theme.
3. Implement a cross-fade, by first setting opaque = No and backgroundColor = transparent on the WKWebView, and then removing these once the first contentful paint occurs in the WebView.

Obviously, the 3rd option provides the best user experience, as the user never sees the "placeholder" color. In addition, sites that use a gradient for their background will appreciate this solution.
The second-best solution is the first one, as it would truly allow web developers to control what the user sees after they tap on the site icon on their home screen. This is also likely the easiest to implement.
Finally, the second option generally works, but there will be edge cases when the site does not support Dark Mode, or if the site allows the user to select Dark Mode independent of the OS setting. Hence this option is least preferred.

We've implemented the 3rd option when developing an app that used WKWebView to display content, and it worked reliably since iOS 12.