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 |