Meeting minutes
Summary of previous call
Qing: [reviews topics during last call]
… For issue #3, there was consensus to add the use case to the document. I prepared a pull request accordingly.
… For issue #4, directly related to DuckDuckGo, Dom took an action to reach out to them
Optional network interception capability (#9)
Issue #9 capabilities and scenarios
Qing: For issue #9 related to network interception, we said more description was needed around third party
wu_jiasheng: Examples include: if the app is used by a child, we can send the request to a security service that can check the content.
… [goes through scenarios added in #9]
Qing: The 6 scenarios make sense to me. Any comments?
JohnRiv: Question on 4. (Web caching) How would that be different from Service Workers?
wu_jiasheng: [answers question in Chinese]
Qing: Jiasheng wants to analyze the possibility of whether Service Workers can be a good fit for this use case.
… My understanding is that, previously, we had some analysis on Service Workers and maybe it's less about caching but about the speed of using Service Worker in native environment. The Service Worker can only be started after WebView is created, meaning that it creates some delay.
… That may potentially be a new use case. I talked with developers. They said that if WebView could provide some configuration methods of the web environment, that could bring some benefit. I'm still discussing real business scenarios behind that.
… I may turn that into a use case later on.
Rayan: Similar to issue #3 related to preloading. Service Workers are a good fit in theory, but WebViews have poor native support in practice. Stengthening web platform support would be a good issue to focus on in the short term.
… Giving applications the ability to modify third party content is problematic from a privacy and security perspective, at least without some form of authorization from the third-party.
duga: For caching, you may actually want to download using the native platform. E.g. download an epub without running an app, using the regular sync process. In terms of caching, Service Workers wouldn't work there.
… In the EPUB world, the manifest lists resources that composes the ebook. Access to external resources needs to be intercepted by the application and not rendered in the WebView.
zheng: Advantage for publishing is that we know the boundaries. In the generic case, we don't know the boundaries. I wonder how we can improve that. Wondering about the active caching in the fourth item here.
… I can precache everything when I know the boundaries.
… On the other hand, I wonder what is meant by "active" caching here.
Qing: I think it means something different from caching the ebook resources. In the case of ebooks, it's probably a one-time action. You download things once and then render locally. For the active caching, one example is eCommerce app where users will browser many pages.
… Pages will want to improve the loading speed, e.g. by guessing what users will load next, and will pre-cache serveral pages accordingly.
… About the comment on the children's filter, do you mean that a WebView is not allowed to render some content?
Rayan: As far as I know, that is the case.
Qing: If native apps provide content to children in WebView, how can the WebView know which content cannot be presented?
Rayan: I believe apps for children are not allowed to use WebViews at all.
… I see the business needs. I don't know if the privacy and security risks are worth the cost.
Qing: I agree. For children's filter, it is policy setting, hard to solve. The other scenarios make sense.
Qing: I'm ok to add network interception in our usage doc. Any other opinion?
… Hearing no objection, I think we can view this as a valid use case.
Enrich OS level UI (#11)
Thomas: Used by Apple. They use it mostly when anything iCloud is involved.
… Probably it facilitates the code for them (same code on desktops and tablets).
… For my quick tests, it seems to be sharing code indeed.
Thomas: I'm merely documenting the use case, not necessarily advocating for it.
Qing: Don't know if anyone has reached out to Apple to join the CG.
… First time I noticed that Apple Music uses WebViews. I'm not sure how to handle this one.
Thomas: There's probably other windows who use the same pattern.
Rayan: Related to having better debugability tools? I don't think anyone would argue about that.
Thomas: I think that's one aspect. On top of that, Apple uses functionalities that are not web-exposed, e.g. colors, features that would not run in a proper web context.
… I'm not sure to what extent this is something we need to generalize.
Qing: I suggest to leave the issue open if we're not sure about it.
Sharing HTTP requests/responses between native and WebView (#12)
JohnRiv: Work on a WebView that is part of a native application, and both often make the exact same HTTP exchanges. We either need to duplicate the calls or somehow have the native part handle the network exchanges and pass the response to the WebView.
… We'd like a mechanism to share the network stack.
Qing: Is it a one-time share or put into the cache?
JohnRiv: I would expect it would respect HTTP cache rules. If the response says "ok to cache during 5mn", then it would be cached for 5 minutes.
… Similar to the EPUB scenario that Brady mentioned earlier during this call.
duga: When we have the ability to intercept network requests, for example on Android, that's how we do it. What we do on Android is that everything goes through native. We're not really sharing but limiting that to one.
Zheng: On Android, we can even support custom schemes. I wonder whether there are additional use cases that need to be covered.
JohnRiv: If there are references to do this already on Android, I'd be curious to see those. Android developers always get back to me claiming that sharing is a terrible idea.
… We share HTTP requests/responses. But we also need to do it for WebSocket connections. It would be nice to say that whether native of the WebView makes the request does not change anything, and that response can be shared equally.
duga: It feels like this and the other issue are proposing solutions to the same use case: how do I share data between native and WebView. I don't know what is the right solution. Different ways to share the data. One benefit with the Android approach is that network requests can be disabled from WebView and still served from native.
… They feel like the same use case to me.
Qing: I agree with Brady.
… In this group, we're not discussing the actual solution. I think that we can agree that data sharing is an important scenario.
… Maybe we can analyze the pros and cons of different approaches later on.
Third party cookies and cross origin resource sharing in WebViews (#15)
niklas: I used to work using Cordova/Capacitor in the past.
… Local content could usually be loaded from the file: protocol but things have gone more restricted with regards to cross-origin policies.
… If the WebView provided APIs to make stuff working, meaning local files that can communicate with the backend using HTTP requests.
… Closely related to the origin issue, and also cookie communication.
Qing: Wondering how EPUB address this
Zheng: Essentially we don't use cookies.
Qing: Any similar origin issue with local content?
Zheng: For Android, we use the interception mechanism.
… For iOS, there's another customization mechanism.
… If there were a standard way, that would make things more consistent.
Qing: The bigger issue for me is that we haven't clarified the origin issue for the WebView. Maybe we need to spend some time on this.
… I encourage everyone to put comments on issue #7 so that we can try to figure out how to address the concept of origin in WebViews.
… We could then address these related use cases.
Additional use cases to discuss?
duga: I have a couple of them that I will write down and make available for next meeting.
Publishing apps using web technologies (#6)
Ashley: Similar to Cordova. WebView wrapped in a native shim. That's the main way we publish mobile apps. The main problem is web compatibility with that approach.
… It seems weird that interoperability is a main focus on regular web browsers, but not in webviews. I'd like the same level of compatibility in WebViews and in browsers.
Qing: The use case is broad and could perhaps be divided into sub use cases.
… There may be functionalites that are not supported because they are not needed or hard to enable in WebViews. I suggest that we analyze the different use cases one by one.
… Maybe we should further work on this and try to derive the specific multiple use cases from it.
Ashley: Something I don't really understand: if there's something that works differently in Chrome and Safari, it's just understood that things need to converge. When it comes to WebViews, it comes to understanding use cases. That feels strange, the same quest for compatibility should prevail.
Rayan: There are other types of web views where you have more support for technologies but less freedom to exchange between native and web. Is there a middle ground that could be better? Perhaps, that could be a use case that we look into.