Meeting minutes
Review and discuss use cases
Load a WebView page #3
QingAn: the browser provides prefetch, load and next as resource hints to optimize the load of associated resources
… but webviews don't support this
… allowing prefetching data in JSON and XML would be beneficial e.g. in an ecommerce site to preload product info
… this helps improve the UX
… this got support from Bytedance, with a suggestion of providing prefetch capabilities
… but this converged to providing in the Web Platform in general rather than for WebView specifically
… We should discuss whether this is a valid use case
duga: Brady Duga, at Google but not representing WebView, coming from the ePUB WG, representing digital publishing
… This is a very important use case for us - reading ebooks on Android and iOS happen mostly on WebView, but end users don't expect a load-the-web-page experience in that context
… we need very nice transitions when moving from one book page to the next
… this requries non amount of trivial work needed, e.g. to use CSS animations
… preloading pages performance is incredibly important for us
… so definitely a valid use case
Qing: similar need from the mini-app perspective
rayan: this is all for on-device data, not fetched - so more pre-rendering rather than pre-fetching?
brady: fonts may take a while to load from storage; we don't want to show the page in the wrong font
… some preloading, but pre-rendering is the most important for us
Qing: rough consensus that this is a valid use case; I'll keep the issue opened to gather more comments
… we should bring it to the document
Rayan: is there a need specific to native re prefetching? or would bringing this to the Web platform be the right approach?
Qing: summarizing what I understood from jiasheng - an ecommerce app cannot pre-load all pages, since the user can view any product
… with a traditional webview, when the user opens a new product page, the webview will fetch html and css which causes delay instead of using native to render the page
… if the webview could prefetch with the native app predicting the most likely-to-be-requested page based on the user's profile
… it could prefetch the said page beforehand, and if the user does request it, it would provide a very good performance
jiasheng: +1 - loading results from local cache is faster than from network
rayan: so the native side decides what pages to download and cache them in webviews
… this could still be done from the WebView?
… using Web Platform features
… it's better if we expose features in Web Platform when we can
qing: +1
Build opinionated web browsers #4
tomayac: there is a desire from companies like DuckDuckGo to push a particular approach to Web browsing
… e.g. DDG browser blocking trackers and removing cookie banners when possible
… to that end, they inject a number of user scripts, either custom built or imported
… right now this is exposed via developer tools
QingAn: is it common for browsers to use WebView to display pages?
Tomayac: BA share code between their native app & browser, with a user script removing the header / footer in their native app
… I noticed by accident when finding the same bug in both
… a core differentiation is that a browser can load any URL
QingAn: what would be needed to support this use case? either from the webview or native side?
tomayac: some users may not be happy with some of the opiniated scripts - that may a very advanced use case
… from the group perspective, maybe this is mostly about acknowledging that webviews *are* used to build browsers
… on iOS, using a webview is even the only approach
… the DDG browser chose to also take this approach on Mac, possibly as a way to re-use their iOS work
QingAn: who are the stakeholders for this use case who could join the discussion?
tomayac: I'm not sure who the right contacts at DDG would be
dom: I can reach out to them
Publishing apps using web technologies #6
QingAn: feels like a compilation of several use cases, with a request to support from APIs from the Web Platform
… as well as customizing permissions, and communications between WebView & Native
… I'll try to dig more into the latter
… there are private solutions in different platforms
Optional network interception capability in WebView
jiasheng: [presenting the use case]
… Android has shouldInterceptRequest to help with this, but no equivalent in WKWebView
… it would be great to see that capability expanded to other webviews
QingAn: should we accept this as a valid use case?
Rayan: are there any valid use case for intercepting 3rd-party network requests, ie domains not owned by the application?
QingAn: this issue describes first-party requests, but doesn't say whether this would also apply to 3rd party as well
jiasheng: there are scenarios where it would also be useful for 3rd parties e.g. to accelerate loading performance of 3rd party content
QingAn: please describe these in the github issue
brady: from a digital publishing perspective, there are times where we want to intercept 3rd party requests
… e.g. when loading a video
… for privacy and performance reason, they might be locally cached to avoid pinging the hosting Web site
rayan: intercepting 1st and 3rd parties network requests have very different constraints
… Service Workers can do the former in the Web Platform context
dom: interesting that this is available in one platform (android), but not another (ios) - we should look how broadly that feature is available across all webviews
… also interesting to see if we handle this as a single use case for 1st/3rd party resources, or if handling them separately will help explore the solution space
QingAn: let's keep discussing this issue
rayan: I think distinguishing 1st party/3rd party use case will likely help, but it's probably too early yet to split the use case
Qing: let's continue discussion on the remaining use cases on github & in our next call
Kick off the use cases and limitations report draft
Template document for use case
QingAn: will start populating this with use cases
TPAC 2022
QingAn: CGs are invited to organize meetings at TPAC 2022
… are you all planning to attend TPAC physically?
<duga> Attending
Rayan: we should probably survey the group to get a sense of who might be there
QingAn: any immediate preference on the day for our meeting?
dom: we should probably collect info on groups we wouldn't want to overlap with
QingAn: re timeslot, since Chinese participants aren't likely to travel, picking the early timeslot would be best
… I'll collect feedback from other CG participants via email
… Our next meeting will be 2 weeks from now, May 25 at 2 pm UTC