Richer splash screen backgrounds

[shwetank]

I'm not sure if this has already been considered or not. In case it hasn't, here goes

Right now the splash screen consists of an image and a background. That background is a plain background with a single color.

I would propose having an option to define an SVG file to serve as the background of the splash screen, essentially replacing the need for the background color for the splash screen (and maybe even the icons for the purpose of the splash screen). I think this could open up possibilities for much richer splash screens (including things like gradients, animations).

[kenchris]

We have discussed other options do splash screens before, but there are a few requirements.

• Cannot be rendered by the browser because it needs to show when the browser is loading
• It needs to be able to load instantly (maybe a svg viewer can do that, but that needs research on all platforms)
• Browser vendors need to commit to implementing this

I would suggest doing some research and talk to @owencm @PaulKinlan @RobDolin and Patrick Kettner. Marcos, Who to talk to on Moz side now?

Also please write down use-cases to make sure this covers the ones web developers are requesting.

[marcoscaceres]

Closing, as we,ve shown in the past that if you can load the browser engine fast enough, you don't need this.

[mgiuca]

I'd like to leave this open and can assign me if you like.

At Google we are constantly talking about richer splash screens because we clearly can do better than a tiny icon and text on a white background. We're now focusing our efforts on this.

The avenue we are pursuing is to have a full HTML page for the splash screen, but the UA takes a screen grab of the page at install time (or perhaps first load). So subsequent loads can show the screengrab very quickly as the browser engine is still loading. Obviously there are a lot of issues with this (updates to the splash page, changing screen orientation or size, transitioning into the start page, etc) but we think this is workable and plan to experiment with it in Chrome.

We'd rather not have to spin up an SVG renderer alongside the HTML renderer. Performance reasons, plus it would be a barrier to entry for devs to have to supply separate SVG along with their HTML page.

[shwetank]

We'd rather not have to spin up an SVG renderer alongside the HTML renderer.

@mgiuca Oh, didn't think of that. Makes sense in that respect. The reason I mentioned SVG is because of good scaling while still providing for richness in graphics and animation, contained in one .svg file.

plus it would be a barrier to entry for devs to have to supply separate SVG along with their HTML page.

Perhaps it won't be if its made optional. Default could be current way, and if someone wants more richness in the splash screen, then they could opt for this way.

full HTML page for the splash screen

What if a person had embedded or inline svg in that html page? SVG renderer might then be needed anyway in that case?

The avenue we are pursuing is to have a full HTML page for the splash screen, but the UA takes a screen grab of the page at install time (or perhaps first load).

I think first load would make more sense than install time. A user could be at any page during install time. Wouldn't be good to capture that. First load might be better there.

Also, by screen grab, are you talking something like a DOM snapshot of the page? Or an actual snapshot like a png? I'm assuming the former.

👍 to thinking more about this area. There is some room for improvement here.

[marcoscaceres]

See also #9, #361, #372, #373, and #390.

In particular, #9 has a lengthy discussion on the subject. I personally don't mind further exploration in this space - but be forewarned that we've had limited success in the past.

[marcoscaceres]

Forgot #510 also.

[marcoscaceres]

And related PR: #530 ... can't remember if that's any good or not anymore.

[piotrswigon]

Hi all, improving splash screen is one of the things I’ve been looking into. The direction we’re pursuing in Chromium is HTML splash screen screenshotted by the browser, which was discussed widely in #9. @mgiuca is on board and willing to make the necessary spec changes.

Proposed spec change

Add an optional manifest attribute splash_screen_url. UA may show this page while Web App is loading. A static image (screenshot) of splash screen page may be cached by UA for performance.

Advantages:

