On 25/10/2019 21:52, Eric Rescorla wrote:
On Fri, Oct 25, 2019 at 12:21 PM Botond Ballo <bba...@mozilla.com> wrote:
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.
I don't take that to be the primary objection.
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
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
