{"@attributes":{"version":"2.0"},"channel":{"title":"TingPing's blog","description":"Development blog of TingPing","link":"https:\/\/blog.tingping.se\/","pubDate":"Thu, 02 Jan 2025 12:12:03 -0500","lastBuildDate":"Thu, 02 Jan 2025 12:12:03 -0500","generator":"Jekyll v3.10.0","item":[{"title":"Introducing the WebKit Container SDK","description":"

Developing WebKitGTK<\/a> and WPE<\/a> has always had challenges such as the amount of dependencies or it\u2019s fairly complex C++ codebase which not all compiler versions handle well. To help with this we\u2019ve made a new SDK to make it easier.<\/p>\n\n\n\n

Current Solutions<\/h3>\n\n

There have always been multiple ways to build WebKit and its dependencies on your host however this was never a great developer experience. Only very specific hosts could be \u201csupported\u201d, you often had to build a large number of dependencies, and the end result wasn\u2019t very reproducable for others.<\/p>\n\n

The current solution used by default is a Flatpak based one. This was a big improvement for ease of use and excellent for reproducablity but it introduced many challenges doing development work. As it has a strict sandbox and provides read-only runtimes it was difficult to use complex tooling\/IDEs or develop third party libraries in it.<\/p>\n\n

The new SDK tries to take a middle ground between those two alternatives, isolating itself from the host to be somewhat reproducable, yet being a mutable environment to be flexible enough for a wide range of tools and workflows.<\/p>\n\n

The WebKit Container SDK<\/h3>\n\n

At the core it is an Ubuntu OCI image with all of the dependencies and tooling needed to work on WebKit. On top of this we added some scripts to run\/manage these containers with podman and aid in developing inside of the container. It\u2019s intention is to be as simple as possible and not change traditional development workflows.<\/p>\n\n

You can find the SDK and follow the quickstart guide on our GitHub: https:\/\/github.com\/Igalia\/webkit-container-sdk<\/a><\/p>\n\n

The main requirements is that this only works on Linux with podman 4.0+ installed. For example Ubuntu 23.10+.<\/p>\n\n

In the most simple case, once you clone https:\/\/github.com\/Igalia\/webkit-container-sdk.git<\/code>, using the SDK can be a few commands:<\/p>\n\n

source<\/span> \/your\/path\/to\/webkit-container-sdk\/register-sdk-on-host.sh\nwkdev-create --create-home<\/span>\nwkdev-enter\n<\/code><\/pre><\/div><\/div>\n\n
From there you can use WebKit\u2019s build scripts (.\/Tools\/Scripts\/build-webkit --gtk<\/code>) or CMake. As mentioned before it is an Ubuntu installation so you can easily install your favorite tools directly like VSCode. We even provide a wkdev-setup-vscode<\/code> script to automate that.<\/p>\n\n
Advanced Usage<\/h3>\n\n
Disposibility<\/h4>\n\n
A workflow that some developers may not be familiar with is making use of entirely disposable development environments. Since these are isolated containers you can easily make two. This allows you to do work in parallel that would interfere with eachother while not worrying about it as well as being able to get back to a known good state easily:<\/p>\n\n
wkdev-create --name=playground1\nwkdev-create --name=playground2\n\npodman rm playground1 # You would stop first if running.\nwkdev-enter --name=playground2\n<\/code><\/pre><\/div><\/div>\n\n
Working on Dependencies<\/h4>\n\n
An important part of WebKit development is working on the dependencies of WebKit rather than itself, either for debugging or for new features. This can be difficult or error-prone with previous solutions. In order to make this easier we use a project called JHBuild<\/a> which isn\u2019t new but works well with containers and is a simple solution to work on our core dependencies.<\/p>\n\n
Here is an example workflow working on GLib:<\/p>\n\n
wkdev-create --name=glib\nwkdev-enter --name=glib\n\n# This will clone glib main, build, and install it for us. \njhbuild build glib\n\n# At this point you could simply test if a bug was fixed in a different versin of glib.\n# We can also modify and debug glib directly. All of the projects are cloned into ~\/checkout.\ncd ~\/checkout\/glib\n\n# Modify the source however you wish then install your new version.\njhbuild make\n<\/code><\/pre><\/div><\/div>\n\n
Remember that containers are isoated from each other so you can even have two terminals open with different builds of glib. This can also be used to test projects like Epiphany against your build of WebKit if you install it into the JHBUILD_PREFIX.<\/p>\n\n
To Be Continued<\/h3>\n\n
In the next blog post I\u2019ll document how to use VSCode inside of the SDK for debugging and development.<\/p>\n","pubDate":"Thu, 23 May 2024 00:00:00 -0400","link":"https:\/\/blog.tingping.se\/2024\/05\/23\/Introducing-WebKit-Container-SDK.html","guid":"https:\/\/blog.tingping.se\/2024\/05\/23\/Introducing-WebKit-Container-SDK.html","category":["igalia","webkit"]},{"title":"WebExtension Support in Epiphany","description":"
I\u2019m excited to help bring WebExtensions to Epiphany<\/a> (GNOME Web) thanks to investment from my employer Igalia<\/a>. In this post, I\u2019ll go over a summary of how extensions work and give details on what Epiphany supports.<\/p>\n\n\n\n
Web browsers have supported extensions in some form for decades. They allow the creation of features that would otherwise be part of a browser but can be authored and experimented with more easily. They\u2019ve helped develop and popularize ideas like ad blocking, password management, and reader modes. Sometimes, as in very popular cases like these, browsers themselves then begin trying to apply lessons upstream.<\/p>\n\n
Toward universal support<\/h2>\n\n
For most of this history, web extensions have used incompatible browser-specific APIs. This began to change in 2015 with Firefox adopting an API similar to Chrome\u2019s. In 2020, Safari also followed suit. We now have the foundations of an ecosystem-wide solution.<\/p>\n\n
\u201cThe foundations of\u201d is an important thing to understand: There are still plenty of existing extensions built with browser-specific APIs and this doesn\u2019t magically make them all portable. It does, however, provide a way towards making portable extensions. In some cases, existing extensions might just need some porting. In other cases, they may utilize features that aren\u2019t entirely universal yet (or, may never be).<\/p>\n\n
Bringing Extensions to Epiphany<\/h2>\n\n
With version 43.alpha Epiphany users can begin<\/em> to take advantage of some of the same powerful and portable extensions described above. Note that there are quite a few APIs that power this and with this release we\u2019ve covered a meaningful segment of them but not all (details below). Over time our API coverage and interoperability will continue to grow.<\/p>\n\n
What WebExtensions can do: Technical Details<\/h2>\n\n
At a high level, WebExtensions allow a private privileged web page to run in the browser. This is an invisible Background Page<\/a> that has access to a browser<\/code><\/a> JavaScript API. This API, given permission, can interact with browser tabs, cookies, downloads, bookmarks, and more.<\/p>\n\n
Along with the invisible background page, it gives a few options to show a UI to the user. One such method is a Browser Action<\/a> which is shown as a button in the browser\u2019s toolbar that can popup an HTML view for the user to interact with. Another is an Options Page<\/a> dedicated to configuring the extension.<\/p>\n\n
Lastly, an extension can inject JavaScript directly into any website it has permissions to via Content Scripts<\/a>. These scripts are given full access to the DOM of any web page they run in. However content scripts don\u2019t have access to the majority of the browser<\/code> API but, along with the above pages, it has the ability to send and receive custom JSON messages to all pages within an extension.<\/p>\n\n
Example usage<\/h3>\n\n
For a real-world example, I use Bitwarden as my password manager which I\u2019ll simplify how it roughly functions. Firstly there is a Background Page that does account management for your user. It has a Popup that the user can trigger to interface with your account, passwords, and options. Finally, it also injects Content Scripts into every website you open.<\/p>\n\n
The Content Script can detect all input fields and then wait for a message to autofill information into them. The Popup can request the details of the active tab and, upon you selecting an account, send a message to the Content Script to fill this information. This flow does function in Epiphany now but there are still some issues to iron out for Bitwarden.<\/p>\n\n
Epiphany\u2019s current support<\/h2>\n\n
Epiphany 43.alpha supports the basic structure described above. We are currently modeling our behavior after Firefox\u2019s ManifestV2 API which includes compatibility with Chrome extensions where possible. Supporting ManifestV3 is planned alongside V2 in the future.<\/p>\n\n
As of today, we support the majority of:<\/p>\n\n