• A lot of flexibility for design (see wall of splash screens from Manifest format should support some way of including a splash screen #9), all icons, backgrounds and fonts are supported.
• Allows reusing the same graphics for all types of splash screens. Eliminates the problem illustrated by Twitter PWA displaing 2 different splash screens on Chrome - one native, one web-based (diagram).
• Pixel-perfect transition between splash screen and web content allows animating the splash screen away in web content (mentioned as potential requirement in this comment on #9).
• Uses technologies familiar to web developers.
• Simple declaration in manifest.
• UA flexibility of how it’s treated (e.g. always displayed by renderer, screenshotted ahead of time, or cached on first launch).

Disadvantages

• All implementations screenshotting the splash_screen_url to static image cannot show developer-controlled animations, e.g. progress bars and spinners.

Open Questions:

• What should be the mechanism for refreshing cached splash screen image once it’s updated by developer? Could be a JS API, UA checking for updated to manifest file or splash screen file.

Viable implementation

In Chromium for Android we found that screenshotting the splash screen page off-screen at A2HS time is difficult for various graphics related reasons. We therefore plan to navigate to it on first launch to grab the image. In the meantime we would fill the screen with background_color. On following launches image of the splash_screen_url would be shown. The splash screen for portrait and landscape would be snapshotted on the first launch in given orientation.

Some problems with such implementation:

• Resizeable windows can cause multiple images to be generated. On desktop environments web rendering engine starts fast enough to make splash screens redundant, so it’s not effectively an issue. On some mobile platforms (e.g. Android) users can divide their screen between apps, we will either fall back to another mechanism or snapshot special versions for split screen.
• If the first Web App launch is offline and the splash screen page has not been put into service worker cache, UA needs to fall back to another mechanism, e.g. background_color or icon-based splash screen

Demo

See the recording of the UX provided by the early prototype in Chromium. This demo focuses on the smooth transition from the splash screen to web content with the animation rendered by the start_url page. Recorded Web App is based on the Material Design Launch Screen example and can be found here.

What is happening on the first launch:

1. UA fills the screen with background_color and navigates to splash_screen_url.
2. Once splash_screen_url has loaded, UA shows it to the user, snapshots it and stores the resulting image.
3. UA navigates to start_url.
4. Page served from start_url detects standalone mode and renders splash screen hiding animation on onload.

What is happening on the second launch:

1. UA uses stored image of the splash_screen_url while it starts.
2. Web content is shown on the first paint. Web page is designed to look the same as the stored splash screen image for smooth transition.
3. Once page loads, Web App runs the splash screen hiding animation.

Worth noting that the UX of the first launch is relatively smooth - filling the screen with background_color is not intrusive.

We discussed this between few folks in Chromium and feel that this approach provides good balance of benefits to issues and addresses existing pain points well.

Feedback would be greatly appreciated.

Some folks who discussed this problem in #9:
@kenchris
@anssiko
@marcoscaceres
@jakearchibald
@mounirlamouri
@slightlyoff

[marcoscaceres]

I quite like the fallbacks proposed, and I really like what I'm seeing in the video... and the overall simplicity of what's being proposed on the manifest side.

I have open questions (not really concerns, rn) about doing the offscreen rendering (portrait, landscape, etc), and having to have a particular feature-policy/security-model for these pages. I guess these are details that can be worked out.

Don't have many concerns about a refresh API - we'd just have to rate limit it, I guess, as to prevent denial of service attacks on low-memory devices by repeatedly loading offscreen documents (I guess you can already do this with iframes... so 🤷🏽‍♂️).

[kenchris]

@RobDolinMS

I would like to know how you intent to handle this on desktop, where the window size might differ - usually desktop apps remember their last sizes.

• the use resizes it while loading (we can block that)
• it gets a different size because it is loading on another screen than last time (monitor connected)
• It was resized during use (so at what point should the browser redo the screenshot, at every resize?)

I am not sure that "On desktop environments web rendering engine starts fast enough to make splash screens redundant" is always the case. I have seen multiple web apps load relatively slow on some Chromebooks and even Netflix on Windows (which is a hybrid app) can take some time to load.

I actually think that will become a bit worse for a while as companies are looking to bringing some of their existing native apps onto web, especially with Web Assembly. Maybe of these apps are hard to make load quickly (and might require big Web Assembly bundles - and you can already see how hard it has been to split up native libraries and code with Instant Android apps) and some PMs don't see the load time as that important, because these are apps that people will have to use anyway, for their work etc, but a splash screen would be nice :-)

[piotrswigon]

Thanks for feedback!

@marcoscaceres, re: Feature-policy/security-model for splash screen pages

I think we should add to the spec something along the lines of “UA may restrict set of APIs available while rendering the splash_screen_url page”. Unless you have specific ideas in mind, I would leave this to later consideration depending on what UAs will decide to do and what problems they might run into.

@kenchris, re: How static screenshots of splash screen pages interplay with windows of different size on desktop.

My claim was not that all webapps can load almost instantaneously, only that if good practices are followed (SW cache etc.), the time to first paint can be negligible. Let me know if you think this generalization is too broad, I don’t have experience with WebAssembly for example. The goal of this proposal is only to display a site-controlled image before the first paint, which happens very quickly on desktop and makes usefulness of this feature questionable there.

If however UA would like to show a splash_screen_url in a desktop environment, it can render it from SW cache very quickly (presumably just HTML + CSS + fonts). There is no need for screenshotting, and therefore no problem with resizeable windows. If UA does that, there is an open question of when to transition from splash_screen_url to the web content. It could happen on onload, but some developer controllable mechanism (#372) could be proposed. Event.waitUntil(...) comes to mind, but I would leave spec’ing this out to a party who is interested in implementing it - at this point in time we (Google) are not.

To sum up, I believe this proposal is compatible with further developments we could consider for desktop.

[kenchris]

Hi @piotrswigon Yes, I really like your proposal and I think we should proceed.

I do think the generalization is too broad but you are right that there are other solutions on desktop, I would just like these to be mentioned in the spec text, like as non-normative text. Ie discuss the use-cases and how these can be solved with the new APIs in conjunction with SW etc.

If you write spec text, I will be happy to review

[marcoscaceres]

I think we should add to the spec something along the lines of “UA may restrict set of APIs available while rendering the splash_screen_url page”.

If we don't define that in an interoperable manner, that's going to end badly.

I would leave this to later consideration depending on what UAs will decide to do and what problems they might run into.

No, this needs to be defined up front. Otherwise, it will be a nightmare. Thankfully we have the feature policy spec now.

[piotrswigon]

Thanks @kenchris, we will keep this in mind and include information on how this could be adapted to Desktop. Regarding interaction with SW I'm intending to do some experiments how we could leverage existing HTTP cache and SW cache to avoid introducing new mechanism for refreshing splash screen image. I will update this thread with a concrete proposal once I have it.

@marcoscaceres, would you like us to specify a list of features that UA should disable on splash screen pages? Everything on the Policy Controlled Features could be turned off without restricting intended functionality. We might even consider disabling JavaScript entirely. Opinions?

[marcoscaceres]

@piotrswigon, it might be worth while starting with the most restrictive policy possible and seeing how developers cope. All browsers that support manifest also support CSS Grid and Flexbox, so 99% of layouts should be achievable.

[mgiuca]

I agree, let's start with JavaScript disabled. That automatically resolves all discussion about which APIs are available. I think that should be sufficient, but if not, we can revisit.

[marcoscaceres]

Ok, is there some means specified somewhere for how we disable JS? Do we need to add it to the list of controlled features?

[kenchris]

Something like

https://html.spec.whatwg.org/multipage/origin.html#sandboxed-scripts-browsing-context-flag
https://html.spec.whatwg.org/multipage/webappapis.html#sandboxScriptBlocked
https://html.spec.whatwg.org/multipage/webappapis.html#concept-bc-script

It seems fine to say "Scripting is disabled in the browsing context at all time"

[piotrswigon]

After some discussions internally, we came to the conclusion that scripting should be allowed.

The argument is that many developers are using web frameworks with UI widgets/components. It will be easier for them, we think, to use the same machinery for the splash screen page. Especially if they aim for a pixel perfect transition from the splash screen into the web app proper under all layouts, ability to re-use the same layout elements is important.

Obviously everything could be done with just HTML+CSS, but disabling scripting will create unnecessary hurdles.

[marcoscaceres]

Yeah, that makes sense. Need to think about the security/privacy aspects. A bunch of things obviously will fail (e.g., trying to get geo or other permissions, if those haven't been granted... etc. so there are even timing issues involved).

It's also potentially going to be super hard for developers to debug if anything goes wrong... so we might need to think about that too.

Just my 2c.

[piotrswigon]

Sorry for no update on this for some time - I've been away on paternity leave.

In Chromium we found that Blink doesn't currently expose signals notifying of a right time to screenshot the page. If we cannot do that reliably, we're risking users on low end devices getting half-rendered splash screens. This is not acceptable, especially given users won't have an easy way to recover from this. Fixing this would be a significant effort.

@marcoscaceres, now that Firefox on Android supports PWAs and A2HS, do you have any plans for this feature? What you do will help us assess whether to invest in the 'splash_screen_url' approach or look together into a solution declaring a splash screen UI through dedicated manifest attributes.

[ewsizeit]

@piotrswigon, I see the problem. But, is this really an issue for the specification of the manifest?

I think the splash_url is a very elegant solution, and it would be a pity to drop it only because it's hard to implement.

The obstacle you see has a broader scope than the splash screen. It would affect any JS animations. Or any other changes to the page not initiated by the user, for example a refresh meta tag. A user on a low end device would be used to animations not working properly. It would be a good thing to improve this, but it's more a question of JS animations on low end devices.

A half-rendered stored splash screen image would be updated (repaired) on the next app load. Of course, only if the device is able to render it in time. If not, the user will see no difference compared to a non cached splash image.

As I understand it there is a race condition. The splash URL has to be loaded, any JS finished and rendering complete. When to do the snapshot? The logical place would be when the content loaded from site_url starts rendering. However there is no guarantee that the rendering of the splash_url is done. An ugly fix would be to add a heuristically determined wait (X CPU cycles). Since we're talking about a low end device - the user is accustomed to a sluggish response. Once there is support for JS animations, this workaround can be removed.

[tomayac]

I just left a comment on #530 documenting the current iOS 11.3 Beta 2 approach.

[marcoscaceres]

Closing as per #510