C++ standards proposal for a <web_view> embedding library

[Botond Ballo]

Hi everyone,

With the proposal for a standard 2D graphics library now on ice [1],
members of the C++ standards committee have been investigating
alternative ways of giving C++ programmers a standard way to write
graphical and interactive applications, in a way that leverages
existing standards and imposes a lower workload on the committee.

A recent proposal along these lines is for a standard embedding
facility called "web_view", inspired by existing embedding APIs like
Android's WebView:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1108r0.html

As we have some experience in the embedding space here at Mozilla, I
was wondering if anyone had feedback on this embedding library
proposal. This is an early-stage proposal, so high-level feedback on
the design and overall approach is likely to be welcome.

Thanks!
Botond

[1] https://botondballo.wordpress.com/2018/06/20/trip-report-c-standards-meeting-in-rapperswil-june-2018/

[Jeff Gilbert]

It feels like the committee is burnt out on trying to solve the
general library problem, but contemplating something massively complex
like this instead doesn't follow, and is an answer to the wrong
question.

Make it easier to integrate libraries and we wouldn't see kludge
proposals like this.

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

[Botond Ballo]

On Wed, Jul 18, 2018 at 3:32 PM, Jeff Gilbert <jgil...@mozilla.com> wrote:
> It feels like the committee is burnt out on trying to solve the
> general library problem, but contemplating something massively complex
> like this instead doesn't follow, and is an answer to the wrong
> question.
>
> Make it easier to integrate libraries and we wouldn't see kludge
> proposals like this.

Could you elaborate on the "complexity" and "kludge" aspects?

One of the main complaints about the 2D graphics proposal was that it
was trying to create a new spec in a space where there are existing
mature specs, and that the committee as a group doesn't necessarily
have the depth of domain expertise in graphics necessary to specify a
library like this. This web_view proposal attempts to address that
concern by leveraging existing graphics and other specs from web
standards. So, in a sense, the committee is trying to avoid dealing
with complexity / reuse the work that others have done to tackle the
complexity inherent in the problem space.

If you're referring to the embedding mechanism / API itself being
complex, it would be useful to elaborate on why. The API surface in
the proposed library seems to be quite small.

It's also worth noting that there is prior art in this space in the
form of e.g. the QtWebView and wxWebView APIs, which I believe are
fairly popular in cross-platform C++ applications, suggesting a demand
for this sort of library.

Note that I'm not necessarily advocating for this proposal; I'm just
trying to understand the concerns / feedback better so that I can
communicate them to the proposal authors effectively. If you would
prefer to communicate the concerns to the authors directly, please
feel free to do so.

Thanks,
Botond

[Boris Zbarsky]

On 7/18/18 12:45 PM, Botond Ballo wrote:
> A recent proposal along these lines is for a standard embedding
> facility called "web_view", inspired by existing embedding APIs like
> Android's WebView:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1108r0.html

Botond,

Thank you for highlighting this proposal!

Am I correct in my reading that this would require the C++ standard
library to include an implementation of the web platform?

I have specific concerns about some of the standards linked to in the
"The provided web_view shall support content complying with" list, but
so far I'm just trying to understand the implications of this proposal.

-Boris

[Axel Hecht]

CCing snorp.

I guess it's interesting to see how the geckoview API differs from the
webview API, and which of those differences are related to goal of that
C++ API, and which are more browser-focused.

And if the C++ API should be also browser-focused, in the end.

Not making any statement on the interesting question of such a stdlib
thing, and how that impacts choice and innovation on the web space.
Which should be a more important question probably for mozilla.

Axel

Am 18.07.18 um 21:55 schrieb Botond Ballo:

[Botond Ballo]

On Wed, Jul 18, 2018 at 4:13 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
> Am I correct in my reading that this would require the C++ standard library
> to include an implementation of the web platform?

Either to include one, or to be able to find and use one provided by
the OS/platform.

Cheers,
Botond

[Nathan Froyd]

On Wed, Jul 18, 2018 at 4:54 PM, Botond Ballo <bba...@mozilla.com> wrote:
> On Wed, Jul 18, 2018 at 4:13 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

>> Am I correct in my reading that this would require the C++ standard library
>> to include an implementation of the web platform?
>

> Either to include one, or to be able to find and use one provided by
> the OS/platform.

Only if the implementation wanted to be fully compliant, correct?
People were still happy to use libstdc++ (say) as an implementation of
the C++ standard even when it didn't contain <regex>. Witness Boost's
extensive workarounds for C++ library implementations not quite
supporting something.

I can imagine that embedded implementations wouldn't include
<web_view>, their documentation would be clear about this, and their
users would be OK with this situation.

-Nathan

[Boris Zbarsky]

