This conflicts with adding them to HTMLElement for custom layout.
I grepped the codebase and couldn't find any uses of these. The
big thing we lose here is a way to set width/height on an image
that automatically maintains aspect ratio, but that's something
we should move into a custom layout method anyways.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/1060443002
After this CL, you can use <sky-element> to describe custom elements. The
current iteration is very basic and is hardcoded to "example", but its a start.
This CL renames the |init| function to |_init| to prevent importers from
calling it directly. Also, we now pass the <script> element to |_init| to give
some context.
R=ojan@chromium.org, eseidel@chromium.org
Review URL: https://codereview.chromium.org/950493003
This CL implements custom elements. The design is as follows:
1) Authors subclass Element and call registerElement.
2) When we create C++ elements for custom elements, we call the author's
constructor synchronously.
3) The attach/detach/attributeChanged callbacks are called either:
a) when exiting the current custom element callback scoped (e.g., before
returning from appendChild), or
b) when draining the microtask queue.
The implementation in this CL is a bit fragile because we don't detect name
registration conflicts and we let you create custom elements with the same name
as built-in elements. Also, not every part of the engine is prepared to execute
script synchronously below createElement. We'll need to iron out these issues
over time, but this CL is a start.
R=ojan@chromium.org
Review URL: https://codereview.chromium.org/943013002
This CL is progress towards deleting the concept of an HTMLElement entirely. We
won't actually get all the way there in this CL series, but we're getting
closer. This CL also will let us make custom elements just be Elements instead
of HTMLElements.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/942933003
This does several things:
1. Teaches sky about asynchronous script execution. Previously once all imports
were loaded and the script text was available, we executed a script and assumed
it completed synchronously. We left the parser loop to do so, but that was fine
as the next chunk from the background thread would resume the parser. In this
change scripts now load and execute separately. The "load" step may trigger
further dart import loads which may cause the execution to happen asynchronously
which required teaching both the DartController and the HTMLScriptRunner to
take callbacks to allow HTMLDocumentParser to know to continue parsing after
the Dart script has resolved its imports and executed.
This required re-working some of how the parser executes scripts and I
re-purposed isWaitingForScripts to include "is the parser blocked" where
as before it was limited only to "does the treebuilder have a script", even
though the imports system may have had pending scripts as well.
I made HTMLScriptRunner live only as long as the script it was executing
since it only contained per-script state at this point.
2. Fixed an error reporting bug whereby we would not show errors when "init"
failed to execute, only "main". This required using the dart_mirrors_api.h
which required adding an include path to the core build. :(
3. Made it possible for a single sky file to contain multiple dart <script>
tags. Each <script> is a separate library and executes as
soon as </script> is seen. main or init is called for each. This required
mangling "urls" for these script blocks since Dart unique's libraries by urls.
Before this change it may have been possible to do <import 'foo.sky'> and then
<script>import 'foo.sky'</script> and have it work!?
R=abarth@chromium.org
BUG=
Review URL: https://codereview.chromium.org/938623005
We shouldn't need pendingScripts in ScriptRunner since
we should never be trying to run scripts when we're
not ready to run them.
However this wasn't completely true in the case of imports
there was code to have us break before any start tag after
an <import> was seen, but it was subtly wrong in that it
it would include the start-tag it was trying to break before
in the chunk it sent to the main thread.
This didn't run out to be the problem I was facing, but I fixed
it anyway. The problem which was actually preventing me from
removing pendingScripts was adding a check inside
didRecieveParsedChunk... to check if imports were pending and
add the chunk to the list of pending chunks.
I also renamed m_speculations to m_pendingChunks since these
chunks are never speculative anymore.
We can't test the off-by-one import-breaking code with our
current system, but it would be trivial to test with a
self-closing custom element if/when we ever add custom
elements back to the system.
R=abarth@chromium.org
BUG=
Review URL: https://codereview.chromium.org/934083002
Because we dump dart errors to LOG(ERROR) (stderr) instead
of console.log / stdout, tests with dart errors just "pass"
and we don't notice they're not running.
This was the case with canvas-rounded-corners.sky.
I don't think this test actually passes yet, despite it
claiming to, but I at least have made it run and not crash.
Required me commenting out a ton of CanvasRenderingContext2D, but
that's fine, it wasn't actually working and it's better to have
it be compiling valid dart.
R=abarth@chromium.org, ojan@chromium.org
BUG=
Review URL: https://codereview.chromium.org/936563002
This CL causes sky/shell to create a blink::WebView to show that sky/shell
links with sky/engine. In the process, I've made it easier to be a trivial
embedder of sky/engine by removing the requirement to implement
blink::ServiceProvider.
This CL also causes sky/shell to link with mojo/edk/system to resolve link
errors with Mojo fabric (e.g., MojoClose, MojoWriteMessage, etc). To make this
work properly, we'll need to initialize the EDK in a future CL.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/873923003
Normal trace events already go directly to base. This CL removes the remaining
trace events that were still indirected through blink::Platform. These were
just the half-finished inspector timeline trace events, which currently aren't
actually hooked up to anything.
This CL also removes the redunant "convertable to trace format" wrappers and
moves their one remaining use over to just using the version in base directly.
R=eseidel@google.com, ojan@chromium.org
Review URL: https://codereview.chromium.org/889823002
HTMLIFrameElement was adding the observer in navigateView. If the same
HTMLIFrameElement navigated multiple times HTMLIFrameElement would
attach itself as an observer more than once. ObserverList doesn't like
this.
Also adds src as an attribute of HTMLIFrameElement so that I can do:
iframe.src = xxx
in script
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/885783002
This was to support doing background: -webkit-canvas(#id) where you could then
get the canvas with document.getCSSCanvasContext(id) and draw into it which
is a poor form of custom drawing for elements. In Sky we'll have real custom
painting instead of just background images hacked in like this.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/876913002
We now only preserve the whitespace inside a <t> element inside
the parser. This removes the known n^2 from reattaching whitespace
which should make parsing and appending nodes faster. I also
removed the dead WhitespaceMode code from the parser, and made
the dom-seralizer.sky auto indent the markup so the test output
would be readable.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/867963006
This removes the symmetrical nature of ServiceProvider and consistently
passes and uses a ServiceProvider + ServiceProvider& pair in places that
wish to bidirectionally expose services, such as the view manager.
The
view manager library now deals with InterfaceRequest<ServiceProvider>
and ServiceProviderPtr objects (i.e. c++ wrappers for handles) instead
of a concrete implementation of ServiceProvider to make it easier for
callers.
A number of places that were assuming a particular
ServiceProvider would always exist are updated to reflect the nullability
of the parameters in mojom and places that do not wish to ever look up
or provide services now pass nullptr instead of doomed pipe handles.
The JS application startup classes are reworked a bit to accomodate
exposing services on the third ConnectToApplication/AcceptConnection
parameter.
BUG=449432
R=abarth@chromium.org, sky@chromium.org
Review URL: https://codereview.chromium.org/858103002
After this CL, you can exchange services with the app loaded in the iframe by
calling takeServiceProvider() on the iframe element. That gives you the raw
handle, which you'll need to wrap in the appropriate mojom-generated interface.
R=hansmuller@google.com, sky@chromium.org
Review URL: https://codereview.chromium.org/862943004
This CL prepares us to expose the imported and exported service providers to
JavaScript. We can't quite do that yet becaues the API on mojo::View isn't
ready for us. However, we can get started by moving the call to Embed into
HTMLIFrameElement.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/793393003
Instead just use textContent() and teach HTMLStyleElement how to atomize
its children. I also added the optimization to Node::textContent so that
Text just returns its value instead of allocating a new buffer which
avoids malloc and copy when getting the textContent of text.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/864613002
This removes the attributes sky doesn't intend to support. It
removes references to the attrs, but leaves behind a lot of
plumbing that will be cleaned up in the future. This at least
removes the API surface.
R=ojan@chromium.org
Review URL: https://codereview.chromium.org/855803002
There's no reason to keep two identical lists of the sheets
and have this separate object. I also moved the updating
logic out of StyleResolver and into ScopedStyleResolver
which makes more sense. There's still some weirdness since
some global state still exists in the StyleResolver, but
that's something we can fix in future patches.
R=ojan@chromium.org
Review URL: https://codereview.chromium.org/852703002
Unlike blink in sky we just want to mark tree scopes dirty. We can
remove these methods, the dirty tree scope tracking we'll add in
the future will take care of this.
R=ojan@chromium.org
Review URL: https://codereview.chromium.org/836893003
