The bindings, core, and application libraries are now referred to as, e.g.:
package:mojo/public/dart/core.dart
Since the handle watcher remains in the snapshot, it no
longer refers to types defined in core.dart. References to types defined
in core.dart are also removed from mojo_natives.cc.
In Dart packaged apps, the SDK is zipped up under mojo/public/dart.
For embedder tests, the SDK is copied into the generated source output directory.
A base_dir parameter is added to the 'dart_package' and 'mojom' GN macros so that
consumers of the Mojo SDK can all import using the same URIs regardless of where
the SDK lives in their source trees.
BUG=
R=erg@chromium.org
Review URL: https://codereview.chromium.org/1027603002
Dart actually expects package: to work. This CL makes package:foo
map to /packages/foo, similar to how Dartium or bin/dart would expect.
This also means overlaying the /gen directory over the actual package
outputs (as consumers of an SDK would expect) as well as adding
an additional /lib indirection for the actual package source as
the Dart pub tool will expect.
This is far from perfect, but it unlocks us actually producing a
sky SDK.
I expect there may be some fallout from this change as I'm sure I
missed some package: uses. We also don't have a general solution
for all /foo/bar/baz includes which randomly included parts
of mojo's source directory. Those will need to be updated to use
a package: and deploy_sdk.py taught how to build a package for them.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/990493002
hit-testing needs to walk in backwards order from paint.
The previous attempt at reverse sorting by z-index didn't
reverse things with the same z-index. Instead, forward
sort the same way as we do with paint and then reverse
the whole vector.
R=abarth@chromium.org, eseidel@chromium.org
Review URL: https://codereview.chromium.org/986793002
In order to make the Dart Analyzer stop complaining about
Event not having a default constructor (and all Event subclasses
not having an explicit constructor, thus having an implicit one
which calls the default Event() constructor), I made all of
Event()'s parameters named and thus optional, but did not update
our one sky test which used Event().
The real fix is probably to make the autogenerator smart enough
to have FooEvent() call super("foo"), but I was lazy.
This at least fixes the tests (and greens the waterfall) for now.
TBR=abarth@chromium.org
BUG=
Review URL: https://codereview.chromium.org/988573002
- Removed out-of-date README.md
- Moved fling-curve into the animation directory because it's part of the
animation behavior of the system.
- Moved view-configuration into the theme directory because it's a collection
of constants similar in flavor to the colors and the shadows. Eventually
we'll want to make the theme configurable and have these all together will
hopefully make that easier.
- Moved dom-serializer into tests/resources because it is used only by tests.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/980423002
This change causes the generated abstract class having the same name as the interface to contain only the interface's method declarations. The generated Proxy class then implements the base class. In addition to implementing the interface methods, the generated Proxy class has one private field _proxyImpl, which is a MojoEventStreamListener and manages sending messages and receiving responses. Operations on the ProxyImpl (close, bind, etc.) are exposed through generated utility functions.
The generated Stub is largely as before with the difference that a class providing a service will implement the mojo interface and *have* a Stub rather than be a Stub. Where appropriate, this change also calls listen() immediately where a Stub is constructed.
BUG=
R=hansmuller@google.com, sky@chromium.org
Review URL: https://codereview.chromium.org/959993002
I also fixed the transform hack in material-element to clean
up after itself.
I also discovered that our namedSetter implementation did not
handle null (it crashed) while doing this. I fixed that
and tested my fix.
This runs great on a Nexus 5, but poorly on an Nexus 10.
R=abarth@chromium.org
BUG=
Review URL: https://codereview.chromium.org/956753002
-Get rid of paintsWithTransform.
-Remove currentTransform. It was only ever called with
IncludeTransformOrigin and on non-null transforms.
-Remove renderableTransform. It was only called on
non-null transforms.
-Remove a layer()->parent() branch. The ASSERT had been
added in a previous patch, but the branch wasn't removed.
-Inline makeMatrixRenderable. It was only called in one
place.
-Add a test to make sure that transform origin is corrrectly
excluded from the transform computedStyle.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/958463002
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
On the web, if you set position:absolute, but not
top/right/bottom/left, then the absolute goes where it
would have gone if it wasn't positioned. The use-cases for
this are slim and it introduces a lot of complexity to the
engine.
Also changes behavior in the presence of direction:rtl.
On the web, direction:rtl and top/left:auto would
sometimes set right:0. Instead we always position at
0,0 if the opposing values are auto.
This removes the code for this positioning and allows
simplifying a bunch of dirty bit handling code since
we don't need to setNeedsLayout if lines move around
or wrap differently.
The test cases did change their output, but the new
positioning all looks correct to me.
Review URL: https://codereview.chromium.org/944073006
We only need to walk the immediate children of the paragraph.
The other inline children of the paragraph will get paint called
on them and they will then appropriately add the self painting
layers to the array inside their paint calls.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/945223002
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
The only bit that was still used was the
containingBlockLogicalWidthChanged check in
RenderBlock::widthAvailableToChildrenHasChanged.
a4f1e657ff
is the patch that added that code. I added a
test to confirm we still pass the test case
that code was added for.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/945003002
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
Change hit testing to walk over the render tree instead of
the RenderLayer tree. This is a step in the direction of
removing the RenderLayer tree entirely.
For now, there's a few calls back into RenderLayer that
will be removed in a followup patch. This patch also
breaks hit testing on transformed inlines. I'll be
removing the ability to transform inlines in a
followup patch anyways, so it's ok for hit testing
to give the wrong result temporarily here.
Almost all of this patch is just moving code from
RenderLayer to RenderBox. The primary substantive change
is in RenderBox::hitTestLayer. Instead of having
hitTestChildren calls, we call collectSelfPaintingLayers,
reverse sort by z-index (so we start at the top),
and then iterate over the result.
The test-case also exposes that we don't correctly hit
transformed elements inside inline-blocks. I went back as
far as 4153b8a515d54275934d4244aaf2d5a7a8fe3333 and the
bug still happened.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/945693002
These now appear on internals as takeServicesProvidedToEmbedder and
takeServicesProvidedByEmbedder. When you call these functions, you get back the
raw int that represents the handle. We'll need to wrap them up inside the Dart
VM with the appropriate types. We can create a nice wrapper for that in a
future CL.
R=hansmuller@google.com, hansmuller@chromium.org
Review URL: https://codereview.chromium.org/944733002
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
I'm not 100% what this was for, but looking at Blink,
it appears that HitTestChildBlockBackground being different
from HitTestBlockBackground had something to do with
multi-column/regions, which we don't have. I believe
this patch doesn't change any behavior.
Also added to the elementFromPoint test in order to
get more test coverage of the hitTesting code.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/924263002
This CL removes a number of tests that we don't plan to port to Dart:
1) custom-elements. We're going to use a different mechanism for custom
elements. We'll need to write a new set of tests as we implement it.
2) inspector. These are tests of the JS inspector backend, which we don't
plan to use.
3) js. This is a test of a JavaScript feature.
4) mocha. These are tests of the JavaScript testing framework we were using.
5) mutation-observer. We're keeping the C++ code for mutation observers, but
it's unclear how we want to expose this in the platform.
6) resources. These are JavaScript-based testing frameworks.
R=eseidel@chromium.org, ojan@chromium.org
Review URL: https://codereview.chromium.org/920343002
