Re: Definition of browser vs. WebView

Thanks so much for kicking off this thread Ashley! (And sorry for making
you take the lead of this 😅)

I do suspect that the edge cases of experience around the UX will bring in
more complications like the kiosk mode. My understanding of CTs is also
that they are the same process and memory space of the regular browser
process being used. I wonder if the definition of a WebView is less about
Browser / WebView and more about WebView being a separate dimension? For
example, if I build a thin web browser using a popular WebView library
(thin meaning I add very little UX and the WebView is doing most of the
work), it doesn't seem like that library necessarily stops being a WebView?

On Wed, May 7, 2025 at 10:54 AM Ashley Gullen <ashley@scirra.com> wrote:

> This proposed specification definition of a webview doesn't rely on the UA
> string. I just meant it's a basis on which we could start to attempt to
> come up with webview statistics based on UA strings seen in the wild (a
> separate discussion at our last meeting where the question came up). Any
> statistics drawn from UA strings are always going to be imperfect, but it's
> all we have to go on for statistics purposes, so we will have to make do.
>
> Chrome in kiosk mode is an interesting case I hadn't thought of - under
> this definition it would count as a webview, and I don't think that's
> unreasonable, as again it's much like a Cordova app where the content you
> see is restricted. I suppose you could argue it's a third mode - just a
> special setting for a browser - but I'm not sure how useful it would be to
> go down that path, especially if we end up with a fourth, fifth mode etc.
> Personally I think an oversimplified definition is better than an
> overcomplicated one.
>
> In my view iframes are part of web content and so would never be
> categorized as a webview by themselves - perhaps the definition could be
> amended to clarify that though. Perhaps something like "if the app
> embedding web content allows entering a URL, then it is a browser". Really
> the intent is to describe the way the top level frame is embedded.
>
> Ashley
>
>
>
> On Tue, 6 May 2025 at 17:46, Mike Taylor <miketaylr@google.com> wrote:
>
>> On 5/6/25 8:54 AM, Ashley Gullen wrote:
>>
>> Hi all,
>>
>> At our last WebView CG meeting I volunteered to help work on the
>> definition of a browser vs. webview, which quickly led to my promotion to
>> lead on the topic, so... here we go!
>>
>> I've had a think and I want to come up with a simple definition that can
>> easily be used to determine whether something is a webview, without
>> referencing specific technologies (e.g. the Android Webview). I think this
>> might be a good definition:
>>
>>    - If the user can enter their own URL to navigate to, then it is a
>>    web browser.
>>    - If the user cannot enter their own URL to navigate to, then it is a
>>    webview.
>>
>> So based on this definition:
>>
>>    - Naturally the major browsers like Chrome, Safari and Firefox are
>>    web browsers, as you can enter your own URL to navigate to.
>>    - Web content embedded in apps, such as Cordova apps, count as a
>>    webview as there is no user interface to enter your own URL to navigate to.
>>    These use cases involve showing a fixed selection of web content determined
>>    by the app developer, and may well block navigating to the open web for
>>    security reasons.
>>    - If an app embeds a webview, but adds a user interface to allow
>>    users to enter their own URL to navigate to, then it qualifies as a web
>>    browser. I think someone mentioned the DuckDuckGo browser does this, and
>>    assuming it has a URL bar, then it is a browser under this definition
>>    - In-app browsers like Android Custom Tabs and SFSafariViewController
>>    qualify as webviews, since (as far as I can tell) the user cannot edit the
>>    URL in this mode to browse to a different website. Despite having many of
>>    the features of a web browser, it works like showing the same content in a
>>    dismissable webview (which AFAIK is in fact often what apps did prior to
>>    the introduction of in-app browsers), so I feel like this is still an
>>    appropriate categorisation. Where the in-app browser provides an option to
>>    open the viewed page in the actual browser app (e.g. 'Open in Chrome
>>    browser' on Android), under this definition it will switch the user from a
>>    webview to a browser, as in the browser they can then edit the URL.
>>
>> It should be easy to tell with this definition: basically if you can type
>> in a URL, it's a browser, otherwise it's a webview.
>>
>> This should then be a basis on which to categorise things like usage
>> stats for browsers vs. webviews. The user agent string does not reliably
>> tell you if there is an editable URL bar, but it gives us a basis from
>> which to categorise the different user agent strings that are observed in
>> the wild, such as DuckDuckGo Browser (browser) and Facebook in-app browser
>> (webview).
>>
>> Categorizing "webview or not" via UA string seems like it falls apart in
>> a scenario like "Chrome opened in kiosk mode", or any app using
>> `setUserAgentString()` (or similar).
>>
>> Another thought: if the goal here to for traffic usage, do you consider
>> traffic coming from iframes to be browser traffic, or webview traffic
>> (given that users can't enter a URL into iframes).
>>
>>
>> Any thoughts?
>>
>> Ashley
>>
>>