How to work on the WebEngine project

Context

The WebEngine project is a package that will encompass all the web view related handling. This is a work in progress, and the package lives under BrowserKit. The goal of the project is to add a layer of abstraction between the Client (Firefox iOS) and handling webviews. As a result, we'll add unit tests coverage in areas that were previously hard/impossible to do so, increase ease-of-maintenance and development speed, while enabling us to fix long standing bugs in webviews with confidence.

Architecture

Note that this architecture is based on GeckoView. There's no concepts of Tabs and Tabs management under the WebEngine.

This is an overview of the most important classes under the WebEngine. There's only one Engine per application. An Engine creates an EngineView and EngineSession(s). You can see the EngineView as the container where a webview is rendered. The EngineSession handles all interaction with a WKWebView. This means pretty much anything you touch will relate in some way to the WKEngineSession and is a good place to start about learning about the project. From a Client perspective, each Tab will have it's own EngineSession. If there's 10 tabs in the Client, then we have 10 EngineSession, but only one EngineView per window.

Further notes:

• We surface events happening in the webview to the Client through the EngineSessionDelegate.
• WKEngineSession holds a reference to the concrete WKWebView object.

Considerations

• WebEngine should never be aware of tab storage and tab management. The WebEngine relates to the Tab object and how URL's are navigated and managed inside this tab webview, through WKNavigationDelegate and WKUIDelegate.
• WebEngine should never create UI views; either the WebEngine asks the Client to show a view in a container or the Client pass down the view to be shown.

Adding a WebEngine feature

As part of the work under this epic, each feature migrated to the WebEngine should aim to have the following requirements done:

1. Unit tests for all code added under the WebEngine. Not aiming for 100% coverage, but where it makes sense tests needs to be written. If you are moving code from the Client under this package, add tests when there were none.
2. Testing the functionality added in the SampleBrowser project. Keep things as simple and straightforward as possible, avoiding creating UI elements (using Settings to toggle certain feature is acceptable).