On Thu, Oct 8, 2015 at 6:10 PM, Mounir Lamouri <mou...@lamouri.fr> wrote:
> Note that Chrome 46 has a way to work around the white screen while a > page load using a new property in the Manifest. If a website added to > the homescreen on Chrome Android has a background_color information, it > will be used while the page loads. After Chrome gets the first paint > following a non-empty layout, it will remove that plain colour and > switch to whatever the page has ready. It allows websites to be > constructed as websites and not rely on that splashscreen feature that > might or might not be present (given the UA and the current context) and > also keep the principle of quick first paint. > > Would using a similar system (ie. background_color from the Manifest) > help you here? > I will be happy to use the background_color field in the manifest. It will likely help web app pinned to the homescreen. I also think it will be a great idea to use it to replace the static black color that is displayed before applications are launched and try to unify the experience between installed apps and pinned apps. However while I think background_color is useful, the white flash we are trying to address here is between the splash screen and the app content beeing loaded. I think, but I may be wrong, that we don't want to have a 3 steps startup with: 1. Black splashscreen with icon 2. plain background_color instead of a white flash 3. App content beeing displayed when ready. I guess 1. and 2. can be merged. Now the issue, if my understanding is correct, Gecko does not have the notion of firstpaint after a non-empty layout. Which means even if 1. and 2. are merged we can end up in a situation where you have: 1./2. background_color with/without icon 3. white flash 4. App content beeing displayed when ready. So basically what I want to add in bug 1211853 (first attachement) is (a very simple) mechanism to not paint until there is something to paint. And from here provide a mechanism for web app to control when first paint happens without enforcing them to be built a specific way. As James mentioned, background_color may also be tricky to used for applications with dynamic first page. For instance if you want to have a setup page with a different background color than the rest of your application. That said I still believe it can be useful for the vast majority of apps. An other constraints for application with multi-steps startup is to display something as quick as possible to the user and continue their execution after first paint. As of today there is no way (at least in Gecko, dunno for Chrome) to know when the UA has painted something on the screen. I would like to introduce a (moz)firstpaint event so app authors can optimize their app to quicly show something on the screen, then wait for the UA to paint, and then continue their execution. Vivien. > > -- Mounir > > On Wed, 7 Oct 2015, at 14:17, vnico...@mozilla.com wrote: > > I also forgot to say that the proposed solution does not help for cases > > like bug 1199674 afaict. > > _______________________________________________ > > dev-platform mailing list > > dev-platform@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
