In preperation for removing the Client annotation from ServiceProvider
this passes a second parameter of type ServiceProvider in the shell and
application Connect calls. In this patch the type signatures are updated
but the second parameter is basically unused. The intention is that the
first parameter |services| will be used for the connecting application to
request services from the connected application (as it does currently)
and the second parameter |exported_services| be used for the connecting
application to provide services to the connected application. We have
very few services exported in the second direction today - I'll update
them to use the second parameter in a follow-up patch.
R=darin@chromium.org
Review URL: https://codereview.chromium.org/845593003
Delete selection paint invalidation code.
There is a slight change in behavior in FrameSelection::revealSelection.
If you have a non-collapsed selection, then we'll center the start
of the selection instead of the whole selection in some cases. There's
a ton of callers of this code, so it's hard to be sure if any of this
actually changes behavior for sky. In manual testing, I couldn't find
any scenarios where there was a difference. Almost universally,
when we call revealSelection, we have a CaretSelection. The only
case I could think of where we have a RangeSelection is when
modifying an off-screen selection (e.g. shift+right), but in that case
we pass the RevealExtent option, so this patch doesn't change behavior
there.
Removing that caller makes all the rest of this rect computing
code into dead code.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/823123003
There is a slight change in behavior in FrameSelection::revealSelection.
If you have a non-collapsed selection, then we'll center the start
of the selection instead of the whole selection in some cases. There's
a ton of callers of this code, so it's hard to be sure if any of this
actually changes behavior for sky. In manual testing, I couldn't find
any scenarios where there was a difference. Almost universally,
when we call revealSelection, we have a CaretSelection. The only
case I could think of where we have a RangeSelection is when
modifying an off-screen selection (e.g. shift+right), but in that case
we pass the RevealExtent option, so this patch doesn't change behavior
there.
Removing that caller makes all the rest of this rect computing
code into dead code.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/847303003
Remove all of ui/views, ui/aura/, ui/compositor, ui/ozone,
and a whole bunch of dead code.
This is part one of multiple patches. This removes the
toplevel directories, and some utility files. Further
patches will deep dive to do surgery on the build system,
the resource bundles, et cetera.
BUG=443439
R=sky@chromium.org
Review URL: https://codereview.chromium.org/851853002
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
This removes the upgrade candidate machinery so now if an
element is created before it's registered it'll never get
turned into the correct type. created() callbacks and the
correct wrappers being created can stil happen async though
because certain operations are not safe to run script inside
of (ex. the parser or editing).
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/843063005
All this method did was check if imports were loaded, and sky's parser
will wait on imports anyway, so there's no reason to block rendering
on imports as they'll likely be at the top of the document and stop
the rest of the page from being appended or rendered.
Sky apps will probably also want more control over rendering and not
want the old school web style of incremental rendering.
R=abarth@chromium.org, ojan@chromium.org
Review URL: https://codereview.chromium.org/835273006
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
I was going to remove all this anyway since we don't need it in sky, all sheets
are local and there's no concept of a pending sheet now.
I also removed the dirty bit I added to StyleSheetCollection. The bit
is not correct and is preventing us from correctly processing sheets and
invalidating style. I'll add it back later when I understand how to add
the dirty bit correctly.
R=ojan@chromium.org
Review URL: https://codereview.chromium.org/846183002
Includes updating DCHECK_IS_ON to a function-style macro and removing
various dead skia-overriding code from Sky.
Review URL: https://codereview.chromium.org/851503003
The update doesn't actually do anything until the resolver
is created, just skip the tree walk.
This also removes the special case for document from StyleSheetCollection
which didn't make any sense. It would cause us to discard the entire
resolver whenever the sheets in the document changed which is far more
work than is actually needed. We probably are missing some font invalidation
code now, but we can add that back later.
R=ojan@chromium.org
Review URL: https://codereview.chromium.org/836383005
The loop in StyleEngine::updateActiveStyleSheets calls this
for every scope whenever any stylesheet is added or removed
from the document, ex. appending a new SkyElement with a
<style> in it. The method was crawling the scope and looking
for all sheets and then marking the element as needing a
SubtreeStyleRecalc, instead keep a dirty bit to avoid doing
a full document recalc all the time.
I made this slow previously when I removed all the dirty tree
scope tracking logic and made us go down the reconstruct path
in the resolver update all the time.
We now keep a dirty bit and only do this work when the sheets
for a scope have changed.
R=ojan@chromium.org
Review URL: https://codereview.chromium.org/846703003
ShadowRoot should deal with adding and removing itself from the active
scope list. HTMLStyleElement should just add/remove itself directy from
the StyleSheetCollection on the scope its entering or leaving in
insertedInto/removedFrom.
R=ojan@chromium.org
Review URL: https://codereview.chromium.org/844133002
There's no reason to do this, if an element matched
an attribute rule then it'll have a unique style and
RenderStyle::isSharable() will return false so we
wouldn't even get here.
If we could have matched an attribute rule, but didn't
actually match one then we can continue to share with
other elements that aren't affected by attribute rules
since even though our attributes could affect styling
the rules didn't match us.
R=ojan@chromium.org
Review URL: https://codereview.chromium.org/843233002
Instead of checking if the rule is from the right scope
in SelectorChecker, just store :host rules separately
and always assume rules are in the right scope in the
checker.
This removes a lot of complexity that was passing around
the scope and checking it, and also the need to plumb
if we're matching UA rules down into the checker.
R=ojan@chromium.org
Review URL: https://codereview.chromium.org/848493003
This is all wasted effort in sky since we invalidate
the whole viewport on every frame. We'll probably eventually
add back in some invalidation, but it likely won't
be rect-based.
R=esprehn@chromium.org
Review URL: https://codereview.chromium.org/840403003
This removes the client relationship between the sky::InspectorFrontend
and sky::InspectorBackend mojo interfaces. Instead, the two are now
unrelated (in the mojom) and just happen to be often used together.
The inspector service provides the InspectorFrontend interface to
connecting applications and optimistically tries to connect to the
InspectorBackend interface of applications that connect, in case they
want to receive messages. The front and back end interfaces are both
broadcast APIs, so no attempt is made to keep track of which binding
is which. If they did need to be correlated this could be easily
accomplished by allocating a new object to keep a
mojo::Binding<sky::InspectorFrontend> and the corresponding
sky::InspectorBackendPtr.
R=abarth@chromium.org, eseidel@chromium.org
Review URL: https://codereview.chromium.org/835463003
