On Thu, Oct 24, 2019 at 12:30 PM Gijs Kruitbosch
<gijskruitbo...@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

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
dev-platform mailing list

Reply via email to