On 7/18/18 4:54 PM, Botond Ballo wrote:
> Either to include one, or to be able to find and use one provided by
> the OS/platform.

Ah, ok.

And in the latter case, to disable whatever network stack the
OS-provided thing has, if any, and substitute its own, right?

-Boris

[Boris Zbarsky]

On 7/18/18 4:59 PM, Nathan Froyd wrote:
> I can imagine that embedded implementations wouldn't include
> <web_view>, their documentation would be clear about this, and their
> users would be OK with this situation.

Oh, sure. I was talking specifically about stdlib implementation that
are aiming to comply with this proposal.

-Boris

[Botond Ballo]

I assume you're referring to the set_uri_scheme_handler() function in the API.

My reading of the proposal is that that's an extension mechanism for
the program to be able to override handling of standard URI schemes,
or invent new ones (such as for serving a page from a string in the
C++ program's memory), but if e.g. the program does not override the
"http" URI scheme, the OS-provided implementation's default handler
(including the network stack) would be used.

Cheers,
Botond

[Boris Zbarsky]

On 7/18/18 5:18 PM, Botond Ballo wrote:
> My reading of the proposal is that that's an extension mechanism for
> the program to be able to override handling of standard URI schemes,
> or invent new ones (such as for serving a page from a string in the
> C++ program's memory), but if e.g. the program does not override the
> "http" URI scheme, the OS-provided implementation's default handler
> (including the network stack) would be used.

I'm glad we're having this conversation, because that was not obvious to me.

If the intent is that the default behavior is to speak http, what are
the committee's thoughts on things like sandboxing, spectre mitigations,
process-per-origin, etc?

This last is particularly concerning in terms of API surface, because
interfacing with a multiprocess embedded browser might be quite
different from interfacing with a single-process one...

-Boris

[Botond Ballo]

On Wed, Jul 18, 2018 at 5:31 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
> If the intent is that the default behavior is to speak http, what are the
> committee's thoughts on things like sandboxing, spectre mitigations,
> process-per-origin, etc?
>
> This last is particularly concerning in terms of API surface, because
> interfacing with a multiprocess embedded browser might be quite different
> from interfacing with a single-process one...

As the proposal doesn't address this explicitly, I can only speculate
(no pun intended) as to the author's intentions, but I would assume
that the web platform implementation's usual policies would apply;
that is, if its policy is to spin up a new process for every origin,
then it will do so when used via web_view as well. (Of course, library
vendors may expose vendor- or platform-specific ways to tweak the
behaviour of the implementation (think "flipping prefs") if there's
demand for that.)

The proposal hasn't been presented to the committee yet, so I can't
speak to the committee's thoughts either, but I predict that there
would be opposition to a design that fundamentally lacks security
protections that would be present when using the web platform
implementation in a usual browser context.

Cheers,
Botond

[L. David Baron]

On Wednesday 2018-07-18 12:45 -0400, Botond Ballo wrote:
> With the proposal for a standard 2D graphics library now on ice [1],
> members of the C++ standards committee have been investigating
> alternative ways of giving C++ programmers a standard way to write
> graphical and interactive applications, in a way that leverages
> existing standards and imposes a lower workload on the committee.
>

> A recent proposal along these lines is for a standard embedding
> facility called "web_view", inspired by existing embedding APIs like
> Android's WebView:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1108r0.html
>

> As we have some experience in the embedding space here at Mozilla, I
> was wondering if anyone had feedback on this embedding library
> proposal. This is an early-stage proposal, so high-level feedback on
> the design and overall approach is likely to be welcome.

It feels like this bakes into the C++ language the idea that a
machine only ever needs a single implementation of the web platform.

I (and I think many others at Mozilla) think that users are better
served by competition among implementations of the Web's technology,
since it allows competition to better serve the interests of users
and allows more flexibility in the evolution of the platform due to
fewer mistakes getting quickly baked in to the platform by
compatibility.

This makes me think it's a bad idea to standardize a Web View API as
part of C++.

-David

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla https://www.mozilla.org/ 𝄂
Before I built a wall I'd ask to know
What I was walling in or walling out,
And to whom I was like to give offense.
- Robert Frost, Mending Wall (1914)

[Botond Ballo]

On Wed, Jul 18, 2018 at 8:04 PM, L. David Baron <dba...@dbaron.org> wrote:
> It feels like this bakes into the C++ language the idea that a
> machine only ever needs a single implementation of the web platform.
>
> I (and I think many others at Mozilla) think that users are better
> served by competition among implementations of the Web's technology,
> since it allows competition to better serve the interests of users
> and allows more flexibility in the evolution of the platform due to
> fewer mistakes getting quickly baked in to the platform by
> compatibility.
>
> This makes me think it's a bad idea to standardize a Web View API as
> part of C++.

Is having a Web View API fundamentally incompatible with there being
multiple implementations to select from?

Suppose the API had a mechanism to query a list of available
implementations, and you could specify which one to use when
instantiating a web view - would that address this concern?

Cheers,
Botond

[Bobby Holley]

In practice, I kind of doubt that standard libraries would actually include
multiple implementations of the web platform.

It also seems like it could break update cadence, since standard libraries
don't have nearly as rapid or streamlined and mechanism for pushing out
updates. It seems like they could ossify whatever arbitrary version got
shipped out in a major stdlib release.

I echo the sentiment that this doesn't feel like the right approach to the
problem, and that focusing on a package ecosystem makes more sense.

[Tom Ritter]

On Wed, Jul 18, 2018 at 9:21 PM, Bobby Holley <bobby...@gmail.com> wrote:

> In practice, I kind of doubt that standard libraries would actually include
> multiple implementations of the web platform.
>

It also seems like the implementation(s) that get included will essentially
be those those authors devote the resources to doing the development.
Meaning there isn't going to be an army of stdlib devs showing up and doing
the work to put Gecko into stdlib. At best someone from one of those
projects will email us and say "Hey, Google is putting Chrome into the
library, do you want to put Gecko?"

It also seems like it could break update cadence, since standard libraries
> don't have nearly as rapid or streamlined and mechanism for pushing out
> updates. It seems like they could ossify whatever arbitrary version got
> shipped out in a major stdlib release.
>

Which is a horrible, horrible idea for security. And web compatibility. And
new web features.

> I echo the sentiment that this doesn't feel like the right approach to the
> problem, and that focusing on a package ecosystem makes more sense.
>

Me too.

-tom

[Ted Mielczarek]

On Wed, Jul 18, 2018, at 12:45 PM, Botond Ballo wrote:
> Hi everyone,

>
> With the proposal for a standard 2D graphics library now on ice [1],
> members of the C++ standards committee have been investigating
> alternative ways of giving C++ programmers a standard way to write
> graphical and interactive applications, in a way that leverages
> existing standards and imposes a lower workload on the committee.
>
> A recent proposal along these lines is for a standard embedding
> facility called "web_view", inspired by existing embedding APIs like
> Android's WebView:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1108r0.html
>
> As we have some experience in the embedding space here at Mozilla, I
> was wondering if anyone had feedback on this embedding library
> proposal. This is an early-stage proposal, so high-level feedback on
> the design and overall approach is likely to be welcome.

I've joked about this a bit, but in seriousness: an API for web embedding is a difficult thing to get right. We don't even have one currently for desktop Firefox. The proposal references things like various WebKit bindings, but glosses over the fact that Apple revamped WebKit APIs as WebKit2 to better handle process separation. For all the buzz about WebKit being a popular web embedding, most people seem to have switched to embedding Chromium in some form these days, and even there the most popular projects are Chromium Embedded Framework and Electron, neither of which is actually maintained by Google and both of which have gone through significant API churn. That is all to say that I don't have confidence that the C++ standards committee (or maybe anyone, really) has the ability to spec a useful API for web embedding that can both encompass the broad set of issues involved and also remain useful over time as rendering engines evolve.

I understand the committee's point of view--the C++ standard library does not provide any facilities for writing applications that do more than console input and output. I would submit that this is OK, because UI programming in any form is a complicated topic and it's unlikely that the standard could include anything that would actually be useful to most people.

Honestly I think at this point growth of the C++ standard library is an anti-feature. The committee should figure out how to get modules specified (which I understand is a difficult thing, I'm not trying to minimize the work there) so that tooling can be built to provide a first-class module ecosystem for C++ like Rust and other languages have. The language should provide a better means for extensibility and code reuse so that the standard library doesn't have to solve everyone's problems.

I would make this same argument if someone were to propose a similar API for inclusion into the Rust standard library--it doesn't belong there, it belongs on crates.io.

-Ted

[Peter Saint-Andre]

Hear, hear and well said!

[Mike Hommey]

On Wed, Jul 18, 2018 at 12:45:30PM -0400, Botond Ballo wrote:
> Hi everyone,
>
> With the proposal for a standard 2D graphics library now on ice [1],
> members of the C++ standards committee have been investigating
> alternative ways of giving C++ programmers a standard way to write
> graphical and interactive applications, in a way that leverages
> existing standards and imposes a lower workload on the committee.
>
> A recent proposal along these lines is for a standard embedding
> facility called "web_view", inspired by existing embedding APIs like
> Android's WebView:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1108r0.html
>
> As we have some experience in the embedding space here at Mozilla, I
> was wondering if anyone had feedback on this embedding library
> proposal. This is an early-stage proposal, so high-level feedback on
> the design and overall approach is likely to be welcome.

Other than everything that has already been said in this thread,
something bugs me with this proposal: a web view is a very UI thing.
And I don't think there's any proposal to add more basic UI elements
to the standard library. So even if a web view is a desirable thing in
the long term (and I'm not saying it is!), there are way more things
that should come first.

Come to think of it, don't many UI libraries come with a web view
anyways? (or is Qt the only one that does?)

Mike

[Botond Ballo]

On Thu, Jul 19, 2018 at 5:35 PM, Mike Hommey <m...@glandium.org> wrote:
> Other than everything that has already been said in this thread,
> something bugs me with this proposal: a web view is a very UI thing.
> And I don't think there's any proposal to add more basic UI elements
> to the standard library.

Not that I'm aware of.

> So even if a web view is a desirable thing in
> the long term (and I'm not saying it is!), there are way more things
> that should come first.

I think the idea behind this proposal is that standardizing a UI
framework for C++ would be too difficult (seeing as we couldn't even
agree on a 2D graphics proposal, which is an ingredient in a UI
framework), so the web view fills the role of the UI framework: your
UI is built inside the web view. (Not saying that's a good idea or a
bad idea, just trying to explain the line of thinking.)

Cheers,
Botond

[Jim Blandy]

Reading between the lines, it seems like the committee's aim is to take
something that is widely understood and used, broadly capable, and in the
big picture relatively well-defined (i.e. the Web), and incorporate it into
the C++ standard by reference.

The problem is that the *relationship of web content to surrounding native
app code* is none of those things, and I think you could make a case that
it's been undergoing violent churn for years and years.

[Randell Jesup]

Ted wrote:
>Honestly I think at this point growth of the C++ standard library is an
>anti-feature. The committee should figure out how to get modules specified
>(which I understand is a difficult thing, I'm not trying to minimize the
>work there) so that tooling can be built to provide a first-class module
>ecosystem for C++ like Rust and other languages have. The language should
>provide a better means for extensibility and code reuse so that the
>standard library doesn't have to solve everyone's problems.

(and various others wrote things along the same lines, or similar
concerns)

I'm strongly in agreement. This is not going to help people in the long
run, and may well be as Ted puts it an anti-feature that causes all
sorts of problems we've chipped away at to re-rear their heads (ossified
unsafe impls, lack of any improvements, etc).

A good module system is a much more useful and liberating thing to do.

--
Randell Jesup, Mozilla Corp
remove "news" for personal email

[Myk Melez]

Botond Ballo wrote on 2018-07-18 09:45:
> As we have some experience in the embedding space here at Mozilla, I
> was wondering if anyone had feedback on this embedding library
> proposal. This is an early-stage proposal, so high-level feedback on
> the design and overall approach is likely to be welcome.

I'm afraid that I agree with the consensus in this thread: specifying a
web_view class isn't a useful activity for the C++ standards committee
to undertake.

The proposal notes that C++ specifies "no useful facilities" for
creating graphical interfaces, so "users either need to make use of
system-specific APIs, third-party libraries, or move to a different
programming language."

However, it doesn't explain why "system-specific APIs" and "third-party
libraries" are considered insufficient or harmful. As others have
pointed out, for languages with first-class modules and package
ecosystems, third-party libraries are a feature of a language, not a
bug. And "system-specific APIs" have their own advantages (along with
downsides).

The proposal also notes, "To be useful, we’ll need to require support
for a large number external standards (i.e., [X]HTML, CSS, SVG,
ECMAScript, and possibly others). Our three-year release cycle is likely
sufficient to maintain a proper list of such standards, but it’s still a
large list, and to be clear, the transitive closure of this list is huge."

At the very least, this statement is worthy of more careful
consideration, given the ongoing rapid change in the web platform
surface area (not to mention implementation strategies that affect
embedding APIs, such as the move to multiple content processes).

And it notes, "Surveying the current implementations has convinced me
that this kind of interface is appropriate for standardization, at least
in the sense that, while broadly useful, using these services from a C++
application today requires difficult-to-get-right platform-specific
code. Moving that burden to C++ library implementers, as a result, makes
sense."

The former statement may be true, but the latter doesn't necessarily
follow; and it isn't even clear that the former is true. The author
himself demonstrates a prototype implementation that supports multiple
platforms. And the Chromium Embedded Framework (CEF) has similarly long
provided a cross-platform API for embedding the web into C++ applications.

Don't such third-party libraries show that it *is* possible to use the
web in a C++ application without "difficult-to-get-right
platform-specific code"?

(It might be that developing such a cross-platform library is itself
challenging, but that's a burden on library vendors, not application
developers.)

Cross-platform graphical application development with C++ can be
challenging, and the web may be a solution in some cases. Indeed,
Mozilla itself has faced that challenge and used its own web
implementation to help solve it for desktop platforms. And others have
solved it via third-party libraries and system-specific APIs.

Nevertheless, while those implementations are imperfect, and there's
plenty of scope for improvement, a minimal standard that evolves more
slowly than the web and its implementations seems like it would do more
harm than good. And thus a web_view class isn't well-suited for
specification by the C++ standards committee.

-myk

[Eric Shepherd (Sheppy)]

Yeah, a standard web_vew library being part of the C++ standard is not a
good idea. It's far too huge a thing with far too many potential pitfalls
and dangerous consequences, and is an overweight solution to what should be
a comparatively lightweight problem.

If the goal is just to have a standard way to build basic GUI interfaces in
C++, then it might make more sense to do something like adopt Tk as a UI
language for C++. It's reasonably well-known, is both expansive and easy to
use, and is designed specifically for creating UIs for integration into
apps in other languages, with cross-platform compatibility baked in.

If the goal is a high-speed graphics solution of some sort, it seems like
adopting a standard such as OpenGL ES as the standard for baseline graphics
in C++ would be more logical. It's already a standard, it's well-documented
and well-known, and in most cases you can shunt off the majority of work to
a platform runtime.

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

--

Eric Shepherd
Senior Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/eshe...@mozilla.com>

[Botond Ballo]

Hi folks,

I wanted to give an update on the "web_view" C++ standard library proposal.

I have relayed the feedback received on this thread on multiple
occasions, and our concerns about this proposal as a browser
implementer have been noted by the committee. However, the proposal
has been received positively by other participants of the committee,
including other browser vendors, and is continuing to be developed and
reviewed. While it's still at an early stage (still in front of the
Library Evolution Incubator group), it is being actively developed and
the proposed API is becoming more fleshed out.

Given that, would anyone be interested in reviewing the proposed API
and providing feedback on its design? I feel like the committee would
be receptive to constructive technical feedback, and as a group with
experience in developing embedding APIs, we are in a particularly good
position to provide such feedback.

The latest draft of the proposal can be found here:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1108r4.html

Thanks!
Botond

On Wed, Jul 18, 2018 at 12:45 PM Botond Ballo <bba...@mozilla.com> wrote:
>
> Hi everyone,
>
> With the proposal for a standard 2D graphics library now on ice [1],
> members of the C++ standards committee have been investigating
> alternative ways of giving C++ programmers a standard way to write
> graphical and interactive applications, in a way that leverages
> existing standards and imposes a lower workload on the committee.
>
> A recent proposal along these lines is for a standard embedding
> facility called "web_view", inspired by existing embedding APIs like
> Android's WebView:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1108r0.html
>

> As we have some experience in the embedding space here at Mozilla, I
> was wondering if anyone had feedback on this embedding library
> proposal. This is an early-stage proposal, so high-level feedback on
> the design and overall approach is likely to be welcome.
>

[Jeff Gilbert]

We that's bleak. Get pumped for a surge in "Download our desktop app for
the full experience"!

Rather than spending our limited resources giving guiding technical
feedback to proposals we fundamentally oppose, I would rather see us
putting effort into satisfying the target user stories with a less
catastrophic proposal.

A bunch of senior engineering has chimed in here, but I would love to know
that this is being surfaced to upper leadership.

Thanks for keeping us all apprised, Botond.

[Henri Sivonen]

On Tue, Oct 22, 2019 at 11:55 PM Botond Ballo <bba...@mozilla.com> wrote:
> Given that, would anyone be interested in reviewing the proposed API
> and providing feedback on its design? I feel like the committee would
> be receptive to constructive technical feedback, and as a group with
> experience in developing embedding APIs, we are in a particularly good
> position to provide such feedback.
>
> The latest draft of the proposal can be found here:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1108r4.html

These comments are still more on the theme of this API being a bad
idea for the standard library on the high level as opposed to being
design comments on the specifics.

Section 4.2 refers to Gecko's XPCOM embedding API, which hasn't been
supported in quite a while. It also refers to the Trident embedding
API. Putting aside for the moment the it's bad from Mozilla
perspective to treat a Web engine as a generic platform capability as
opposed to it being a thing that one chooses from a number of
competitive options, it seems bad to build on the assumption that on
Windows the platform capability is Trident, which isn't getting new
Web features anymore.

Further on the Trident point, it doesn't really work to both say that
this is just exposing a platform capability and to go on to say that
implementations are encouraged to support [list of Web specs]. This
sort of thinking failed for the various Web on TV initiatives that got
whatever Presto and WebKit had. If the mechanism here is the Trident
embedding API on Windows, then you get whatever Trident has.

I'm curious how developers of libstdc++ and libc++ view the notion of
WebKitGTK+ as a platform capability. The C++ standard libraries are
arguably for Linux while the "platform capability" named (WebKitGTK+)
is arguably a Gnome thing rather than a Linux-level thing. That WPE
WebKit exists separately from WebKitGTK+ seems like a data point of
some kind: https://wpewebkit.org/

Section 4.4 argues against providing a localhost Web server
capability. I understand that the goal here is a user experience that
differs from the experience of launching a localhost HTTP server and
telling a Web browser to navigate to a localhost URL. However, the
additional arguments about the HTTP/2 and HTTP/3 landscape evolving
quickly and requiring TLS seem bad.

For localhost communication, HTTP/1.1 should address the kind of use
cases presented (other than the launch UX). Without actual network
latencies, HTTP/2 and HTTP/3 optimizations over HTTP/1.1 aren't _that_
relevant. Also, the point about TLS doesn't apply to HTTP/1.1 to
localhost. The notion that it's easier to create a multi-engine Web
engine embedding API that allows the embedder to feed the Web engine
pseudonetwork data is simpler than creating a localhost HTTP/1.1
server seems like a huge misestimation of the relative complexities.

Moreover, for either this API and a local HTTP server to work well, a
better way of dynamically generating HTML than is presented in the
example is required. It doesn't make sense to me to argue that
everything belongs in the standard library to the point of putting a
Web engine API there if a mechanism for generating the HTML to talk
with the Web engine doesn't belong in the standard library. If the
mechanism for generating the HTML is something you pull from GitHub
instead of something you get in the standard library, why can't
https://github.com/hfinkel/web_view be pulled from GitHub, too?

Finally, this seems very hand-wavy in terms of the security aspects of
loading remote content in a Web engine launched like this. My
understanding is that this has been an area of security problems for
Electron apps. It seems irresponsible not to cover this in detail, but
it also seems potentially impossible to do so, given the need to work
with whatever Web engine APIs that already exist as "platform
capabilities".

--
Henri Sivonen
hsiv...@mozilla.com

[mhoye]

------ Original Message ------
From: "Henri Sivonen" <hsiv...@mozilla.com>
>
>Section 4.2 refers to Gecko's XPCOM embedding API, which hasn't been
>supported in quite a while. It also refers to the Trident embedding
>API. Putting aside for the moment the it's bad from Mozilla
>perspective to treat a Web engine as a generic platform capability as
>opposed to it being a thing that one chooses from a number of
>competitive options, it seems bad to build on the assumption that on
>Windows the platform capability is Trident, which isn't getting new
>Web features anymore.

While I'm admittedly way, way out of my swim lane here, I'd like to
second one Henri's concerns; the specification as proposed doesn't admit
that Trident is effectively gone and that the Mozilla API referenced in
(1.) embedding is marked as "Obsolete" in places and otherwise full of
red flags:


https://developer.mozilla.org/en-US/docs/Mozilla/Gecko/Embedding_Mozilla/Roll_your_own_browser

... but I'm equally concerned that this specification repeatedly assumes
that a possibly-unbounded amount of poorly-defined work done by
unspecified other people will manifest itself somehow:

"To be useful, we’ll need to require support for a large number external
standards (i.e., [X]HTML, CSS, SVG, ECMAScript, and possibly others).
Our three-year release cycle is likely sufficient to maintain a proper
list of such standards, but it’s still a large list, and to be clear,

the transitive closure of this list is huge. Nevertheless..."

"Required security and functionality updates on many platforms for
web-content support may be far more frequent than updates to the C++
standard library, and a web_view in the C++ standard library should
automatically use this frequently-updated web-content software."

"I fully expect that, if we decide to go down this route, additional
utilities and abstractions will be added to go along with it."

"It should be noted that, as a limitation derived from current
implementations, the URI scheme handlers provide a kind of virtual
file-system interface, and as such, do not support POST data being
provided to the handler along with the URI itself. To support that, and
other protocols directly, we may need to provide an actual socket-based
server to which the web_view could connect."

"Implementations are encouraged to support the latest WHATWG living
standards, [wai-aria], [WebGL], [webrtc], [webvtt1], [SVG11], CSS
standards, DOM standards, and otherwise maximize compatibility with
other implementations (see, e.g., Can I use... )"

"It is expected that, for security reasons, implementations might
restrict or disable this interface for web content provided by some
remote sources."


In short, there is a _lot_ of "should", "might" and "may" in this
specification. I have to admit that on a re-read, the basic idea of a
standard API used to invoke an _existing external third-party browser_ -
that a C++ program might want to define some content and interactions
and maybe ask questions and get reasonably well-formed answers back - is
about 99% less incredibly bonkers than my initial impressions, and there
may well be something there worth pursuing, but as drafted this spec
presumes a lot of future work and glosses over a lot of serious
questions as a result.

- mhoye

[Gijs Kruitbosch]

Is there some visibility into the feedback by other participants (esp.
other browser vendors) and why they think this is a good idea? What are
the arguments *for* this thing, and have they engaged with our arguments
against at all?

As a desktop Firefox person, "embedding" Gecko and providing UI on top
is at some level what we do - with the added bonus that we can change
Gecko to suit us if necessary (a luxury embedders generally do not have).

From experience, people seriously underestimate how hard this is -
things like "I want a URL bar" or "I want tabs / multiple navigation
contexts and want them to interact correctly" or "users should be able
to download files and/or open them in helper apps cross-platform" are
considerably less trivial than most people seem to assume, and even as
Mozilla we have (perhaps embarrassingly) repeatedly made the same /
similar mistakes in these areas when creating new "embedders" from
scratch (Firefox for iOS, FirefoxOS, the various Android browsers), or
have had to go over all our existing separate gecko consumers to adjust
them to new web specs (most recent example I can think of is same site
cookies, for instance, which requires passing along origin-of-link
information for context menu or similar affordances), which is
non-trivial and of course cannot happen without embedding API
adjustments. That's before we've talked about the embedded code itself
changing requirements (e10s, fission, sandboxing improvements, ...).

When looking at the objections our senior engineers had already raised
earlier in this thread, I was struck by Ted's point about a module
system - avoiding specifying a module system because "it's hard" (which
I too don't disbelieve, fwiw), but instead trying to specify a web
embedding API looks to me like the inverse of "better the devil you
know" on the part of the C++ standard library folks - fundamentally, a
module system is a more constrained thing than "please provide a
complete API for interacting with the web".

Finally, I'll point out that in all this time, it seems (from searching
the web, that is) the standard library committee has not specified a
standard API for either sockets or HTTP(S) connections - a very very
tiny subset of "web view", instead leaving everyone to integrate
libcurl/neon/boost.asio/whatever as they see fit. It seems odd to go
straight from "nothing" to "web view", and not start with the building
blocks... Similar arguments could be made for xml/html parsing, JS
engine support, CSS parsing, layout, etc.

(apparently there is/was a networking/socket (but not http/https - or
even tls itself) proposal but afaict it hasn't been integrated in any of
the finished standards so far?)

~ Gijs

[Henri Sivonen]

On Thu, Oct 24, 2019 at 12:30 PM Gijs Kruitbosch
<gijskru...@gmail.com> wrote:
> From experience, people seriously underestimate how hard this is -
> things like "I want a URL bar" or "I want tabs / multiple navigation
> contexts and want them to interact correctly" or "users should be able
> to download files and/or open them in helper apps cross-platform" are
> considerably less trivial than most people seem to assume, and even as
> Mozilla we have (perhaps embarrassingly) repeatedly made the same /
> similar mistakes in these areas when creating new "embedders" from
> scratch (Firefox for iOS, FirefoxOS, the various Android browsers), or
> have had to go over all our existing separate gecko consumers to adjust
> them to new web specs (most recent example I can think of is same site
> cookies, for instance, which requires passing along origin-of-link
> information for context menu or similar affordances), which is
> non-trivial and of course cannot happen without embedding API
> adjustments.

The Mozilla cases are harder, because the applications we build around
Web engines are Web browsers. My understanding (which may be wrong!)
is that the purpose of the C++ proposal isn't to enable creating Web
browsers around the API but to use the API to render the GUI for a
local C++ app whose primary purpose isn't to browse the Web, so I
assume "I want a URL bar" is the opposite of what the proposal is
after.

But even so, the proposal is inadequate in addressing questions like
multiple windows and various issues related to loading content from
the network as opposed to content from the app's own URL scheme that
maps to a stream produced by the C++ app internals. And its inadequate
for even the app-internal URL scheme: It looks like the app-internal
URL scheme is expected to map a URL to a stream of bytes as opposed to
a Content-Type and a stream of bytes.

--
Henri Sivonen
hsiv...@mozilla.com

[Botond Ballo]

> My understanding (which may be wrong!)
> is that the purpose of the C++ proposal isn't to enable creating Web
> browsers around the API but to use the API to render the GUI for a
> local C++ app whose primary purpose isn't to browse the Web, so I
> assume "I want a URL bar" is the opposite of what the proposal is
> after.

Correct. The goal is to leverage the web platform to write C++
applications with graphical output and user interaction, not to write
browsers.

If we would find it reassuring if the proposal explicitly called out
writing browsers on top of this API as a non-goal, I can suggest that.

Cheers,
Botond

[Eric Rescorla]

I don't take that to be the primary objection.

-Ekr

[Gijs Kruitbosch]

Indeed not. I think the concerns that were surfaced originally probably
carry more weight than mine here anyway - mostly I was very surprised
that a year later, despite all the objections (which seemed very valid
to me), people are pressing ahead with this idea.

I'll attempt to re-summarize the bit of my post that led to the
discussion of web browsers vs. other embedders of web views:

First, as Ted said, web embedding APIs are not very stable things. They
can change as a result of:

- web spec changes (e.g. samesite cookies)
- embedded code changes (e.g. fission)
- embedding consumer expectation changes (e.g. which bits they do/don't
want to do themselves (networking, js engine, ...) or want more control
over)
- OS API/runtime changes or bugs (e.g. different types of sandboxing,
signing, packaging or permissions for features exposed through web specs)


Second, people underestimate the responsibility placed on the consumer
and/or embedding spec. Looking at the spec casually, I wonder:

- How should operations that open new windows be handled? Based on the
text "If the previous content caused additional windows to be opened,
those windows should be closed.", it seems they should be supported
somehow (?!) but it doesn't say how those are exposed to C++, and even
that disclaimer is unclear - e.g. are windows opened by the user
clicking links ones that were "caused" by the previous content, or no?
- is the expectation that http(s): links, when clicked by the user, are
opened inside the same webview? What about data:/blob:/file:/... links?
(It seems yes based on "It is expected that, for security reasons,

implementations might restrict or disable this interface for web content

provided by some remote sources." It seems irresponsible to do this
without UI indicating origin and security state, at least, but there's
no mention of this that I can see. It also seems irresponsible to
handwave what happens if the C++ tries to interact with arbitrary remote
web pages as implementation-defined.)
- if https: is handled inside, what about the CA database, HSTS lists,
intermediate caching/databases, and/or custom certs?
- where does the webview store site data (from indexeddb, cookies,
localstorage, ... )?
- what's the caching behaviour of the custom URI scheme? What's their
content type (as pointed out by Henri), and does it support other
headers or supplementary information (e.g. CSP)?
- what's the origin policy between different URIs of the custom URI
scheme(s)? What about link policy? (ie clicking links from `http:` pages
to `file:` URIs doesn't work; what about from `appfoo:` to `appbar:` or
even `appfoo:onething` to `appfoo:anotherthing` ?)
- do beforeunload events fire if loading another URI into the same
webview? How is the consumer notified if the page prevents navigation?
Is the consumer notified at all if things in the DOM itself navigate
(e.g. as a result of user clicks)? ?
- what kind of non-web UI is the webview responsible for? Presumably
window chrome, and maybe native dialogs like for alert/confirm/prompt?
What about full screen support, printing, and other UI-implicating
features that are web-exposed?
- is there some expectation of history (e.g. :visited link colouring)
and/or is that and other state shared between different webview
consumers (as the spec says "a web_view in the C++ standard library

should automatically use this frequently-updated web-content software."

implying it's being shared) or no? What about back/forward/history
navigation in the webview - it doesn't seem there's anything allowing
this to happen in the API, nor is there anything that allows the
embedder to notice this happening if the user does it (e.g. using mouse
swipes or custom buttons, even without a context menu or browser-like
UI) - but the docs say that having the embedder call display_from_uri()
should be treated as a navigation per the spec...
- the invoke API is fun - what happens to all the C++ references if the
function you invoke calls `window.close()` ?

To be clear, this is not intended as a concrete and complete list of
questions, whose answering in the spec will mean that then all is well
and good - just as an indication of the breadth of the task of
specifying sane behaviour here - behaviour and specs that will need to
evolve together with the web.

~ Gijs

[Botond Ballo]

On Wed, Oct 23, 2019 at 8:34 AM Henri Sivonen <hsiv...@mozilla.com> wrote:
> I'm curious how developers of libstdc++ and libc++ view the notion of
> WebKitGTK+ as a platform capability. The C++ standard libraries are
> arguably for Linux while the "platform capability" named (WebKitGTK+)
> is arguably a Gnome thing rather than a Linux-level thing.

I spoke to a libstdc++ maintainer at the recent C++ standards meeting
in Belfast, and he indicated to me that he would be fine with adding
an optional dependency on WebKitGTK+, as long as he didn't have to
bundle it part of libstdc++, but could link to the platform's copy (if
present) instead.

I spoke to a libc++ maintainer as well, who indicated that there may
be engineering challenges related to scenarios where applications end
up linking to both libstdc++ and libc++. However, this is an issue
that affects all external C++ dependencies, and will need to be solved
going forward regardless of what happens to web_view.

Cheers,
Botond