Skip to content

How to work on the WebEngine project

lmarceau edited this page Feb 11, 2025 · 7 revisions

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, all the 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 has 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. We surface events happening in the webview to the Client through the EngineSessionDelegate.

Screenshot 2025-02-11 at 3 54 11 PM

Pitfalls

  • WebEngine isn't 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 shouldn't create UI views; either the Client pass down the view to be shown, or the WebEngine asks the Client to show a view in a container.

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 make 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).
Clone this wiki locally