| This directory provides API definitions for CEF. Some extensions are implemented |
| using Mojo and others use an older JSON-based format. |
| |
| <api> is the name of the API definition (e.g. 'alarms'). |
| <class> is the name of the class implementation (e.g. 'AlarmManager'). |
| |
| To add a new extension API implemented only in CEF ***: |
| |
| 1. Add libcef/common/extensions/api/<api>.idl or .json file which defines the |
| API. |
| 2. Add <api>.idl or .json to the 'schema_sources' list in |
| libcef/common/extensions/api/BUILD.gn. Serialization code will be |
| generated based on this list in step 4. |
| 3. Add libcef/browser/extensions/api/<api>/<api>_api.[h|cc] class implementation |
| files and associated entries to the 'libcef_static' target in BUILD.gn. |
| 4. Run the cef_create_projects script and build to generate the |
| cef/libcef/common/extensions/api/<api>.h file and other serialization code |
| required by the extensions system. |
| 5. Add an entry in the libcef/common/extensions/api/_*_features.json files if |
| necessary [1]. |
| 6. Add an entry in the libcef/common/extensions/api/*_manifest_overlay.json |
| files if necessary [2]. |
| 7. Call `<class>::GetInstance();` or `<class>Factory::GetFactoryInstance();` [3] |
| from EnsureBrowserContextKeyedServiceFactoriesBuilt in |
| libcef/browser/extensions/browser_context_keyed_service_factories.cc. |
| 8. Call `DependsOn(<class>Factory::GetInstance());` from |
| CefExtensionSystemFactory::CefExtensionSystemFactory in |
| libcef/browser/extensions/extension_system_factory.cc if necessary [3]. |
| |
| *** Note that CEF does not currently expose its own Mojo APIs. Related code is |
| commented out in: |
| cef/BUILD.gn |
| cef/libcef/common/extensions/api/BUILD.gn |
| CefExtensionsBrowserClient::RegisterExtensionFunctions |
| CefExtensionsClient::IsAPISchemaGenerated |
| CefExtensionsClient::GetAPISchema |
| |
| To add a new extension API implemented in Chrome: |
| |
| 1. Register the API in libcef/browser/extensions/chrome_api_registration.cc |
| 2. Perform steps 5 through 8 above. |
| |
| See https://www.chromium.org/developers/design-documents/mojo for more |
| information. |
| |
| [1] A feature can optionally express requirements for where it can be accessed. |
| See the _api_features.json and _permission_features.json files for |
| additional details. For Chrome extensions this should match the definitions |
| in the chrome/common/extensions/api/_*_features.json files. |
| |
| [2] Service Manifest InterfaceProviderSpecs control interfaces exposed between |
| processes. Mojo interfaces exposed at the frame level are controlled by the |
| "navigation:frame" dictionary. Those exposed at the process level are |
| controlled by the "service_manager:connector" dictionary. Failure to specify |
| this correctly may result in a console error like the following: |
| |
| InterfaceProviderSpec "navigation:frame" prevented service: |
| service:content_renderer from binding interface: |
| mojom::Foo exposed by: service:content_browser |
| |
| [3] Some Mojo APIs use singleton Factory objects that create a one-to-one |
| relationship between a service and a BrowserContext. This is used primarily |
| to control shutdown/destruction order and implementors must explicitly state |
| which services are depended on. See comments in |
| components/keyed_service/content/browser_context_keyed_service_factory.h |
| for additional details. |