rayankans
commented
2 years ago Thanks for the detailed analysis!
Agreed that the gaps in Web Platform support for WebViews are hard to keep track of and often confusing. Consistency in the Web Platform across WebViews seems to be a recurring issue.
I'd like to add a bit more colour to the compatibility issue you brought up, that there seems to be two general categories web content embedders / webviews fall into:
- reduced web platform support + control over web content, like the Android WebView and Windows WebView2
- full web platform support + no control over web content, like installable PWAs, and Android Trusted Web Activities
Customizing/delegating permissions is also an interesting point, I wonder to what extent that can be done while keeping security & privacy in mind.
QingAn
dontcallmedom
muodov
Submitter(s)
Ashley Gullen, Scirra Ltd
Motivation
Web apps can be published to app stores such as the Apple App Store, Google Play and Microsoft Store. This often involves bundling all the resources for the web app along with a native app that displays it using a web view. There are also hybrid cases where apps mix and match native and web content, but here I am focused on the web content being the main content of the app.
In this use case I am also focusing on the webview only displaying content bundled with the app itself. It would not be used to browse to any third-party content. This is a very common model for webview-based apps, and significantly alters the considerations for security and trust: the web content can be thought of as part of the app, as opposed to untrusted remote content.
When publishing apps this way a common problem is API compatibility. This is discussed in more detail below under Analysis.
Stakeholders
Web app developers publishing with frameworks like Cordova and Capacitor rely on WebViews to essentially run the main content of the app.
A similar development style is also possible on desktop (using WKWebView on macOS and WebView2 on Windows). However I would not personally consider frameworks like Electron or NW.js as WebViews. They are more like modified builds of an entire browser (Chromium) and do not tend to exhibit the same problems faced by WebViews. I would define a WebView as something that displays web content in the context of a native app, allowing mixing both web and native content. That covers the Windows WebView2 but not Electron or NW.js.
Analysis
WebViews generally have less API compatibility compared to browsers. Here are some examples:
There are probably more examples I've missed. This presents a problem for web compatibility. Browsers may be thoroughly tested and advertise supported features, but often web content stops working correctly when moving to a WebView due to API deficiencies. It's sometimes possible to essentially polyfill them by communicating with the containing native app to fill in the gaps (as frameworks like Cordova do). However this can still break web compatibility if it's not 100% spec compliant, adds extra development complications, and is not always feasible (e.g. a native app likely can't polyfill
requestVideoFrameCallback).Apple's WKWebView actually works surprisingly well - for the APIs that are supported, they tend to just work in WKWebView too (e.g. Web Share API works in WKWebView). However several of the noted APIs that are problematic on Android are not yet supported in Safari, so this may yet become a problem.
It's also often desirable to customise WebViews to work more similarly to apps. For example if the containing app already has permission to access the file system without the user being notified, then the WebView should not have a permission prompt. (This WebView2 issue demonstrates that being a problem.) Common customisations are:
Related W3C deliverables and/or work items
I'm not sure what the solution is but perhaps the specification could mandate that features must work in WebViews too. Specifications for permissions and user gestures could have wording to cover alterations for WebView use cases. A new specification could be designed to handle app-to-webview communication.
How is the issue solved in the Browser, and what’s more is needed?
In browsers everything tends to just work. I think there is a much greater focus on web compatibility across browsers than WebViews, so sometimes details specific to WebViews are neglected. A good example is the Virtual Keyboard API. The specification appears to assume use in a browser where the full window is dedicated to the browser. Since this is not necessarily the case with WebViews (although it can be), the API is simply not supported there. It does not seem like the WebView case was seriously considered, or perhaps it was deliberately omitted - either way it's now a web compatibility problem. All the problems that API solves must now be handled differently in a WebView.
Perhaps the main solution is just technical work on WebViews though - ideally everything would work out of the box in a web compatible way, and provide APIs to customise behavior if the default is not suitable for a specific app.