| 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 |