OLD | NEW |
(Empty) | |
| 1 Navigation Service |
| 2 ==== |
| 3 |
| 4 ### Overview |
| 5 |
| 6 Navigation is a Chrome Foundation Service that provides the concept of a |
| 7 "navigable view". A navigable view is an application host that can be |
| 8 navigated to different states in sequence, like a traditional "webview" on other |
| 9 platforms. |
| 10 |
| 11 The Navigation service maintains a tree of frames, within which different |
| 12 applications run. Each navigation state corresponds to a potentially different |
| 13 tree structure with different applications run in each frame. |
| 14 |
| 15 In theory, the Navigation service should not care about the specifics of the |
| 16 application hosted in each frame, though in practice today because the |
| 17 implementation is provided by //content, all frames are instances of Blink. |
| 18 |
| 19 When an application hosted by a view requires a capability not intrinsic to the |
| 20 container, it requests via the ViewClient that the embedder provide it. For some |
| 21 capabilities the grant action is simply providing some metadata directly. For |
| 22 others, they are modeled by the acquisition of a Mojo message pipe handle |
| 23 (interface) to some service that exposes the capability. In this latter case it |
| 24 is possible, again in theory, that the middleware layer (Navigation service) not |
| 25 know about the specifics of the capability and just forward the request from the |
| 26 frame renderer to the Navigation service client where it will either be bound or |
| 27 the message pipe closed. |
| 28 |
| 29 A client of the Navigation service may embed a visual representation of a view i
nto |
| 30 its own rendering using Mus. The View interface provides a means to acquire a |
| 31 mus.mojom.WindowTreeClient that can be embedded in a mus::Window created by the |
| 32 client. The Navigation service may create its own mus::Windows within this windo
w, |
| 33 but these will not be visible to the client according to Mus security policy. |
| 34 |
| 35 ### Details |
| 36 |
| 37 Concretely, this service is a //content client, using the Content Public API |
| 38 to construct a WebContents for every request for a navigation::mojom::View. |
| 39 The class that binds these two together is //services/navigation/view_impl.h. |
| 40 This class implements the WebContentsDelegate (& other) interfaces to learn |
| 41 about state changes within the Content layer & transmit them to the Navigation |
| 42 Service client via navigation::mojom::ViewClient. |
| 43 |
| 44 Note that the //content client provided here |
| 45 (in //services/navigation/content_client) is very simple, even simpler than |
| 46 Content Shell's. This is not intended to be a long term solution, just a |
| 47 mechanism to avoid changing Content. If we were to deploy this code in //chrome, |
| 48 we might want to expose these interfaces from content directly. |
| 49 |
| 50 Lastly, the desired end state of the service-refactoring is that //content |
| 51 ceases to exist, so at that point it's conceivable that //content types that |
| 52 are used to implement these interfaces end up in this directory. But that's a |
| 53 long way off. |
| 54 |
| 55 ### Usage |
| 56 |
| 57 For convenience, as synchronizing some navigable view state is tricky, a client |
| 58 library is provided in //services/navigation/public/cpp. The types exposed in |
| 59 this library mimic conventional platform WebView types. |
| 60 |
| 61 std::unique_ptr<navigation::View> view(new navigation::View); |
| 62 ViewDelegateImpl delegate; |
| 63 ViewObserverImpl observer; |
| 64 view->set_delegate(&delegate); |
| 65 view->AddObserver(&observer); |
| 66 view->EmbedInWindow(some_mus_window); |
| 67 view->NavigateToURL(GURL("http://www.chromium.org/")); |
OLD | NEW |