13 Commits

Author SHA1 Message Date
Adam Barth
4f1ad264d9 Make it possible to navigate <iframes>
Also, add support for exposing services to <iframes>. This worked before but
now that [Client=...] is gone we need to create another message pipe.

R=sky@chromium.org

Review URL: https://codereview.chromium.org/882723003
2015-01-27 10:35:52 -08:00
James Robinson
c0c8a41eb3 Remove [Client=] annotation from ServiceProvider
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
2015-01-21 18:36:01 -08:00
Adam Barth
881b06dfc5 <iframe> should expose its mojo::ServiceProvider handle
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
2015-01-21 16:24:58 -08:00
Adam Barth
6f3a5a1496 Move the call to mojo::View::Embed to HTMLIFrameElement
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
2015-01-21 10:49:24 -08:00
Elliott Sprehn
c4cc8dd831 Remove didNotifySubtreeInsertionsToDocument.
This hook existed because some elements wanted to run script inside
::insertedInto, but that wasn't a safe time. Now nothing can run script
inside there so we don't need this extra hook.

HTMLStyleElement's usage of this hook is not clear, but it seems like
it might have related to a pre-lazy attach bug.

R=abarth@chromium.org

Review URL: https://codereview.chromium.org/758623002
2014-11-25 02:53:43 -05:00
Eric Seidel
e0fd75b5ab Make absolute and sort all Sky headers
This caused us to lose our gn check certification. :(

Turns out gn check was just ignoring all the header
paths it didn't understand and so gn check passing
for sky wasn't meaning much.  I tried to straighten
out some of the mess in this CL, but its going to take
several more rounds of massaging before gn check
passes again.  On the bright side (almost) all of
our headers are absolute now.  Turns out my script
(attached to the bug) didn't notice ../ includes
but I'll fix that in the next patch.

R=abarth@chromium.org
BUG=435361

Review URL: https://codereview.chromium.org/746023002
2014-11-20 17:42:05 -08:00
Matt Perry
7f17e0b4b9 Unrevert "Sky: When an iframe element is removed, delete its mojo View."
This reverts commit acec66c735d6a40d3da3e0e9a6ee5f278bdfe043.

Scott thinks he fixed the crash.

BUG=434555
TBR=sky@chromium.org

Review URL: https://codereview.chromium.org/740383002
2014-11-20 11:13:16 -05:00
Eric Seidel
55b5bc485d Sort headers
Fix (most) generated includes to have gen/ in their path.

This makes it easier to tell where files exist on disk.

Unfortunately I had to leave the old include path
in engine/BUILD.gn to support all the v8 includes
which were too many to deal with in this patch.

It's a little nasty to have the raw build directory
in our include path, but it produces nicer paths.

R=abarth@chromium.org
2014-11-19 12:33:42 -08:00
Matt Perry
2a60db84ea Revert "Sky: When an iframe element is removed, delete its mojo View."
This reverts commit 45991a3752e6a6298901eba36e7bf4cdec4d263c.

It was causing flaky crashes on the bots.

TBR=esprehn@chromium.org
BUG=434555

Review URL: https://codereview.chromium.org/740773002
2014-11-19 15:13:28 -05:00
Matt Perry
14ec13d9c0 Sky: When an iframe element is removed, delete its mojo View.
R=esprehn@chromium.org

Review URL: https://codereview.chromium.org/733063007
2014-11-18 14:00:05 -05:00
Matt Perry
037ca1b039 Rename RenderRemote to RenderIFrame.
R=ojan@chromium.org

Review URL: https://codereview.chromium.org/723143003
2014-11-13 18:19:28 -05:00
Matt Perry
d4ddbf836c Add a separate call to initialize the bounds for a sky <iframe> element.
Also rename the methods to refer to "frames" not "views".

R=abarth@chromium.org

Review URL: https://codereview.chromium.org/682413006
2014-11-11 11:11:59 -05:00
Matt Perry
694cabc454 Initial work on a new <view> element backed by a mojo::View.
This CL introduces an HTMLViewElement which, when inserted into a document,
causes a mojo::View to be created and navigated to the provided URL. No
compositing is done, but the view manager handles the rendering (as I
understand it).

R=abarth@chromium.org

Review URL: https://codereview.chromium.org/708903002
2014-11-07 14:34:07 -05:00