diff --git a/aperezdc/learn-discover-rework/.stamp b/aperezdc/learn-discover-rework/.stamp
new file mode 100644
index 000000000..1e11e380c
--- /dev/null
+++ b/aperezdc/learn-discover-rework/.stamp
@@ -0,0 +1 @@
+Wed Feb 28 15:36:22 UTC 2024
diff --git a/aperezdc/learn-discover-rework/README/index.html b/aperezdc/learn-discover-rework/README/index.html
new file mode 100644
index 000000000..0a3cc271f
--- /dev/null
+++ b/aperezdc/learn-discover-rework/README/index.html
@@ -0,0 +1,46 @@
+
wpewebkit.org
+
wepwebkit.org is a statically generated site for WPE. The website aims to be simple to maintain and with little complexity and dependencies. It is built with 11ty and Liquid templates - and that’s pretty much it.
+
The actual site is hosted by Igalia who are the primary maintainers of the project.
+
Development
+
In order to setup, you just just have to check it out, switch to the checked out directory and then npm install.
+
Building wpewebkit.org site locally
+
In order to test it all you need to do is
+
npminstall&&npm run serve
+
This will build the project, start a server, and your terminal will provide you useful links to actually get to it.
+
Structure
+
+
+
_site is the output folder, where the generated and served content lives. It is committed and github pages used to provide a sharable dev URL in case you want to discuss proposed changes easily or test for something without exposing things behind your own firewall.
+
+
+
_includes contains templates and partials. Currently our templates are based on a variant of Stylish Portfolio simply because that is what we had to start with.
+
+
+
_posts contains much of the actual content: release notes, security advisories, posts, etc as .md files with front matter. These generate individual .html files in _site.
+
+
+
assets contain images and things, they are copied directly into their relevant directory in _site.
+
+
+
css This is where our CSS goes. Currently, our CSS is overrides and customizations for the Stylish Portfolio CSS. There is no preprocessing at the moment.
+
+
+
release contains the markdown and directory structure for the release schedule page.
+
+
+
vendor this contains thirdparty stuff that we will use directly in the site - it is copied wholesale into its relevant spot in the output directory (_site). There is currently too much in there - our page uses stylish portfolio, which uses bootstrap, which uses jQuery and font-awesome and simple-line-icons. These in turn contain things for bundling, pre-processing with several different preprocessors, etc. We will probably simplify this further, that’s a lot of downloads, code and round-trips for such a simple site.
+
+
+
about contains page posts that are about various aspects of wpe
+
+
+
In the root directory you will also find some top level files - index.htmlwhich is the template for the main page, release.md which is the template for creating the release pages, a package.json which is, well, what you’d expect and .eleventy.js which does some very understandable work in creating a date filter for outputting dates (because of how some of the old content exists), and creates some ‘recent’ collections for simple templating of things like release notes and security advisories.
+
Updating wpewebkit.org site
+
+
The website is automatically updated from this repository. So simply commit to master or send a pull-request.
+
+
Updating content
+
In order to write a new release or security advisory piece in the website
+you just have to create a new file inside _posts folder using
+Markdown syntax.
+
Should you need anything else, you will find 11ty’s documentation pretty helpful.
diff --git a/aperezdc/learn-discover-rework/_authors/aperez/index.html b/aperezdc/learn-discover-rework/_authors/aperez/index.html
new file mode 100644
index 000000000..6b00ceb4c
--- /dev/null
+++ b/aperezdc/learn-discover-rework/_authors/aperez/index.html
@@ -0,0 +1,17 @@
+
+
+
+
+
+
+
+ This article was written by Adrián Pérez.
+
+ I have been working on WebKit since 2012, with a focus on
+ environment integration, embedding, and distribution. Igalia
+ has been a life-long project since even earlier.
+
+
+ This article was written by Loïc Le Page.
+
+ I have worked in different industries like video games,
+ cinema, and multimedia—the latter being where my
+ focus lies at the moment. Did anyone say Web engines need
+ that, too?
+
I'm a proud Igalian since 2019 and have been working on WebKits predecessors since the early 2000s, namely kjs/khtml/ksvg, and kdom/kcanvas/ksvg2/khtml2 that all found their way into WebKit. Since that time, Web technology - especially SVG - is my main area of interest.
+
+
WPE WebKit is widely adopted in many industries, including digital signage, professional audio, video and broadcasting, home appliances, set-top boxes, and automative and in-flight infotainment systems.
+
+
+
+
+
+
If you need a fast and lightweight web runtime for Linux-based embedded devices that supports most current web standards, has hardware acceleration wherever it is advantageous, and has a strong focus on multimedia applications, WPE WebKit is a great choice.
+
WPE WebKit offers great possibilities for deployment on different platforms, thanks to its underlying design which allows for integration in a variety of hardware configurations. At a minimum, only EGL and OpenGL ES 2 support and basic GStreamer integration are required.
+
+
+
Some advantages of WPE WebKit
+
+
The minimal set of dependencies needed to run WPE WebKit ensures that its footprint is small and it consumes less memory, which allows applications built with WPE WebKit to run on low-end devices.
+
Enables rich and fast 2D and 3D HTML-based user interfaces, multimedia integration, 3D content, and many more of the latest Web technologies to run smoothly and efficiently on low-cost devices.
+
Displays multimedia content with high-quality CSS 3D animations, WebGL, and fluid high-quality HTML videos.
+
Focused on graphics performance with multi-threading optimizations to improve CSS animation, scrolling, scaling, and rendering of canvas and video elements.
+
Provides a strong focus on multimedia applications and performance with WebRTC, MSE (MP4, WebM, VP9, Opus) and EME (ClearKey and other third-party DRM frameworks) supported and constantly improving.
+
Unlicensed parts of YouTube TV and similar platforms are supported.
+
+
+
+
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
WPE is the official WebKit port for embedded platforms. WPE is uniquely designed
+for embedded systems in that it doesn’t depend on any user-interface toolkit
+such as the traditional Cocoa, GTK, etc toolkits.
+
+
+
+
+
+
Web page rendering
+
WPE is considered a hybrid port because it defers the final web page delivery for display to a rendering backend. A traditional port would provide a widget for a given toolkit, but WPE opted for a different and more flexible approach.
+
The common interface between WPEWebKit and its rendering backends is provided by
+libwpe. On one side, once
+WPEWebKit has a graphical representation of the final composited Web page ready
+for rendering, it invokes a callback function on libwpe. On the other side,
+the WPE application has to register a view backend on the WPE WebView. This view
+backend is provided by the rendering backend. The view backend receives the Web
+page representation from libwpe, usually as an EGLImage, and is in charge of
+presenting it in the application, on-screen.
+
The decoupling between generating the WebPage representation on WebKit side and
+the actual rendering on the application side provides a very flexible design.
+For instance, WPE integrators can easily develop a new rendering backend for
+specific embedded platforms that might have a graphics driver with special API
+requirements.
+
WPE provides a rendering backend aiming to target the most common platforms and
+leverage the existing graphics stack available in the
+Freedesktop umbrella eco-system.
+WPEBackend-FDO is the reference
+implementation of the base rendering backend design. WPEBackend-FDO provides an API
+for WPE applications that aims to ease the handling of rendering either
+on-screen using EGL, or off-screen using SHM.
+
+
+
Input events handling
+
In a traditional WebKit port, the provided widget usually also handles input
+(keyboard, mouse, touch) events and is in charge of relaying them to the
+internal WebKit input-methods components.
+
As WPE doesn’t provide a widget, it relies on libwpe APIs to relay input
+events from the WPE application to the internal WebKit input-methods components.
+This design again adds flexibility to the overall WPE architecture, enabling
+applications to support new input devices without having to go through a UI
+toolkit first.
+
In the example of the Cog WPE browser, the
+application relies on Wayland protocols for user input to communicate events
+coming from the Wayland compositor to WPE.
+
+
+
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
While there are several simple ways for developers to experiment with and explore WPE, none are tuned for performance. Generally, shipping products for embedded systems are performance-tuned custom builds. To make this easier, there is also meta-webkit, which provides build recipes, WebKit based runtimes, and browsers for use with OpenEmbedded and/or Yocto.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
What is the difference between WebPlatformForEmbedded’s WPE and WPEWebKit?
+
Historically, the WebPlatformForEmbedded flavor of WPE came first. It included several adaptations for the Reference Design Kit (RDK) platform, as well as different fixes for its supported devices. Quoting the RDK website:
+
+
RDK is a fully modular, portable, and customizable open source software
+solution that standardizes core functions used in video, broadband and IoT
+devices.
+
+
The RDK WPE page provides more
+information about WPE in the RDK platform.
+
In 2017, engineers from Igalia submitted a new flavor of WPE, suitable for upstream hosting under the webkit.org umbrella. This version of WPE is released every 6 months from the code hosted on the upstream repository. This flavor of WPE is maintained upstream and provides regular security updates.
+
Is WPE supported on any specific hardware System-on-Chip?
+
WPE has been ported to a wide range of hardware platforms. The team aims to expand the list even further, so don’t hesitate to contact us if you can’t find your favorite SoC in the list.
+
Is WPE ported to non-Linux operating systems?
+
WPE currently only works on Linux-based operating systems. We are currently working on supporting Android, though. If you require WPE to run on any other OS, don’t hesitate to contact us.
+
What Web features does WPE support?
+
The WebKit project provides a features status page to which you can refer. However, that information should be taken with a grain of salt. The multi-platform nature of WebKit implies that ports have different build-time and runtime configurations.
+
The WPE project currently does not have an official list of the Web features it supports. It might provide one in the future, but for the time being, we recommend users check for specific features by testing WPE through the Cog browser.
LibWebRTC is bundled as third-party library in WebKit’s upstream repository.
+
The LibWebRTC backend doesn’t support hardware-accelerated encoders and decoders.
+
LibWebRTC bundles BoringSSL, which is a fork of OpenSSL started while OpenSSL
+was still under the dual OpenSSL and SSLeay licences.
+
+
Taking these facts into account, the WPEWebKit maintainers have decided to leave WebRTC support disabled in the default build configuration of the official release tarballs because:
+
+
Bundling LibWebRTC in tarballs significantly increases the archive size.
+
The dependency on BoringSSL prevents LibWebRTC usage in GPL applications.
+
The lack of hardware-accelerated support in LibWebRTC would incur a bad
+performance impact on the embedded platforms that WPE targets.
+
+
In order to solve these issues, an alternative WebRTC backend based on GstWebRTC will be enabled by default in the WPE upstream CMake build, hopefully during 2023; bug #235885 is being used to track progress. This new backend will seamlessly integrate with hardware-accelerated encoders and decoders on most embedded platforms. GstWebRTC depends on OpenSSL, which is released under an Apache-style license, so it doesn’t have limitations regarding redistribution in binary form.
+
What’s up with EME? How can I support this feature in my WPE-based product?
+
There is code in WebKit to support Encrypted Media Extensions (EME), but in any case, you will need a license agreement with DRM CDM providers to access it, since this part is not open source. There are three ways you can get this working:
Cog is a small single “window” launcher for the WebKit WPE port. It is small,
+provides no user interface, and is suitable to be used as a Web application
+container. The “window” may be fullscreen depending on the WPE backend being
+used.
+
+
Cog’s usage scenarios span from a MiniBrowser application to a full web-app container application meant to run HTML-based user interfaces on embedded platforms and products.
+
Although it can run on Linux-based desktop environments, Cog is not a full-blown Web Browser to be compared with Google Chrome or Safari. Cog’s primary environment is on embedded platforms, and it can run within a Wayland compositor such as Weston. Additionally, if the platform supports KMS/DRM, Cog can run as a full-screen standalone browser, this use-case is very common on kiosk products for instance.
+
If you are a developer aiming to enable WPE on a certain embedded platform, Cog combined with WPEBackend-FDO provides the most flexible solution for agile tinkering and to test WPE’s features.
+
Is Wayland required to run WPE?
+
As we say in Galicia, “it depends”.
+
WPE’s architecture was designed in order to
+decouple rendering out of the Web engine and delegate this task to rendering
+backends and to the application running the Web engine—it does not strictly
+require usage of Wayland.
+
Typically when talking about Wayland we tend to conflate many things:
+
+
+
Wayland itself is an IPC
+protocol which happens to be designed to move buffers containing pixel
+data and input events from one process to another.
+
+
+
The Wayland package typically contains the reference implementation
+of the protocol, libwayland. Other implementations are theoretically
+possible.
+
+
+
By extension we may refer to a compositor, which is a program that
+implements the server–side of the Wayland
+protocol—possibly with the aid of libwayland.
+
+
+
If you use WPEBackend-fdo, it internally uses the Wayland
+protocol (via libwayland) to pass rendered frames from the WPEWebProcess
+program to the application that embeds the web view—that we call “the UI
+process”. As this is an implementation detail of the backend, the fact that
+Wayland is used as IPC protocol does not need to be known by the application.
+A compositor may be required or not depending on how the UI process displays
+the web content.
+
For example, Cog can act as a Wayland client using its FDO platform plug-in, and in that case a
+Wayland compositor is required. On the other hand, using Cog’s DRM platform plug-in it will display
+rendered web content directly on screen (without a running Wayland
+compositor). Note that in both cases WPEBackend-fdo is used as backend,
+which means that the Wayland protocol is still in use.
+
Some WPE backends may not require Wayland at all. Such is the case
+of WPEBackend-rdk in some configurations
+(USE_BACKEND_BCM_RPI, USE_BACKEND_BCM_NEXUS, etc.)
+
Are open dialogs/popups menus supported?
+
The application embedding WPE is responsible for rendering popups and dialogs. The reference WPE Browser, Cog, has limited support for these features (as of 2021, it supports option menus).
+
What is the wayland-protocols build dependency about in Cog?
+
Depending on which platform rendering plugin is enabled at build time, the Cog browser might depend on the wayland-protocols project to generate source files needed in order to act as a Wayland client to the compositor (server) implementing those protocols.
+
So for instance, if you enable the FDO platform plugin and want to use it at runtime to have Cog running as a Wayland application, then the plugin will try to consume some Wayland protocols from the server, such as xdg-shell, fullscreen-shell-unstable-v1, presentation-time and linux-dmabuf-unstable-v1. Those protocols can’t be used without first generating source files derived from each protocol XML spec definition. This is all part of the Wayland design.
+
Why does the browser/launcher (e.g. Cog) crash at startup?
+
If you are building an embedded system image yourself, make sure there is at least one font installed that can be used as fallback by Fontconfig. You can use the fc-list program to print the list of known fonts.
+
Why does the browser/launcher (e.g. Cog) crash when trying to play audio?
+
If you are building an embedded system image yourself, make sure that the
+GStreamer elements autoaudiosink and alsasink are installed. Even if your
+system uses some other audio output by default (PulseAudio, PipeWire, etc.)
+ALSA is always tried as the last fallback if all the other available sinks
+fail.
+
Why does the browser/launcher (e.g. Cog) not load local files?
+
If you are building an embedded system image yourself, make sure to install
+the shared MIME database is installed—in most distributions
+this is part of a package named shared-mime-info. WebKit uses it to
+determine which kind of data within file before loading it. Note that this is
+not needed if you plan to loading remote resources because HTTP servers
+provide the needed information in the Content-Type HTTP header.
+
+
+
+
+
+
+
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
WPE is an open source/free software project. That means that you can
+get the source code directly and modify it to serve your needs. While
+this can sometimes be an involved process, there are different ways to
+get your hands on WPE, depending on what you need.
Before getting the code, it’s a good idea to be familiar with what you
+will need. The different components that are needed to run WPE are:
+
+
WebKit: as WPE is an official WebKit port, you will need the source code for the WebKit project.
+
libwpe: A general-purpose library for WPE, that enables integration between WebKit and different platforms, through backends.
+
WPEBackend-fdo: A reference FreeDesktop.org backend for WPE, that relies on different FreeDesktop.org projects and can serve as a starting point to either customize or create a completely new backend for specific configurations.
+
Cog: A simple and minimalistic browser using WPE, with no user interface, suitable to be used as a Web application container or as a starting point to develop more complex browser applications based on WPE.
+
+
Install it from your Linux distribution
+
These packages are not just a quick and simple way to test WPE but
+they also come with all the development files and documentation
+necessary to build and test software that uses this web engine. Some
+of the distributions that already have built packages for WPE are:
This list is not exhaustive, so if you use a different distributions,
+there might be packages for it already. Refer to the official
+documentation of your distribution for information on how to install packages.
+
Build an image for supported reference hardware
+
A simple way to cross-compile WPE and its dependencies for a target
+architecture is to use an existing build framework. We provide recipes
+for a OpenEmbedded/Yocto layer for WPE.
+There are specific instructions in the
+project wiki.
+
Download the official tarball releases
+
We periodically package WPE and its associated libraries, following a
+predictable release schedule, to make sure that
+both stable and development versions are available to users,
+deployers, and developers. Following the release schedule is the best
+way to follow the progress of WPE, get a sense of what’s coming, and
+properly prepare for updates in your production deployments.
+
Unstable releases are development versions, that give a preview of
+what’s coming in the next stable release. These are useful for
+beta-testing, and to prepare to upgrade your deployment to an upcoming
+stable release when this is out. Unstable releases should never be
+used in production.
+
Below is a summary of the latest stable and unstable releases for WPE
+and its components:
This is the most involved way to get the source code, and it’s only
+recommended for developers who are interested in getting involved in
+the development of the project, or who need to implement any feature
+that is not yet available in WPE. Additionally, this can be also be
+a good way to track down any bug you might find and to fix it.
Instead of downloading each of these components on their own, a good way to start is to fetch the WebKit repository
+and use its build system to fetch all the dependencies. Check the instructions for building WebKit.
+
If you find any problem or want to know more about optimizing WPE for your hardware or use cases, please contact us.
A few pointers on how to get better performance out of WPEwebkit. (Github Wiki)
+
+
+
+
+
+
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
We understand that WPE is interesting from many perspectives, and to people of potentially vastly different backgrounds. Let’s help you find what you’re looking for.
WPE WebKit is widely adopted by many industries, including digital signage, professional audio, home appliances, set-top-boxes, automotive, and inflight infotainment. Countless devices deployed around the globe are already using WPE WebKit as their web runtime platform, and use is growing rapidly.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
WPE WebKit is widely adopted in many industries, including digital signage, home appliances, set-top boxes, and automative and in-flight infotainment systems.
The maintainer and sponsor of WPEwebkit, Igalia is an open-source and web standards consultancy spanning the globe.
+
+
+
+
+
+
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Long ago, it might have been reasonable to imagine browsers only in the realm of desktop computers. However, embedded browsers are in everything these days: cars, signs, tablets, gaming systems, televisions and appliances. They’re even in space!
+
+
The Web Platform is a frequently chosen foundational technology for many reasons, including:
+
+
Because Web Platform technologies are built on standards, they have great longevity
+
Because these standards are open, embedded systems can incorporate them without licensing fees or other worries.
+
Open standards with great longevity allows lots more things to benefit from the same investments
+
The number of people with the basic skills to build things with web technologies is massive
+
+
The fact that over the past few years, billions of new devices have come online, and the implications of this are still under-discussed. We believe developers need to be able explore and understand this space, and that lessons learned here are potentially helpful to the larger web ecosystem as well. However, this can be challenging, because embedded browsers are a little different…
+
Why embedded browsers are different
+
For many of us, a browser is an application like the one you’re probably using now. You click an icon on your graphical operating system (OS), navigate somewhere with a URL bar, search, and so on. You have bookmarks and tabs that you can drag around, and lots of other features.
+
In contrast, an embedded browser is contained within another application or is built for a specific purpose and runs in an embedded system, and the application controlling the embedded browser does not provide all the typical features of browsers running in desktops.
+
Furthermore, for most embedded systems there isn’t a common desktop OS for the browser to run on — in fact, the OS is built specifically for that type of device, and the embedded browser is built along with it. Part of the reason for this is that, by and large, they are not general-purpose computing devices. They have slightly different security concerns, and they also run on often radically different sorts of hardware than desktop, laptop or many mobile devices.
+
So, what really is an embedded browser?
+
Browsers, engines and ports
+
A “proper” browser is, in all likelihood, the application in which you are reading this. This browser is built on one of three open source projects: WebKit, Chromium or Gecko. Each of these projects defines an engine — that is, they provide an architecture through which something else (e.g., a browser) can bind to the top layer of the engine in order to drive us from URL to URL, and use the engine’s bottom layer to do things like actually put content on the screen, render graphics, receive input from devices like keyboards, mice and pointing devices, and connect to things like the text-to-speech subsystem.
+
In terms of WebKit-based browsers, a “port” is the set of extra layers that provides facilities at those top and bottom layers of the engine. The WebKit project has a few “official” ports that are available from webkit.org/downloads/. Some, like Safari, are fully-featured desktop browsers. WebKitGTK is a port for the GTK GUI toolkit, used among others by the desktop browser Epiphany.
+
WPE (“Web Platform for Embedded”) is the official port for embedded systems, and it adds another layer to the architecture allowing for more easily swappable backends (the graphics layers, windowing and so on) and simpler bindings for programmatic top-level control in Linux based systems. Cog is another project that makes it easier to launch and drive WPE views.
+
In other words, WPE is designed to be built and optimized for your embedded device in order to deliver the best performance. What all of this means is that there isn’t really a single “WPE” that’s as easy to provide as many browsers that you’re probably familiar with.
+
+
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/aperezdc/learn-discover-rework/assets/SourceSans3VF-Italic.otf b/aperezdc/learn-discover-rework/assets/SourceSans3VF-Italic.otf
new file mode 100644
index 000000000..19ffdee31
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/SourceSans3VF-Italic.otf differ
diff --git a/aperezdc/learn-discover-rework/assets/SourceSans3VF-Italic.ttf b/aperezdc/learn-discover-rework/assets/SourceSans3VF-Italic.ttf
new file mode 100644
index 000000000..814f834af
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/SourceSans3VF-Italic.ttf differ
diff --git a/aperezdc/learn-discover-rework/assets/SourceSans3VF-Italic.ttf.woff b/aperezdc/learn-discover-rework/assets/SourceSans3VF-Italic.ttf.woff
new file mode 100644
index 000000000..1934bb082
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/SourceSans3VF-Italic.ttf.woff differ
diff --git a/aperezdc/learn-discover-rework/assets/SourceSans3VF-Italic.ttf.woff2 b/aperezdc/learn-discover-rework/assets/SourceSans3VF-Italic.ttf.woff2
new file mode 100644
index 000000000..753755416
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/SourceSans3VF-Italic.ttf.woff2 differ
diff --git a/aperezdc/learn-discover-rework/assets/SourceSans3VF-Roman.otf b/aperezdc/learn-discover-rework/assets/SourceSans3VF-Roman.otf
new file mode 100644
index 000000000..baae69659
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/SourceSans3VF-Roman.otf differ
diff --git a/aperezdc/learn-discover-rework/assets/SourceSans3VF-Roman.ttf b/aperezdc/learn-discover-rework/assets/SourceSans3VF-Roman.ttf
new file mode 100644
index 000000000..093d01d02
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/SourceSans3VF-Roman.ttf differ
diff --git a/aperezdc/learn-discover-rework/assets/SourceSans3VF-Roman.ttf.woff b/aperezdc/learn-discover-rework/assets/SourceSans3VF-Roman.ttf.woff
new file mode 100644
index 000000000..5e1f981c0
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/SourceSans3VF-Roman.ttf.woff differ
diff --git a/aperezdc/learn-discover-rework/assets/SourceSans3VF-Roman.ttf.woff2 b/aperezdc/learn-discover-rework/assets/SourceSans3VF-Roman.ttf.woff2
new file mode 100644
index 000000000..48d5ff89e
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/SourceSans3VF-Roman.ttf.woff2 differ
diff --git a/aperezdc/learn-discover-rework/assets/author-aperez@1x.png b/aperezdc/learn-discover-rework/assets/author-aperez@1x.png
new file mode 100644
index 000000000..0318523c2
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/author-aperez@1x.png differ
diff --git a/aperezdc/learn-discover-rework/assets/author-aperez@2x.png b/aperezdc/learn-discover-rework/assets/author-aperez@2x.png
new file mode 100644
index 000000000..19fe6034f
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/author-aperez@2x.png differ
diff --git a/aperezdc/learn-discover-rework/assets/author-llepage@1x.png b/aperezdc/learn-discover-rework/assets/author-llepage@1x.png
new file mode 100644
index 000000000..d1ec5987b
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/author-llepage@1x.png differ
diff --git a/aperezdc/learn-discover-rework/assets/author-llepage@2x.png b/aperezdc/learn-discover-rework/assets/author-llepage@2x.png
new file mode 100644
index 000000000..001fd1171
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/author-llepage@2x.png differ
diff --git a/aperezdc/learn-discover-rework/assets/build-webkit-org-screenshot.png b/aperezdc/learn-discover-rework/assets/build-webkit-org-screenshot.png
new file mode 100644
index 000000000..9750e75a8
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/build-webkit-org-screenshot.png differ
diff --git a/aperezdc/learn-discover-rework/assets/bw_Twitter_Profile_400px.png b/aperezdc/learn-discover-rework/assets/bw_Twitter_Profile_400px.png
new file mode 100644
index 000000000..8b2d58bbd
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/bw_Twitter_Profile_400px.png differ
diff --git a/aperezdc/learn-discover-rework/assets/bw_Twitter_Profile_WhiteBg_400px.png b/aperezdc/learn-discover-rework/assets/bw_Twitter_Profile_WhiteBg_400px.png
new file mode 100644
index 000000000..53a921d0f
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/bw_Twitter_Profile_WhiteBg_400px.png differ
diff --git a/aperezdc/learn-discover-rework/assets/bw_Web_Logo_Header_300x110px.png b/aperezdc/learn-discover-rework/assets/bw_Web_Logo_Header_300x110px.png
new file mode 100644
index 000000000..d9ced3938
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/bw_Web_Logo_Header_300x110px.png differ
diff --git a/aperezdc/learn-discover-rework/assets/graphics-attachment.png b/aperezdc/learn-discover-rework/assets/graphics-attachment.png
new file mode 100644
index 000000000..a6fc12f7a
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/graphics-attachment.png differ
diff --git a/aperezdc/learn-discover-rework/assets/graphics-graphicslayertree.png b/aperezdc/learn-discover-rework/assets/graphics-graphicslayertree.png
new file mode 100644
index 000000000..0823dd0ef
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/graphics-graphicslayertree.png differ
diff --git a/aperezdc/learn-discover-rework/assets/graphics-renderlayertree.png b/aperezdc/learn-discover-rework/assets/graphics-renderlayertree.png
new file mode 100644
index 000000000..e8f6a9ab0
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/graphics-renderlayertree.png differ
diff --git a/aperezdc/learn-discover-rework/assets/graphics-rendertree.png b/aperezdc/learn-discover-rework/assets/graphics-rendertree.png
new file mode 100644
index 000000000..a4c683fc9
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/graphics-rendertree.png differ
diff --git a/aperezdc/learn-discover-rework/assets/gtk-cog-screenshot.png b/aperezdc/learn-discover-rework/assets/gtk-cog-screenshot.png
new file mode 100644
index 000000000..49be83528
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/gtk-cog-screenshot.png differ
diff --git a/aperezdc/learn-discover-rework/assets/img/Igalia_tagline-white-1.png b/aperezdc/learn-discover-rework/assets/img/Igalia_tagline-white-1.png
new file mode 100644
index 000000000..dc6a63e02
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/Igalia_tagline-white-1.png differ
diff --git a/aperezdc/learn-discover-rework/assets/img/Metrological-hero-orig.jpg b/aperezdc/learn-discover-rework/assets/img/Metrological-hero-orig.jpg
new file mode 100644
index 000000000..eed532c39
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/Metrological-hero-orig.jpg differ
diff --git a/aperezdc/learn-discover-rework/assets/img/Metrological-hero.jpg b/aperezdc/learn-discover-rework/assets/img/Metrological-hero.jpg
new file mode 100644
index 000000000..2649107f3
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/Metrological-hero.jpg differ
diff --git a/aperezdc/learn-discover-rework/assets/img/WPE-design.svg b/aperezdc/learn-discover-rework/assets/img/WPE-design.svg
new file mode 100755
index 000000000..6fffc615e
--- /dev/null
+++ b/aperezdc/learn-discover-rework/assets/img/WPE-design.svg
@@ -0,0 +1,101 @@
+
diff --git a/aperezdc/learn-discover-rework/assets/img/WhyChooseWPE-ExploreLand.png b/aperezdc/learn-discover-rework/assets/img/WhyChooseWPE-ExploreLand.png
new file mode 100644
index 000000000..d7ca5e659
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/WhyChooseWPE-ExploreLand.png differ
diff --git a/aperezdc/learn-discover-rework/assets/img/WhyChooseWPE-homepage.png b/aperezdc/learn-discover-rework/assets/img/WhyChooseWPE-homepage.png
new file mode 100644
index 000000000..bfaf565c5
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/WhyChooseWPE-homepage.png differ
diff --git a/aperezdc/learn-discover-rework/assets/img/WhyChooseWPE.png b/aperezdc/learn-discover-rework/assets/img/WhyChooseWPE.png
new file mode 100644
index 000000000..8532eda72
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/WhyChooseWPE.png differ
diff --git a/aperezdc/learn-discover-rework/assets/img/blog-backends-thumb@1x.png b/aperezdc/learn-discover-rework/assets/img/blog-backends-thumb@1x.png
new file mode 100644
index 000000000..f6d6f23fd
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/blog-backends-thumb@1x.png differ
diff --git a/aperezdc/learn-discover-rework/assets/img/blog-backends-thumb@2x.png b/aperezdc/learn-discover-rework/assets/img/blog-backends-thumb@2x.png
new file mode 100644
index 000000000..b2ba0807f
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/blog-backends-thumb@2x.png differ
diff --git a/aperezdc/learn-discover-rework/assets/img/border-dot-black.svg b/aperezdc/learn-discover-rework/assets/img/border-dot-black.svg
new file mode 100755
index 000000000..11750c638
--- /dev/null
+++ b/aperezdc/learn-discover-rework/assets/img/border-dot-black.svg
@@ -0,0 +1,4 @@
+
diff --git a/aperezdc/learn-discover-rework/assets/img/border-dot-white.svg b/aperezdc/learn-discover-rework/assets/img/border-dot-white.svg
new file mode 100755
index 000000000..d0318fa5d
--- /dev/null
+++ b/aperezdc/learn-discover-rework/assets/img/border-dot-white.svg
@@ -0,0 +1,3 @@
+
diff --git a/aperezdc/learn-discover-rework/assets/img/checkmark.png b/aperezdc/learn-discover-rework/assets/img/checkmark.png
new file mode 100644
index 000000000..d593d3fe0
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/checkmark.png differ
diff --git a/aperezdc/learn-discover-rework/assets/img/dash-h.svg b/aperezdc/learn-discover-rework/assets/img/dash-h.svg
new file mode 100644
index 000000000..690121e88
--- /dev/null
+++ b/aperezdc/learn-discover-rework/assets/img/dash-h.svg
@@ -0,0 +1,9 @@
+
+
\ No newline at end of file
diff --git a/aperezdc/learn-discover-rework/assets/img/dash-v.svg b/aperezdc/learn-discover-rework/assets/img/dash-v.svg
new file mode 100644
index 000000000..c1a0df340
--- /dev/null
+++ b/aperezdc/learn-discover-rework/assets/img/dash-v.svg
@@ -0,0 +1,9 @@
+
+
\ No newline at end of file
diff --git a/aperezdc/learn-discover-rework/assets/img/diagram-WPE-design.svg b/aperezdc/learn-discover-rework/assets/img/diagram-WPE-design.svg
new file mode 100644
index 000000000..5b4bde790
--- /dev/null
+++ b/aperezdc/learn-discover-rework/assets/img/diagram-WPE-design.svg
@@ -0,0 +1,103 @@
+
diff --git a/aperezdc/learn-discover-rework/assets/img/dotted-continents.svg b/aperezdc/learn-discover-rework/assets/img/dotted-continents.svg
new file mode 100644
index 000000000..5fef31ce8
--- /dev/null
+++ b/aperezdc/learn-discover-rework/assets/img/dotted-continents.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/aperezdc/learn-discover-rework/assets/img/extending-minicog-echouri.png b/aperezdc/learn-discover-rework/assets/img/extending-minicog-echouri.png
new file mode 100644
index 000000000..072691d78
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/extending-minicog-echouri.png differ
diff --git a/aperezdc/learn-discover-rework/assets/img/graphic-title-blue.svg b/aperezdc/learn-discover-rework/assets/img/graphic-title-blue.svg
new file mode 100755
index 000000000..a5a83c8b8
--- /dev/null
+++ b/aperezdc/learn-discover-rework/assets/img/graphic-title-blue.svg
@@ -0,0 +1,10 @@
+
diff --git a/aperezdc/learn-discover-rework/assets/img/graphic-title-white.svg b/aperezdc/learn-discover-rework/assets/img/graphic-title-white.svg
new file mode 100755
index 000000000..48006b66c
--- /dev/null
+++ b/aperezdc/learn-discover-rework/assets/img/graphic-title-white.svg
@@ -0,0 +1,10 @@
+
diff --git a/aperezdc/learn-discover-rework/assets/img/igalia-larger.png b/aperezdc/learn-discover-rework/assets/img/igalia-larger.png
new file mode 100644
index 000000000..de7d77cba
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/igalia-larger.png differ
diff --git a/aperezdc/learn-discover-rework/assets/img/igalia-logo.png b/aperezdc/learn-discover-rework/assets/img/igalia-logo.png
new file mode 100644
index 000000000..23ef44b1a
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/igalia-logo.png differ
diff --git a/aperezdc/learn-discover-rework/assets/img/igalia.png b/aperezdc/learn-discover-rework/assets/img/igalia.png
new file mode 100644
index 000000000..c2aa4cc79
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/igalia.png differ
diff --git a/aperezdc/learn-discover-rework/assets/img/illustration-community.svg b/aperezdc/learn-discover-rework/assets/img/illustration-community.svg
new file mode 100755
index 000000000..dee25750b
--- /dev/null
+++ b/aperezdc/learn-discover-rework/assets/img/illustration-community.svg
@@ -0,0 +1,43 @@
+
diff --git a/aperezdc/learn-discover-rework/assets/img/illustration-resources.svg b/aperezdc/learn-discover-rework/assets/img/illustration-resources.svg
new file mode 100755
index 000000000..ca162dbd1
--- /dev/null
+++ b/aperezdc/learn-discover-rework/assets/img/illustration-resources.svg
@@ -0,0 +1,72 @@
+
diff --git a/aperezdc/learn-discover-rework/assets/img/link_ext_icon.svg b/aperezdc/learn-discover-rework/assets/img/link_ext_icon.svg
new file mode 100644
index 000000000..32b63637d
--- /dev/null
+++ b/aperezdc/learn-discover-rework/assets/img/link_ext_icon.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/aperezdc/learn-discover-rework/assets/img/list-arrow.svg b/aperezdc/learn-discover-rework/assets/img/list-arrow.svg
new file mode 100644
index 000000000..a31b9c7f8
--- /dev/null
+++ b/aperezdc/learn-discover-rework/assets/img/list-arrow.svg
@@ -0,0 +1,9 @@
+
+
\ No newline at end of file
diff --git a/aperezdc/learn-discover-rework/assets/img/logo-NOS.png b/aperezdc/learn-discover-rework/assets/img/logo-NOS.png
new file mode 100755
index 000000000..2a7ecea4e
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/logo-NOS.png differ
diff --git a/aperezdc/learn-discover-rework/assets/img/logo-NOS@2x.png b/aperezdc/learn-discover-rework/assets/img/logo-NOS@2x.png
new file mode 100755
index 000000000..9c4a40cdf
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/logo-NOS@2x.png differ
diff --git a/aperezdc/learn-discover-rework/assets/img/logo-black.svg b/aperezdc/learn-discover-rework/assets/img/logo-black.svg
new file mode 100644
index 000000000..f94bb095d
--- /dev/null
+++ b/aperezdc/learn-discover-rework/assets/img/logo-black.svg
@@ -0,0 +1,28 @@
+
diff --git a/aperezdc/learn-discover-rework/assets/img/logo-blue.svg b/aperezdc/learn-discover-rework/assets/img/logo-blue.svg
new file mode 100644
index 000000000..84e47beb2
--- /dev/null
+++ b/aperezdc/learn-discover-rework/assets/img/logo-blue.svg
@@ -0,0 +1,28 @@
+
diff --git a/aperezdc/learn-discover-rework/assets/img/logo-digital-signage.png b/aperezdc/learn-discover-rework/assets/img/logo-digital-signage.png
new file mode 100644
index 000000000..7aa44568d
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/logo-digital-signage.png differ
diff --git a/aperezdc/learn-discover-rework/assets/img/logo-digital-signage@2x.png b/aperezdc/learn-discover-rework/assets/img/logo-digital-signage@2x.png
new file mode 100644
index 000000000..887c294d8
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/logo-digital-signage@2x.png differ
diff --git a/aperezdc/learn-discover-rework/assets/img/logo-garmin.png b/aperezdc/learn-discover-rework/assets/img/logo-garmin.png
new file mode 100755
index 000000000..597b5f12f
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/logo-garmin.png differ
diff --git a/aperezdc/learn-discover-rework/assets/img/logo-garmin@2x.png b/aperezdc/learn-discover-rework/assets/img/logo-garmin@2x.png
new file mode 100755
index 000000000..8c0c817be
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/logo-garmin@2x.png differ
diff --git a/aperezdc/learn-discover-rework/assets/img/logo-liberty.png b/aperezdc/learn-discover-rework/assets/img/logo-liberty.png
new file mode 100755
index 000000000..2103a5248
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/logo-liberty.png differ
diff --git a/aperezdc/learn-discover-rework/assets/img/logo-liberty@2x.png b/aperezdc/learn-discover-rework/assets/img/logo-liberty@2x.png
new file mode 100755
index 000000000..cc047c920
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/logo-liberty@2x.png differ
diff --git a/aperezdc/learn-discover-rework/assets/img/logo-metrological.png b/aperezdc/learn-discover-rework/assets/img/logo-metrological.png
new file mode 100755
index 000000000..1a22433f2
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/logo-metrological.png differ
diff --git a/aperezdc/learn-discover-rework/assets/img/logo-metrological@2x.png b/aperezdc/learn-discover-rework/assets/img/logo-metrological@2x.png
new file mode 100755
index 000000000..eae62ac29
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/logo-metrological@2x.png differ
diff --git a/aperezdc/learn-discover-rework/assets/img/logo-multichoice.png b/aperezdc/learn-discover-rework/assets/img/logo-multichoice.png
new file mode 100755
index 000000000..fc5a5b538
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/logo-multichoice.png differ
diff --git a/aperezdc/learn-discover-rework/assets/img/logo-multichoice@2x.png b/aperezdc/learn-discover-rework/assets/img/logo-multichoice@2x.png
new file mode 100755
index 000000000..1421e9d1f
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/logo-multichoice@2x.png differ
diff --git a/aperezdc/learn-discover-rework/assets/img/logo-nvidia.png b/aperezdc/learn-discover-rework/assets/img/logo-nvidia.png
new file mode 100755
index 000000000..b70b901d0
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/logo-nvidia.png differ
diff --git a/aperezdc/learn-discover-rework/assets/img/logo-nvidia@2x.png b/aperezdc/learn-discover-rework/assets/img/logo-nvidia@2x.png
new file mode 100755
index 000000000..ba1226187
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/logo-nvidia@2x.png differ
diff --git a/aperezdc/learn-discover-rework/assets/img/logo-nxp.png b/aperezdc/learn-discover-rework/assets/img/logo-nxp.png
new file mode 100644
index 000000000..51171af90
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/logo-nxp.png differ
diff --git a/aperezdc/learn-discover-rework/assets/img/logo-nxp@2x.png b/aperezdc/learn-discover-rework/assets/img/logo-nxp@2x.png
new file mode 100755
index 000000000..8470d229b
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/logo-nxp@2x.png differ
diff --git a/aperezdc/learn-discover-rework/assets/img/logo-ombori.png b/aperezdc/learn-discover-rework/assets/img/logo-ombori.png
new file mode 100755
index 000000000..774bf4bf3
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/logo-ombori.png differ
diff --git a/aperezdc/learn-discover-rework/assets/img/logo-ombori@2x.png b/aperezdc/learn-discover-rework/assets/img/logo-ombori@2x.png
new file mode 100755
index 000000000..133d7730b
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/logo-ombori@2x.png differ
diff --git a/aperezdc/learn-discover-rework/assets/img/logo-qualcomm.png b/aperezdc/learn-discover-rework/assets/img/logo-qualcomm.png
new file mode 100755
index 000000000..02e1d5b60
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/logo-qualcomm.png differ
diff --git a/aperezdc/learn-discover-rework/assets/img/logo-qualcomm@2x.png b/aperezdc/learn-discover-rework/assets/img/logo-qualcomm@2x.png
new file mode 100755
index 000000000..b74fa5592
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/logo-qualcomm@2x.png differ
diff --git a/aperezdc/learn-discover-rework/assets/img/logo-rockchip.png b/aperezdc/learn-discover-rework/assets/img/logo-rockchip.png
new file mode 100755
index 000000000..f0040c19b
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/logo-rockchip.png differ
diff --git a/aperezdc/learn-discover-rework/assets/img/logo-rockchip@2x.png b/aperezdc/learn-discover-rework/assets/img/logo-rockchip@2x.png
new file mode 100755
index 000000000..c6e59367b
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/logo-rockchip@2x.png differ
diff --git a/aperezdc/learn-discover-rework/assets/img/logo-server-side-rendering.png b/aperezdc/learn-discover-rework/assets/img/logo-server-side-rendering.png
new file mode 100644
index 000000000..961621b28
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/logo-server-side-rendering.png differ
diff --git a/aperezdc/learn-discover-rework/assets/img/logo-server-side-rendering@2x.png b/aperezdc/learn-discover-rework/assets/img/logo-server-side-rendering@2x.png
new file mode 100644
index 000000000..1c22b326c
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/logo-server-side-rendering@2x.png differ
diff --git a/aperezdc/learn-discover-rework/assets/img/logo-telefonica.png b/aperezdc/learn-discover-rework/assets/img/logo-telefonica.png
new file mode 100755
index 000000000..946e0f087
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/logo-telefonica.png differ
diff --git a/aperezdc/learn-discover-rework/assets/img/logo-telefonica@2x.png b/aperezdc/learn-discover-rework/assets/img/logo-telefonica@2x.png
new file mode 100755
index 000000000..7109a60e9
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/logo-telefonica@2x.png differ
diff --git a/aperezdc/learn-discover-rework/assets/img/logo-televic.png b/aperezdc/learn-discover-rework/assets/img/logo-televic.png
new file mode 100755
index 000000000..570c67a9f
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/logo-televic.png differ
diff --git a/aperezdc/learn-discover-rework/assets/img/logo-televic@2x.png b/aperezdc/learn-discover-rework/assets/img/logo-televic@2x.png
new file mode 100755
index 000000000..ed7257a0a
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/logo-televic@2x.png differ
diff --git a/aperezdc/learn-discover-rework/assets/img/logo-white.svg b/aperezdc/learn-discover-rework/assets/img/logo-white.svg
new file mode 100644
index 000000000..116d23915
--- /dev/null
+++ b/aperezdc/learn-discover-rework/assets/img/logo-white.svg
@@ -0,0 +1,28 @@
+
diff --git a/aperezdc/learn-discover-rework/assets/img/media-pause.svg b/aperezdc/learn-discover-rework/assets/img/media-pause.svg
new file mode 100644
index 000000000..c91909489
--- /dev/null
+++ b/aperezdc/learn-discover-rework/assets/img/media-pause.svg
@@ -0,0 +1,10 @@
+
+
\ No newline at end of file
diff --git a/aperezdc/learn-discover-rework/assets/img/media-play.svg b/aperezdc/learn-discover-rework/assets/img/media-play.svg
new file mode 100644
index 000000000..02c9ac9c9
--- /dev/null
+++ b/aperezdc/learn-discover-rework/assets/img/media-play.svg
@@ -0,0 +1,9 @@
+
+
\ No newline at end of file
diff --git a/aperezdc/learn-discover-rework/assets/img/menu-x.svg b/aperezdc/learn-discover-rework/assets/img/menu-x.svg
new file mode 100644
index 000000000..a3ceabb70
--- /dev/null
+++ b/aperezdc/learn-discover-rework/assets/img/menu-x.svg
@@ -0,0 +1,6 @@
+
\ No newline at end of file
diff --git a/aperezdc/learn-discover-rework/assets/img/menu.svg b/aperezdc/learn-discover-rework/assets/img/menu.svg
new file mode 100644
index 000000000..f4b9cb69d
--- /dev/null
+++ b/aperezdc/learn-discover-rework/assets/img/menu.svg
@@ -0,0 +1,7 @@
+
\ No newline at end of file
diff --git a/aperezdc/learn-discover-rework/assets/img/pepe-silvia-all-javascript.jpg b/aperezdc/learn-discover-rework/assets/img/pepe-silvia-all-javascript.jpg
new file mode 100644
index 000000000..4f58c7f63
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/pepe-silvia-all-javascript.jpg differ
diff --git a/aperezdc/learn-discover-rework/assets/img/placeholder.png b/aperezdc/learn-discover-rework/assets/img/placeholder.png
new file mode 100644
index 000000000..60b803408
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/placeholder.png differ
diff --git a/aperezdc/learn-discover-rework/assets/img/survey.svg b/aperezdc/learn-discover-rework/assets/img/survey.svg
new file mode 100644
index 000000000..03f43c667
--- /dev/null
+++ b/aperezdc/learn-discover-rework/assets/img/survey.svg
@@ -0,0 +1,25 @@
+
+
\ No newline at end of file
diff --git a/aperezdc/learn-discover-rework/assets/img/use_case-digital_signage.png b/aperezdc/learn-discover-rework/assets/img/use_case-digital_signage.png
new file mode 100644
index 000000000..9848f2387
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/img/use_case-digital_signage.png differ
diff --git a/aperezdc/learn-discover-rework/assets/lbse-logo-wide.png b/aperezdc/learn-discover-rework/assets/lbse-logo-wide.png
new file mode 100644
index 000000000..b4978347a
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/lbse-logo-wide.png differ
diff --git a/aperezdc/learn-discover-rework/assets/networking-flow.svg b/aperezdc/learn-discover-rework/assets/networking-flow.svg
new file mode 100644
index 000000000..dd6d32697
--- /dev/null
+++ b/aperezdc/learn-discover-rework/assets/networking-flow.svg
@@ -0,0 +1,3 @@
+
+
+
\ No newline at end of file
diff --git a/aperezdc/learn-discover-rework/assets/networking-layers.svg b/aperezdc/learn-discover-rework/assets/networking-layers.svg
new file mode 100644
index 000000000..62ddf4f48
--- /dev/null
+++ b/aperezdc/learn-discover-rework/assets/networking-layers.svg
@@ -0,0 +1,3 @@
+
+
+
\ No newline at end of file
diff --git a/aperezdc/learn-discover-rework/assets/svg/URI_syntax_diagram.svg b/aperezdc/learn-discover-rework/assets/svg/URI_syntax_diagram.svg
new file mode 100644
index 000000000..db042d9dd
--- /dev/null
+++ b/aperezdc/learn-discover-rework/assets/svg/URI_syntax_diagram.svg
@@ -0,0 +1,78 @@
+
+
diff --git a/aperezdc/learn-discover-rework/assets/svg/black_Web_Logo.svg b/aperezdc/learn-discover-rework/assets/svg/black_Web_Logo.svg
new file mode 100644
index 000000000..1cc18a20e
--- /dev/null
+++ b/aperezdc/learn-discover-rework/assets/svg/black_Web_Logo.svg
@@ -0,0 +1,33 @@
+
+
+
diff --git a/aperezdc/learn-discover-rework/assets/svg/blue_Web_Logo.png b/aperezdc/learn-discover-rework/assets/svg/blue_Web_Logo.png
new file mode 100644
index 000000000..c7178565c
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/svg/blue_Web_Logo.png differ
diff --git a/aperezdc/learn-discover-rework/assets/svg/blue_Web_Logo.svg b/aperezdc/learn-discover-rework/assets/svg/blue_Web_Logo.svg
new file mode 100644
index 000000000..d3f56399b
--- /dev/null
+++ b/aperezdc/learn-discover-rework/assets/svg/blue_Web_Logo.svg
@@ -0,0 +1,37 @@
+
+
+
diff --git a/aperezdc/learn-discover-rework/assets/svg/lbse-logo-wide.svg b/aperezdc/learn-discover-rework/assets/svg/lbse-logo-wide.svg
new file mode 100644
index 000000000..11d3ea721
--- /dev/null
+++ b/aperezdc/learn-discover-rework/assets/svg/lbse-logo-wide.svg
@@ -0,0 +1,574 @@
+
+
diff --git a/aperezdc/learn-discover-rework/assets/svg/lbse-logo.svg b/aperezdc/learn-discover-rework/assets/svg/lbse-logo.svg
new file mode 100644
index 000000000..059b21a8e
--- /dev/null
+++ b/aperezdc/learn-discover-rework/assets/svg/lbse-logo.svg
@@ -0,0 +1,498 @@
+
+
diff --git a/aperezdc/learn-discover-rework/assets/svg/part1-basics.md-1.svg b/aperezdc/learn-discover-rework/assets/svg/part1-basics.md-1.svg
new file mode 100644
index 000000000..0ebe5b999
--- /dev/null
+++ b/aperezdc/learn-discover-rework/assets/svg/part1-basics.md-1.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/aperezdc/learn-discover-rework/assets/svg/part1-basics.md-2.svg b/aperezdc/learn-discover-rework/assets/svg/part1-basics.md-2.svg
new file mode 100644
index 000000000..66af63288
--- /dev/null
+++ b/aperezdc/learn-discover-rework/assets/svg/part1-basics.md-2.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/aperezdc/learn-discover-rework/assets/svg/part1-basics.md-3.svg b/aperezdc/learn-discover-rework/assets/svg/part1-basics.md-3.svg
new file mode 100644
index 000000000..dd6cc12db
--- /dev/null
+++ b/aperezdc/learn-discover-rework/assets/svg/part1-basics.md-3.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/aperezdc/learn-discover-rework/assets/svg/part2-eglstream.md-1.svg b/aperezdc/learn-discover-rework/assets/svg/part2-eglstream.md-1.svg
new file mode 100644
index 000000000..49249627d
--- /dev/null
+++ b/aperezdc/learn-discover-rework/assets/svg/part2-eglstream.md-1.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/aperezdc/learn-discover-rework/assets/svg/part2-eglstream.md-2.svg b/aperezdc/learn-discover-rework/assets/svg/part2-eglstream.md-2.svg
new file mode 100644
index 000000000..1f98e77fc
--- /dev/null
+++ b/aperezdc/learn-discover-rework/assets/svg/part2-eglstream.md-2.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/aperezdc/learn-discover-rework/assets/svg/svg_render_tree_lbse.svg b/aperezdc/learn-discover-rework/assets/svg/svg_render_tree_lbse.svg
new file mode 100644
index 000000000..31057f129
--- /dev/null
+++ b/aperezdc/learn-discover-rework/assets/svg/svg_render_tree_lbse.svg
@@ -0,0 +1,3 @@
+
+
+
diff --git a/aperezdc/learn-discover-rework/assets/svg/svg_render_tree_legacy.svg b/aperezdc/learn-discover-rework/assets/svg/svg_render_tree_legacy.svg
new file mode 100644
index 000000000..d66ab66e1
--- /dev/null
+++ b/aperezdc/learn-discover-rework/assets/svg/svg_render_tree_legacy.svg
@@ -0,0 +1,3 @@
+
+
+
diff --git a/aperezdc/learn-discover-rework/assets/svg/twitter_Profile_Color_400px.svg b/aperezdc/learn-discover-rework/assets/svg/twitter_Profile_Color_400px.svg
new file mode 100644
index 000000000..bd2d00840
--- /dev/null
+++ b/aperezdc/learn-discover-rework/assets/svg/twitter_Profile_Color_400px.svg
@@ -0,0 +1,22 @@
+
+
+
diff --git a/aperezdc/learn-discover-rework/assets/svg/twitter_Profile_bw_400px.svg b/aperezdc/learn-discover-rework/assets/svg/twitter_Profile_bw_400px.svg
new file mode 100644
index 000000000..fcd982be4
--- /dev/null
+++ b/aperezdc/learn-discover-rework/assets/svg/twitter_Profile_bw_400px.svg
@@ -0,0 +1,20 @@
+
+
+
diff --git a/aperezdc/learn-discover-rework/assets/svg/web_Logo_Header_Color_300x110px.svg b/aperezdc/learn-discover-rework/assets/svg/web_Logo_Header_Color_300x110px.svg
new file mode 100644
index 000000000..2dfdb2bb7
--- /dev/null
+++ b/aperezdc/learn-discover-rework/assets/svg/web_Logo_Header_Color_300x110px.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/aperezdc/learn-discover-rework/assets/svg/wpe-architecture-diagram.svg b/aperezdc/learn-discover-rework/assets/svg/wpe-architecture-diagram.svg
new file mode 100644
index 000000000..05878b47b
--- /dev/null
+++ b/aperezdc/learn-discover-rework/assets/svg/wpe-architecture-diagram.svg
@@ -0,0 +1,278 @@
+
+
diff --git a/aperezdc/learn-discover-rework/assets/svg/wpe-birthday-cake-5-years.svg b/aperezdc/learn-discover-rework/assets/svg/wpe-birthday-cake-5-years.svg
new file mode 100644
index 000000000..526741935
--- /dev/null
+++ b/aperezdc/learn-discover-rework/assets/svg/wpe-birthday-cake-5-years.svg
@@ -0,0 +1,1207 @@
+
+
+
diff --git a/aperezdc/learn-discover-rework/assets/twitter_Profile_400px.png b/aperezdc/learn-discover-rework/assets/twitter_Profile_400px.png
new file mode 100644
index 000000000..312d0c24b
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/twitter_Profile_400px.png differ
diff --git a/aperezdc/learn-discover-rework/assets/twitter_Profile_WhiteBg_400px.png b/aperezdc/learn-discover-rework/assets/twitter_Profile_WhiteBg_400px.png
new file mode 100644
index 000000000..d70dc10ad
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/twitter_Profile_WhiteBg_400px.png differ
diff --git a/aperezdc/learn-discover-rework/assets/video/WPE-1.mp4 b/aperezdc/learn-discover-rework/assets/video/WPE-1.mp4
new file mode 100644
index 000000000..186744378
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/video/WPE-1.mp4 differ
diff --git a/aperezdc/learn-discover-rework/assets/video/homepage.mp4 b/aperezdc/learn-discover-rework/assets/video/homepage.mp4
new file mode 100644
index 000000000..2eba2fa57
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/video/homepage.mp4 differ
diff --git a/aperezdc/learn-discover-rework/assets/web_Logo_Header_300x110px.png b/aperezdc/learn-discover-rework/assets/web_Logo_Header_300x110px.png
new file mode 100644
index 000000000..2a1cd5671
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/web_Logo_Header_300x110px.png differ
diff --git a/aperezdc/learn-discover-rework/assets/wpe-architecture-diagram.png b/aperezdc/learn-discover-rework/assets/wpe-architecture-diagram.png
new file mode 100644
index 000000000..480b8dae5
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/wpe-architecture-diagram.png differ
diff --git a/aperezdc/learn-discover-rework/assets/wpe-architecture-diagram@2x.png b/aperezdc/learn-discover-rework/assets/wpe-architecture-diagram@2x.png
new file mode 100644
index 000000000..4550524cf
Binary files /dev/null and b/aperezdc/learn-discover-rework/assets/wpe-architecture-diagram@2x.png differ
diff --git a/aperezdc/learn-discover-rework/blog.xml b/aperezdc/learn-discover-rework/blog.xml
new file mode 100644
index 000000000..d93acdbe6
--- /dev/null
+++ b/aperezdc/learn-discover-rework/blog.xml
@@ -0,0 +1,1056 @@
+
+
+ WPE WebKit Blog
+ News related to WPE WebKit.
+
+
+ 2024-02-01T00:00:00Z
+ https://wpewebkit.org/blog/
+
+
+ Use Case: Server-side headless rendering
+
+ 2024-02-01T00:00:00Z
+ https://wpewebkit.org/wpewebkit.org/aperezdc/learn-discover-rework/blog/2024-use-case-server-side-rendering.html
+ <div class="success-top">
+<img alt="WPE and server-side headless rendering" align="center" src="https://wpewebkit.org/assets/img/logo-server-side-rendering.png" srcset="https://wpewebkit.org/assets/img/logo-server-side-rendering@2x.png 2x" />
+</div>
+<p>In many distributed applications, it can be useful to run a light web browser on the server side to render some HTML content or process images, video and/or audio using JavaScript.</p>
+<p>Some concrete use-cases can be:</p>
+<ul>
+<li>Video post-production using HTML overlays.</li>
+<li>Easy 3D rendering with WebGL that can be broadcasted as a video stream.</li>
+<li>Reusing the same JavaScript code between a frontend web application and the backend processing.</li>
+</ul>
+<p>WPE WebKit is the perfect solution for all those use cases as it offers a lightweight solution which can run on low-end hardware or even within a container. It provides a lot of flexibility at the moment of choosing the backend infrastructure as WPE WebKit can, for instance, run from within a container with a very minimal Linux configuration (no need for any windowing system) and with full hardware acceleration and zero-copy of the video buffers between the GPU and the CPU.</p>
+<p>Additionally, the fact that WPE WebKit is optimized for lower-powered devices, makes it also the perfect option for server-side rendering when scaling commercial deployments while keeping cost under control, which is yet another important factor to take into account when considering cloud rendering.</p>
+
+
+
+
+ A New WPE Backend Using EGLStream
+
+ 2024-01-29T06:00:00Z
+ https://wpewebkit.org/wpewebkit.org/aperezdc/learn-discover-rework/blog/07-creating-wpe-backends.html
+ <h2 id="what-is-a-wpe-backend%3F" tabindex="-1">What is a WPE Backend?</h2>
+<div class="sidebar">
+<p>This article is a mashup of <a href="https://blogs.igalia.com/llepage/the-process-of-creating-a-new-wpe-backend/">The process of creating a new WPE
+backend</a>
+and <a href="https://blogs.igalia.com/llepage/use-eglstreams-in-a-wpe-webkit-backend/">Use EGLStreams in a WPE WebKit
+backend</a>,
+originally published at Loïc’s blog.</p>
+</div>
+<p>Depending on the target hardware WPE may need to use different techniques and
+technologies to ensure correct graphical rendering. To be independent of any
+user-interface toolkit and windowing system, WPE WebKit delegates the rendering
+to a third-party API defined in the
+<a href="https://github.com/WebPlatformForEmbedded/libwpe">libwpe</a> library. A concrete
+implementation of this API is a “WPE backend”.</p>
+<p>WPE WebKit is a multiprocess application, the end-user starts and controls the
+web widgets in the application process (which we often call “the <abbr title="User Interface">UI</abbr> process” while the web engine itself uses
+different subprocesses: <code>WPENetworkProcess</code> is in charge of managing network
+connections and <code>WPEWebProcess</code> (or “web process”) in charge of the HTML and
+JavaScript parsing, execution and rendering. The WPE backend is at a crossroads
+between the UI process and one or more web process instances.</p>
+<figure>
+ <a href="https://wpewebkit.org/assets/svg/part1-basics.md-1.svg" target="_blank"><img src="https://wpewebkit.org/assets/svg/part1-basics.md-1.svg" alt="Diagram showing a box for the WPE backend in between the UI process and WPEWebProcess" />
+ </a>
+</figure>
+<p>The WPE backend is a shared library that is loaded at runtime by the web
+process and by the UI process. It is used to render the visual aspect of a web
+page and transfer the resulting video buffer from the web process to the
+application process.</p>
+<h2 id="backend-interfaces" tabindex="-1">Backend Interfaces</h2>
+<p>The WPE backend shared library must export at least one symbol called
+<code>_wpe_loader_interface</code> of type <code>struct wpe_loader_interface</code> as defined <a href="https://github.com/WebPlatformForEmbedded/libwpe/blob/d7c669ca6f5ec0d544c264016d270669b336c931/include/wpe/loader.h#L57">in
+the <em>libwpe</em>
+API</a>.
+Presently its only member is <code>load_object</code>, a callback function that receives a
+string with an interface name and returns concrete implementations of the
+following interfaces:</p>
+<ul>
+<li><a href="https://github.com/WebPlatformForEmbedded/libwpe/blob/d7c669ca6f5ec0d544c264016d270669b336c931/include/wpe/renderer-host.h#L48">struct wpe_renderer_host_interface</a></li>
+<li><a href="https://github.com/WebPlatformForEmbedded/libwpe/blob/d7c669ca6f5ec0d544c264016d270669b336c931/include/wpe/renderer-backend-egl.h#L75">struct wpe_renderer_backend_egl_interface</a></li>
+<li><a href="https://github.com/WebPlatformForEmbedded/libwpe/blob/d7c669ca6f5ec0d544c264016d270669b336c931/include/wpe/renderer-backend-egl.h#L93">struct wpe_renderer_backend_egl_target_interface</a></li>
+<li><a href="https://github.com/WebPlatformForEmbedded/libwpe/blob/d7c669ca6f5ec0d544c264016d270669b336c931/include/wpe/renderer-backend-egl.h#L115">struct wpe_renderer_backend_egl_offscreen_target_interface</a></li>
+<li><a href="https://github.com/WebPlatformForEmbedded/libwpe/blob/d7c669ca6f5ec0d544c264016d270669b336c931/include/wpe/view-backend.h#L63">struct wpe_view_backend_interface</a></li>
+</ul>
+<p>The names passed to the <code>.load_object()</code> function are the same as those of the
+interface types, prefixed with an underscore. For example, a
+<code>.load_object("_wpe_renderer_host_interface")</code> call must return a pointer to a
+<code>struct wpe_renderer_host_interface</code> object.</p>
+<details>
+ <summary>Example C code for a <code>load_object</code> callback.</summary>
+<!-- load_object example <<<1 -->
+<pre class="language-c"><code class="language-c"><span class="token keyword">static</span> <span class="token keyword">struct</span> <span class="token class-name">wpe_renderer_host_interface</span> <span class="token operator">=</span> <span class="token punctuation">{</span> <span class="token comment">/* ... */</span> <span class="token punctuation">}</span><span class="token punctuation">;</span>
+<span class="token keyword">static</span> <span class="token keyword">struct</span> <span class="token class-name">wpe_renderer_backend_egl_interface</span> <span class="token operator">=</span> <span class="token punctuation">{</span> <span class="token comment">/* ... */</span> <span class="token punctuation">}</span><span class="token punctuation">;</span>
+
+<span class="token keyword">static</span> <span class="token keyword">void</span><span class="token operator">*</span>
+<span class="token function">my_backend_load_object</span><span class="token punctuation">(</span><span class="token keyword">const</span> <span class="token keyword">char</span> <span class="token operator">*</span>name<span class="token punctuation">)</span>
+<span class="token punctuation">{</span>
+ <span class="token keyword">if</span> <span class="token punctuation">(</span><span class="token operator">!</span><span class="token function">strcmp</span><span class="token punctuation">(</span>name<span class="token punctuation">,</span> <span class="token string">"_wpe_renderer_host_interface"</span><span class="token punctuation">)</span><span class="token punctuation">)</span>
+ <span class="token keyword">return</span> <span class="token operator">&</span>my_renderer_host<span class="token punctuation">;</span>
+ <span class="token keyword">if</span> <span class="token punctuation">(</span><span class="token operator">!</span><span class="token function">strcmp</span><span class="token punctuation">(</span>name<span class="token punctuation">,</span> <span class="token string">"_wpe_renderer_backend_egl_interface"</span><span class="token punctuation">)</span><span class="token punctuation">)</span>
+ <span class="token keyword">return</span> <span class="token operator">&</span>my_renderer_backend_egl<span class="token punctuation">;</span>
+
+ <span class="token comment">/* ... */</span>
+
+ <span class="token keyword">return</span> <span class="token constant">NULL</span><span class="token punctuation">;</span>
+<span class="token punctuation">}</span>
+
+<span class="token keyword">struct</span> <span class="token class-name">wpe_loader_interface</span> _wpe_loader_interface <span class="token operator">=</span> <span class="token punctuation">{</span>
+ <span class="token punctuation">.</span>load_object <span class="token operator">=</span> my_backend_load_object<span class="token punctuation">,</span>
+<span class="token punctuation">}</span><span class="token punctuation">;</span></code></pre>
+<!-- 1>>> -->
+</details>
+<p>Each of these interfaces follow the same base structure: the <code>struct</code> members
+are callback functions, all interfaces have <code>create</code> and <code>destroy</code> members which
+act as instance constructor and destructor, plus any additional “methods”.
+The pointer returned by the <code>create</code> callback will be passed as the <code>object</code>
+“instance” of the other methods:</p>
+<pre class="language-c"><code class="language-c"><span class="token keyword">struct</span> <span class="token class-name">wpe_renderer_host_interface</span> <span class="token punctuation">{</span>
+ <span class="token keyword">void</span><span class="token operator">*</span> <span class="token punctuation">(</span><span class="token operator">*</span>create<span class="token punctuation">)</span><span class="token punctuation">(</span><span class="token keyword">void</span><span class="token punctuation">)</span><span class="token punctuation">;</span>
+ <span class="token keyword">void</span> <span class="token punctuation">(</span><span class="token operator">*</span>destroy<span class="token punctuation">)</span><span class="token punctuation">(</span><span class="token keyword">void</span> <span class="token operator">*</span>object<span class="token punctuation">)</span><span class="token punctuation">;</span>
+ <span class="token comment">/* ... */</span>
+<span class="token punctuation">}</span><span class="token punctuation">;</span></code></pre>
+<p>In the <strong>UI process</strong> side WPE WebKit will create:</p>
+<ul>
+<li>One “renderer host” instance, using <code>wpe_renderer_host_interface.create()</code>.</li>
+<li>Multiple “renderer host client” instances, using <code>wpe_renderer_host_interface.create_client()</code>.
+These are mainly used for IPC communication, one instance gets created for
+each web process launched by WebKit.</li>
+<li>Multiple “view backend” instances, using <code>wpe_view_backend_interface.create()</code>.
+One instance is created for each rendering target in the web process.</li>
+</ul>
+<p>In each <strong>web process</strong>—there can be more than one—WPE WebKit
+will create:</p>
+<ul>
+<li>One “renderer backend EGL” instance, using <code>wpe_renderer_backend_egl_interface.create()</code>.</li>
+<li>Multiple “renderer backend EGL target” instances, using
+<code>wpe_renderer_backend_egl_target_interface.create()</code>. An instance is created
+for each new rendering target needed by the application.</li>
+</ul>
+<details>
+ <summary>How about <code>wpe_renderer_backend_egl_offscreen_target_interface</code>?</summary>
+ <div>
+<p>The <code>rendererBackendEGLTarget</code> instances may be created by the <code>wpe_renderer_backend_egl_target_interface</code>, or
+the <code>wpe_renderer_backend_egl_offscreen_target_interface</code> depending on the interfaces implemented in the backend.</p>
+<p>Here we are only focusing on the <code>wpe_renderer_backend_egl_target_interface</code> that is relying on a classical EGL
+display (defined in the <code>rendererBackendEGL</code> instance). The <code>wpe_renderer_backend_egl_offscreen_target_interface</code> may
+be used in very specific use-cases that are out of the scope of this post. You can check its usage in the WPE WebKit
+<a href="https://github.com/WebKit/WebKit/blob/f32cd0f7cb7961420ce08ae78b8f01f287bec199/Source/WebCore/platform/graphics/egl/GLContextLibWPE.cpp#L61">source code</a>
+for more information.</p>
+ </div>
+</details>
+<p>These instances typically communicate with each others using Unix sockets for
+<abbr title="Inter-Process Communication">IPC</abbr>. The IPC layer must be
+implemented in the WPE backend itself because the <em>libwpe</em> interfaces only pass
+around the file descriptors to be used as communication endpoints.</p>
+<p>From a topological point of view, all those instances are organized as follows:</p>
+<figure>
+ <a href="https://wpewebkit.org/assets/svg/part1-basics.md-2.svg" target="_blank"><img src="https://wpewebkit.org/assets/svg/part1-basics.md-2.svg" />
+ </a>
+</figure>
+<p>From an usage point of view:</p>
+<ul>
+<li>The <code>rendererHost</code> and <code>rendererHostClient</code> instances are only used to manage
+IPC endpoints on the UI process side that are connected to each running
+web process. They are not used by the graphical rendering system.</li>
+<li>The <code>rendererBackendEGL</code> instance (one per web process) is only used to
+connect to the native display for a specific platform. For example, on a
+desktop Linux, the platform may be X11 where the native display would be the
+result of calling <code>XOpenDisplay()</code>; or the platform may be Wayland and in
+this case the native display would be the result of calling
+<code>wl_display_connect()</code>; and so on.</li>
+<li>The <code>rendererBackendEGLTarget</code> (on the web process side) and <code>viewBackend</code>
+(on the UI process side) instances are the ones truly managing the web page
+graphical rendering.</li>
+</ul>
+<h2 id="graphics-rendering" tabindex="-1">Graphics Rendering</h2>
+<p>As seen above, the interfaces in charge of the rendering are
+<code>wpe_renderer_backend_egl_target_interface</code> and <code>wpe_view_backend_interface</code>.
+During their creation, WPE WebKit exchanges the file descriptors used to
+establish a direct IPC connection between a <code>rendererBackendEGL</code> (in the
+web process), and a <code>viewBackend</code> (in the UI process).</p>
+<p>During the EGL initialization phase, when a new web process is launched, WebKit
+will use the native display and platform provided by the
+<code>wpe_renderer_backend_egl_interface.get_native_display()</code> and <code>.get_platform()</code>
+functions to create a suitable OpenGL ES context.</p>
+<p>When WebKit’s
+<a href="https://github.com/WebKit/WebKit/blob/c22f641da18b8c4eee23b8021b37aeec69268675/Source/WebKit/Shared/CoordinatedGraphics/threadedcompositor/ThreadedCompositor.cpp#L220">ThreadedCompositor</a>
+is ready to render a new frame (in the web process), it calls the
+<code>wpe_renderer_backend_egl_target_interface.frame_will_render()</code> function to let
+the WPE backend know that rendering is about to start. At this moment, the
+previously created OpenGL ES context is made current to be used as the target
+for GL drawing commands.</p>
+<p>Once the threaded compositor has finished drawing, it will swap the front and
+back EGL buffers and call the
+<code>wpe_renderer_backend_egl_target_interface.frame_rendered()</code> function to signal
+that the frame is ready. The compositor will then wait until the WPE backend
+calls <code>wpe_renderer_backend_egl_target_dispatch_frame_complete()</code> to indicate
+that the compositor may produce a new frame.</p>
+<p>What happens inside the <code>.frame_will_render()</code> and <code>.frame_rendered()</code>
+implementations is up to the WPE backend. As en example, it could
+set up a <a href="https://www.khronos.org/opengl/wiki/Framebuffer_Object">Frame Buffer Object</a>
+to have the web content draw offscreen, in a texture that can be passed
+back to the UI process for further processing, or use extensions like
+<a href="https://registry.khronos.org/EGL/extensions/KHR/EGL_KHR_stream.txt">EGLStream</a>,
+or <a href="https://registry.khronos.org/EGL/extensions/MESA/EGL_MESA_image_dma_buf_export.txt">DMA-BUF exports</a>
+to transfer the frame to the UI process without copying the pixel data.</p>
+<figure>
+ <a href="https://wpewebkit.org/assets/svg/part1-basics.md-3.svg" target="_blank"><img src="https://wpewebkit.org/assets/svg/part1-basics.md-3.svg" />
+ </a>
+</figure>
+<p>Typically the backend sends each new frame to the corresponding view backend in
+in its <code>.frame_rendered()</code> function. The application can use the frame until it
+sends back an <abbr>IPC</abbr> message to the renderer target (in the web
+process) to indicate that the frame is not in use anymore and may be be freed
+or recycled. Although it is not a requirement to do it at this exact point,
+usually when a renderer backend receives this message it calls the
+<code>wpe_renderer_backend_egl_target_dispatch_frame_complete()</code> function to trigger
+the rendering of a new frame. As a side effect, this mechanism also allows
+controlling the pace at which new frames are produced.</p>
+<h2 id="using-eglstream" tabindex="-1">Using EGLStream</h2>
+<p>EGLStream is an EGL extension that defines a mechanism to transfer hardware
+video buffers from one process to another efficiently, without getting them
+out of GPU memory. Although the extension is supported only in Nvidia
+hardware, it makes for a good example as it transparently handles some
+complexities involved, like buffers with multiple planes.</p>
+<p>This backend uses the EGLStream extension to transfer graphics buffers from the
+web process, which acts as a producer, to the UI process acting as a consumer.
+The producer extension
+<a href="https://registry.khronos.org/EGL/extensions/KHR/EGL_KHR_stream_producer_eglsurface.txt">EGL_KHR_stream_producer_eglsurface</a>
+allows creating a surface that may be used as target for rendering, then using
+<a href="https://registry.khronos.org/EGL/sdk/docs/man/html/eglSwapBuffers.xhtml">eglSwapBuffers()</a>
+finishes drawing and sends the result to the consumer. Meanwhile, in the
+consumer side, the
+<a href="https://registry.khronos.org/EGL/extensions/NV/EGL_NV_stream_consumer_eglimage.txt">EGL_NV_stream_consumer_eglimage</a>
+extension is used to turn each buffer into an <code>EGLImage</code>.</p>
+<p>The reference source code for this WPE backend is available in the
+<a href="https://github.com/Igalia/WPEBackend-offscreen-nvidia">WPEBackend-offscreen-nvidia</a>
+repository, which has been tested with WPE WebKit 2.38.x or 2.40.x, and
+<em>libwpe</em> version 1.14.x.</p>
+<details>
+ <summary>Behold, the Future Belongs to DMA-BUF!</summary>
+ <div>
+<p>With the growing adoption of
+<a href="https://docs.kernel.org/driver-api/dma-buf.html">DMA-BUF</a> for sharing memory
+buffers on modern Linux platforms, the WPE WebKit architecture will be
+evolving and, in the future, the need for a WPE Backend should disappear in
+most cases.</p>
+<p>Ongoing work on WPE WebKit removes the need to provide a WPE backend
+implementation for most hardware platforms, with a generic implementation
+using DMA-BUF provided as an integral, built-in feature of WebKit. It will
+still be possible to provide external implementations for platforms that
+might need to use custom buffer sharing mechanisms.</p>
+<p>From the application developer point of view, in most cases writing
+programs that use the WPE WebKit API will be simpler, with the complexity
+of the communication among multiple processes handled by WebKit.</p>
+ </div>
+</details>
+<h3 id="stream-setup" tabindex="-1">Stream Setup</h3>
+<p>The steps needed to set up EGLStream endpoints need to be done in a particular
+order:</p>
+<ol>
+<li>Create the consumer.</li>
+<li>Get the stream file descriptor for the consumer.</li>
+<li>Send the stream file descriptor to the producer.</li>
+<li>Create the producer.</li>
+</ol>
+<p><strong>First</strong>, the consumer needs to be created:</p>
+<pre class="language-cpp"><code class="language-cpp">EGLStream <span class="token function">createConsumerStream</span><span class="token punctuation">(</span>EGLDisplay eglDisplay<span class="token punctuation">)</span> <span class="token punctuation">{</span>
+ <span class="token keyword">static</span> <span class="token keyword">const</span> EGLint s_streamAttribs<span class="token punctuation">[</span><span class="token punctuation">]</span> <span class="token operator">=</span> <span class="token punctuation">{</span>
+ EGL_STREAM_FIFO_LENGTH_KHR<span class="token punctuation">,</span> <span class="token number">1</span><span class="token punctuation">,</span>
+ EGL_CONSUMER_ACQUIRE_TIMEOUT_USEC_KHR<span class="token punctuation">,</span> <span class="token number">1000</span> <span class="token operator">*</span> <span class="token number">1000</span><span class="token punctuation">,</span>
+ EGL_NONE
+ <span class="token punctuation">}</span><span class="token punctuation">;</span>
+ <span class="token keyword">return</span> <span class="token function">eglCreateStreamKHR</span><span class="token punctuation">(</span>eglDisplay<span class="token punctuation">,</span> s_streamAttribs<span class="token punctuation">)</span><span class="token punctuation">;</span>
+<span class="token punctuation">}</span></code></pre>
+<p>The <code>EGL_STREAM_FIFO_LENGTH_KHR</code> parameter defines the length of the EGLStream
+queue. If set to zero, the stream will work in “mailbox” mode and each time the
+producer has a new frame it will empty the stream content and replace the frame
+by the new one. If non-zero, the stream works work in “<abbr title="First-In,
+First-Out">FIFO</abbr>” mode, which means that the stream queue can contain up
+to <code>EGL_STREAM_FIFO_LENGTH_KHR</code> frames.</p>
+<p>Here we configure a queue for one frame because in this case the specification
+of <code>EGL_KHR_stream_producer_eglsurface</code> guarantees that calling
+<code>eglSwapBuffers()</code> on the producer the call will block until the consumer
+retires the previous frame from queue. This is used as implicit synchronization
+between the UI process side and the web process side without needing to rely on
+custom IPC, which would add a small delay between frames.</p>
+<p>The <code>EGL_CONSUMER_ACQUIRE_TIMEOUT_USEC_KHR</code> parameter defines the maximum
+timeout in microseconds to wait on the consumer side to acquire a frame when
+calling <code>eglStreamConsumerAcquireKHR()</code>. It is only used with the
+<code>EGL_KHR_stream_consumer_gltexture</code> extension because the
+<code>EGL_NV_stream_consumer_eglimage</code> extension allows setting a timeout on each
+call to <code>eglQueryStreamConsumerEventNV()</code> function.</p>
+<p><strong>Second</strong>, to initialize the consumer using the <code>EGL_NV_stream_consumer_eglimage</code>
+extension it is enough to call the <code>eglStreamImageConsumerConnectNV()</code> function.</p>
+<p><strong>Once the consumer has been initialized</strong>, you need to send the EGLStream
+file descriptor to the producer process. The usual way of achieving this would
+be using IPC between the two processes, sending the file descriptor in a
+<code>SCM_RIGHTS</code> message through an Unix socket—although with recent kernels
+using <a href="https://lwn.net/Articles/808997/">pidfd_getfd()</a> may be an option if
+both processes are related.</p>
+<p>When the file descriptor is <strong>finally</strong> received, the producer endpoint can be
+created using the <code>EGL_KHR_stream_producer_eglsurface</code> extension:</p>
+<pre class="language-cpp"><code class="language-cpp"><span class="token keyword">const</span> EGLint surfaceAttribs<span class="token punctuation">[</span><span class="token punctuation">]</span> <span class="token operator">=</span> <span class="token punctuation">{</span>
+ EGL_WIDTH<span class="token punctuation">,</span> width<span class="token punctuation">,</span>
+ EGL_HEIGHT<span class="token punctuation">,</span> height<span class="token punctuation">,</span>
+ EGL_NONE
+<span class="token punctuation">}</span><span class="token punctuation">;</span>
+EGLStream eglStream <span class="token operator">=</span> <span class="token function">eglCreateStreamFromFileDescriptorKHR</span><span class="token punctuation">(</span>eglDisplay<span class="token punctuation">,</span> consumerFD<span class="token punctuation">)</span><span class="token punctuation">;</span>
+EGLSurface eglSurface <span class="token operator">=</span> <span class="token function">eglCreateStreamProducerSurfaceKHR</span><span class="token punctuation">(</span>eglDisplay<span class="token punctuation">,</span> config<span class="token punctuation">,</span> eglStream<span class="token punctuation">,</span> surfaceAttribs<span class="token punctuation">)</span><span class="token punctuation">;</span></code></pre>
+<p>As with <abbr title="Pixel Buffer">pbuffer</abbr> surfaces, the dimensions
+need to be specified as surface attributes. When picking a frame buffer
+configuration with <code>eglChooseConfig()</code> the <code>EGL_SURFACE_TYPE</code> attribute must
+be set to <code>EGL_STREAM_BIT_KHR</code>. From this point onwards, rendering proceeds as
+usual: the EGL surface and context are made active, and once the painting is
+done a call to <code>eglSwapBuffers()</code> will “present” the frame, which in this case
+means sending the buffer with the pixel data down the EGLStream to the
+consumer.</p>
+<figure>
+ <a href="https://wpewebkit.org/assets/svg/part2-eglstream.md-1.svg" target="_blank"><img src="https://wpewebkit.org/assets/svg/part2-eglstream.md-1.svg" />
+ </a>
+</figure>
+<h3 id="consuming-frames" tabindex="-1">Consuming Frames</h3>
+<p>While on the producer side rendering treats the EGLStream surface like any
+other, on the consumer some more work is needed to manager the lifetime of
+the data received: frames have to be manually acquired and released once
+they are not needed anymore.</p>
+<p>The producer calls <code>eglQueryStreamConsumerEventNV()</code> repeatedly to retire the
+next event from the stream:</p>
+<ul>
+<li><code>EGL_STREAM_IMAGE_ADD_NV</code> indicates that there is a buffer in the stream
+that has not yet been bound to an <code>EGLImage</code>, and the application needs to
+create a new one to which the actual data will be bound later.</li>
+<li><code>EGL_STREAM_IMAGE_AVAILABLE_NV</code> indicates that a new frame is available
+and that it can be bound to the previously created <code>EGLImage</code>.</li>
+<li><code>EGL_STREAM_IMAGE_REMOVE_NV</code> indicates that a buffer has been retired from
+the stream, and that its associated <code>EGLImage</code> may be released once the
+application has finished using it.</li>
+</ul>
+<p>This translates roughly to the following code:</p>
+<pre class="language-cpp"><code class="language-cpp"><span class="token keyword">static</span> <span class="token keyword">constexpr</span> EGLTime MAX_TIMEOUT_USEC <span class="token operator">=</span> <span class="token number">1000</span> <span class="token operator">*</span> <span class="token number">1000</span><span class="token punctuation">;</span>
+EGLImage eglImage <span class="token operator">=</span> EGL_NO_IMAGE<span class="token punctuation">;</span>
+
+<span class="token keyword">while</span> <span class="token punctuation">(</span><span class="token boolean">true</span><span class="token punctuation">)</span> <span class="token punctuation">{</span>
+ EGLenum event <span class="token operator">=</span> <span class="token number">0</span><span class="token punctuation">;</span>
+ EGLAttrib data <span class="token operator">=</span> <span class="token number">0</span><span class="token punctuation">;</span>
+
+ <span class="token comment">// WARNING: The specification states that the timeout is in nanoseconds</span>
+ <span class="token comment">// (see: https://registry.khronos.org/EGL/extensions/NV/EGL_NV_stream_consumer_eglimage.txt)</span>
+ <span class="token comment">// but in reality it is in microseconds, at least with the version 535.113.01 of the NVidia drivers.</span>
+ <span class="token keyword">if</span> <span class="token punctuation">(</span><span class="token operator">!</span><span class="token function">eglQueryStreamConsumerEventNV</span><span class="token punctuation">(</span>display<span class="token punctuation">,</span> eglStream<span class="token punctuation">,</span> MAX_TIMEOUT_USEC<span class="token punctuation">,</span> <span class="token operator">&</span>event<span class="token punctuation">,</span> <span class="token operator">&</span>data<span class="token punctuation">)</span><span class="token punctuation">)</span>
+ <span class="token keyword">break</span><span class="token punctuation">;</span>
+
+ <span class="token keyword">switch</span> <span class="token punctuation">(</span>event<span class="token punctuation">)</span> <span class="token punctuation">{</span>
+ <span class="token keyword">case</span> EGL_STREAM_IMAGE_ADD_NV<span class="token operator">:</span> <span class="token comment">// Bind an incoming buffer to an EGLImage.</span>
+ <span class="token keyword">if</span> <span class="token punctuation">(</span>eglImage<span class="token punctuation">)</span> <span class="token function">eglDestroyImage</span><span class="token punctuation">(</span>display<span class="token punctuation">,</span> eglImage<span class="token punctuation">)</span><span class="token punctuation">;</span>
+ eglImage <span class="token operator">=</span> <span class="token function">eglCreateImage</span><span class="token punctuation">(</span>display<span class="token punctuation">,</span> EGL_NO_CONTEXT<span class="token punctuation">,</span> EGL_STREAM_CONSUMER_IMAGE_NV<span class="token punctuation">,</span>
+ <span class="token generic-function"><span class="token function">static_cast</span><span class="token generic class-name"><span class="token operator"><</span>EGLClientBuffer<span class="token operator">></span></span></span><span class="token punctuation">(</span>eglStream<span class="token punctuation">)</span><span class="token punctuation">,</span> <span class="token keyword">nullptr</span><span class="token punctuation">)</span><span class="token punctuation">;</span>
+ <span class="token keyword">continue</span><span class="token punctuation">;</span> <span class="token comment">// Handle the next event.</span>
+
+ <span class="token keyword">case</span> EGL_STREAM_IMAGE_REMOVE_NV<span class="token operator">:</span> <span class="token comment">// Buffer removed, EGLImage may be disposed.</span>
+ <span class="token keyword">if</span> <span class="token punctuation">(</span>data<span class="token punctuation">)</span> <span class="token punctuation">{</span>
+ EGLImage image <span class="token operator">=</span> <span class="token generic-function"><span class="token function">reinterpret_cast</span><span class="token generic class-name"><span class="token operator"><</span>EGLImage<span class="token operator">></span></span></span><span class="token punctuation">(</span>data<span class="token punctuation">)</span><span class="token punctuation">;</span>
+ <span class="token function">eglDestroyImage</span><span class="token punctuation">(</span>display<span class="token punctuation">,</span> image<span class="token punctuation">)</span><span class="token punctuation">;</span>
+ <span class="token keyword">if</span> <span class="token punctuation">(</span>image <span class="token operator">==</span> eglImage<span class="token punctuation">)</span>
+ eglImage <span class="token operator">=</span> EGL_NO_IMAGE<span class="token punctuation">;</span>
+ <span class="token punctuation">}</span>
+ <span class="token keyword">continue</span><span class="token punctuation">;</span> <span class="token comment">// Handle the next event.</span>
+
+ <span class="token keyword">case</span> EGL_STREAM_IMAGE_AVAILABLE_NV<span class="token operator">:</span> <span class="token comment">// New frame available.</span>
+ <span class="token keyword">if</span> <span class="token punctuation">(</span><span class="token function">eglStreamAcquireImageNV</span><span class="token punctuation">(</span>display<span class="token punctuation">,</span> eglStream<span class="token punctuation">,</span> <span class="token operator">&</span>eglImage<span class="token punctuation">,</span> EGL_NO_SYNC<span class="token punctuation">)</span><span class="token punctuation">)</span>
+ <span class="token keyword">break</span><span class="token punctuation">;</span>
+
+ <span class="token keyword">default</span><span class="token operator">:</span>
+ <span class="token keyword">continue</span><span class="token punctuation">;</span> <span class="token comment">// Handle the next event.</span>
+ <span class="token punctuation">}</span>
+
+ <span class="token comment">/*** Use the EGLImage here ***/</span>
+
+ <span class="token function">eglStreamReleaseImageNV</span><span class="token punctuation">(</span>display<span class="token punctuation">,</span> eglStream<span class="token punctuation">,</span> eglImage<span class="token punctuation">,</span> EGL_NO_SYNC<span class="token punctuation">)</span><span class="token punctuation">;</span>
+<span class="token punctuation">}</span></code></pre>
+<p>The application is free to use each <code>EGLImage</code> as it sees fit. An obvious
+example would be to use it as the contents for a texture, which then gets
+painted in the “content” area of a web browser; or as the contents of the
+screen for an in-game computer that the player can interact with, enabling
+display of real, live web content as part of the gaming experience—now
+<em>that</em> would be a deeply embedded browser!</p>
+<h3 id="one-last-thing" tabindex="-1">One Last Thing</h3>
+<p>There is a small showstopper to have EGLStream support working:
+<a href="https://github.com/WebKit/WebKit/blob/cb07c70c253a35b0e09e46e6100e1cdcebab26e2/Source/WebCore/platform/graphics/egl/GLContextEGL.cpp#L135">currently</a>
+when WPE WebKit uses surfaceless EGL contexts it sets the surface type to
+<code>EGL_WINDOW_BIT</code> attribute, while <code>EGL_STREAM_BIT_KHR</code> would be needed
+instead. <a href="https://github.com/Igalia/WPEBackend-offscreen-nvidia/blob/main/wpewebkit-patches/005-fix-surfaceless-egl-context-creation.patch">A small
+patch</a>
+is enough to apply this tweak:</p>
+<pre class="language-diff"><code class="language-diff">diff --git a/Source/WebCore/platform/graphics/egl/GLContextEGL.cpp b/Source/WebCore/platform/graphics/egl/GLContextEGL.cpp
+index d5efa070..5f200edc 100644
+<span class="token coord">--- a/Source/WebCore/platform/graphics/egl/GLContextEGL.cpp</span>
+<span class="token coord">+++ b/Source/WebCore/platform/graphics/egl/GLContextEGL.cpp</span>
+@@ -122,9 +122,11 @@ bool GLContextEGL::getEGLConfig(EGLDisplay display, EGLConfig* config, EGLSurfac
+<span class="token unchanged"><span class="token prefix unchanged"> </span><span class="token line"> attributeList[13] = EGL_PIXMAP_BIT;
+</span><span class="token prefix unchanged"> </span><span class="token line"> break;
+</span><span class="token prefix unchanged"> </span><span class="token line"> case GLContextEGL::WindowSurface:
+</span></span><span class="token deleted-sign deleted"><span class="token prefix deleted">-</span><span class="token line"> case GLContextEGL::Surfaceless:
+</span></span><span class="token unchanged"><span class="token prefix unchanged"> </span><span class="token line"> attributeList[13] = EGL_WINDOW_BIT;
+</span><span class="token prefix unchanged"> </span><span class="token line"> break;
+</span></span><span class="token inserted-sign inserted"><span class="token prefix inserted">+</span><span class="token line"> case GLContextEGL::Surfaceless:
+</span><span class="token prefix inserted">+</span><span class="token line"> attributeList[13] = EGL_STREAM_BIT_KHR;
+</span><span class="token prefix inserted">+</span><span class="token line"> break;
+</span></span><span class="token unchanged"><span class="token prefix unchanged"> </span><span class="token line"> }
+</span></span>
+<span class="token unchanged"><span class="token prefix unchanged"> </span><span class="token line"> EGLint count;
+</span></span></code></pre>
+<!-- vim:set foldmethod=marker foldmarker=<<<,>>>: -->
+
+
+
+
+ Integrating WPE: URI Scheme Handlers and Script Messages
+
+ 2023-03-07T00:00:00Z
+ https://wpewebkit.org/wpewebkit.org/aperezdc/learn-discover-rework/blog/06-integrating-wpe.html
+ <p>Most Web content is designed entirely for screen display—and there is <em>a
+lot</em> of it—so it will spend its life in the somewhat restricted sandbox
+implemented by a web browser. But rich user interfaces using Web technologies
+in all kinds of consumer devices require <em>some</em> degree of integration, an
+escape hatch to interact with the rest of their software and hardware. This is
+where a Web engine like WPE designed to be <em>embeddable</em> shines: not only does
+WPE provide a <a href="https://people.igalia.com/aperez/Documentation/wpe-webkit-1.1/">stable API</a>, it is also comprehensive in
+supporting a number of ways to <em>integrate</em> with its environment further than
+the plethora of available <a href="https://developer.mozilla.org/en-US/docs/Web/API">Web platform APIs</a>.</p>
+<p>Integrating a “Web view” (the main <a href="https://people.igalia.com/aperez/Documentation/wpe-webkit-1.1/class.WebView.html">entry point of the WPE embedding
+API</a>) involves providing extension points, which allow the
+Web content (HTML/CSS/JavaScript) it loads to call into native code provided
+by the client application (typically written in C/C++) from JavaScript, and
+vice versa. There are a number of ways in which this can be achieved:</p>
+<ul>
+<li><strong><a href="https://wpewebkit.org/wpewebkit.org/aperezdc/learn-discover-rework/blog/06-integrating-wpe.html#uri-scheme-handlers">URI scheme handlers</a></strong> allow native code to
+register a custom <abbr title="Uniform Resource Identifier">URI</abbr>
+scheme, which will run a user provided
+function to produce content that can be “fetched” regularly.</li>
+<li><strong><a href="https://wpewebkit.org/wpewebkit.org/aperezdc/learn-discover-rework/blog/06-integrating-wpe.html#user-script-messages">User script messaging</a></strong> can be used to send JSON
+messages from JavaScript running in the same context as Web pages to an user
+function, and vice versa.</li>
+<li>The <strong>JavaScriptCore API</strong> is a powerful solution to provide new JavaScript
+functionality to Web content seamlessly, almost as if they were implemented
+inside the Web engine itself—akin to <a href="https://nodejs.org/api/addons.html#c-addons">NodeJS C++ addons</a>.</li>
+</ul>
+<p>In this post we will explore the first two, as they can support many
+interesting use cases without introducing the additional complexity of
+extending the JavaScript virtual machine. Let’s dive in!</p>
+<h2 id="intermission" tabindex="-1">Intermission</h2>
+<p>We will be referring to the code of a tiny browser written for the occasion.
+Telling WebKit how to call our native code involves creating a
+<a href="https://people.igalia.com/aperez/Documentation/wpe-webkit-1.1/class.UserContentManager.html">WebKitUserContentManager</a>, customizing it, and then
+associating it with web views during their creation. The only exception to
+this are <a href="https://wpewebkit.org/wpewebkit.org/aperezdc/learn-discover-rework/blog/06-integrating-wpe.html#uri-scheme-handlers">URI scheme handlers</a>, which are registered
+using <a href="https://people.igalia.com/aperez/Documentation/wpe-webkit-1.1/method.WebContext.register_uri_scheme.html">webkit_web_context_register_uri_scheme()</a>. This
+minimal browser includes an <code>on_create_view</code> function, which is the perfect
+place to do the configuration:</p>
+<pre class="language-c"><code class="language-c"><span class="token keyword">static</span> WebKitWebView<span class="token operator">*</span>
+<span class="token function">on_create_view</span><span class="token punctuation">(</span>CogShell <span class="token operator">*</span>shell<span class="token punctuation">,</span> CogPlatform <span class="token operator">*</span>platform<span class="token punctuation">)</span>
+<span class="token punctuation">{</span>
+ <span class="token function">g_autoptr</span><span class="token punctuation">(</span>GError<span class="token punctuation">)</span> error <span class="token operator">=</span> <span class="token constant">NULL</span><span class="token punctuation">;</span>
+ WebKitWebViewBackend <span class="token operator">*</span>view_backend <span class="token operator">=</span> <span class="token function">cog_platform_get_view_backend</span><span class="token punctuation">(</span>platform<span class="token punctuation">,</span> <span class="token constant">NULL</span><span class="token punctuation">,</span> <span class="token operator">&</span>error<span class="token punctuation">)</span><span class="token punctuation">;</span>
+ <span class="token keyword">if</span> <span class="token punctuation">(</span><span class="token operator">!</span>view_backend<span class="token punctuation">)</span>
+ <span class="token function">g_error</span><span class="token punctuation">(</span><span class="token string">"Cannot obtain view backend: %s"</span><span class="token punctuation">,</span> error<span class="token operator">-></span>message<span class="token punctuation">)</span><span class="token punctuation">;</span>
+
+ <span class="token function">g_autoptr</span><span class="token punctuation">(</span>WebKitUserContentManager<span class="token punctuation">)</span> content_manager <span class="token operator">=</span> <span class="token function">create_content_manager</span><span class="token punctuation">(</span><span class="token punctuation">)</span><span class="token punctuation">;</span> <span class="token comment">/** NEW! **/</span>
+ <span class="token function">configure_web_context</span><span class="token punctuation">(</span><span class="token function">cog_shell_get_web_context</span><span class="token punctuation">(</span>shell<span class="token punctuation">)</span><span class="token punctuation">)</span><span class="token punctuation">;</span> <span class="token comment">/** NEW! **/</span>
+
+ <span class="token function">g_autoptr</span><span class="token punctuation">(</span>WebKitWebView<span class="token punctuation">)</span> web_view <span class="token operator">=</span>
+ <span class="token function">g_object_new</span><span class="token punctuation">(</span>WEBKIT_TYPE_WEB_VIEW<span class="token punctuation">,</span>
+ <span class="token string">"user-content-manager"</span><span class="token punctuation">,</span> content_manager<span class="token punctuation">,</span> <span class="token comment">/** NEW! **/</span>
+ <span class="token string">"settings"</span><span class="token punctuation">,</span> <span class="token function">cog_shell_get_web_settings</span><span class="token punctuation">(</span>shell<span class="token punctuation">)</span><span class="token punctuation">,</span>
+ <span class="token string">"web-context"</span><span class="token punctuation">,</span> <span class="token function">cog_shell_get_web_context</span><span class="token punctuation">(</span>shell<span class="token punctuation">)</span><span class="token punctuation">,</span>
+ <span class="token string">"backend"</span><span class="token punctuation">,</span> view_backend<span class="token punctuation">,</span>
+ <span class="token constant">NULL</span><span class="token punctuation">)</span><span class="token punctuation">;</span>
+ <span class="token function">cog_platform_init_web_view</span><span class="token punctuation">(</span>platform<span class="token punctuation">,</span> web_view<span class="token punctuation">)</span><span class="token punctuation">;</span>
+ <span class="token function">webkit_web_view_load_uri</span><span class="token punctuation">(</span>web_view<span class="token punctuation">,</span> s_starturl<span class="token punctuation">)</span><span class="token punctuation">;</span>
+ <span class="token keyword">return</span> <span class="token function">g_steal_pointer</span><span class="token punctuation">(</span><span class="token operator">&</span>web_view<span class="token punctuation">)</span><span class="token punctuation">;</span>
+<span class="token punctuation">}</span></code></pre>
+<details>
+ <summary>What is <code>g_autoptr</code>?
+ Does it relate to <code>g_steal_pointer</code>?
+ This does not look like C!</summary><div>
+<p>In the shown code examples, <code>g_autoptr(T)</code> is a preprocessor macro provided by
+GLib that declares a pointer variable of the <code>T</code> type, and arranges for
+freeing resources automatically when the variable goes out of scope. For
+objects this results in
+<a href="https://docs.gtk.org/gobject/method.Object.unref.html">g_object_unref()</a>
+being called.</p>
+<p>Internally the macro takes advantage of the <code>__attribute__((cleanup, ...))</code>
+compiler extension, which is supported by GCC and Clang. GLib also includes <a href="https://docs.gtk.org/glib/func.DEFINE_AUTOPTR_CLEANUP_FUNC.html">a
+convenience
+macro</a> that
+can be used to define cleanups for your own types.</p>
+<p>As for <code>g_steal_pointer</code>, it is useful to indicate that the ownership of a
+pointer declared with <code>g_autoptr</code> is transferred outside from the current
+scope. The function returns the same pointer passed as parameter and
+resets it to <code>NULL</code>, thus preventing cleanup functions from running.</p>
+</div></details>
+<p>The size has been kept small thanks to reusing code from the <a href="https://github.com/Igalia/cog#cog">Cog
+core</a> library. As a bonus, it should
+run on Wayland, X11, and even on a bare display using the <abbr title="Direct
+Rendering Manager">DRM<abbr>/<abbr title="Kernel Mode Setting">KMS</abbr>
+subsystem directly. Compiling and running it, assuming you already have the
+dependencies installed, should be as easy as running:</abbr></abbr></p>
+<pre class="language-sh"><code class="language-sh">cc <span class="token parameter variable">-o</span> minicog minicog.c <span class="token variable"><span class="token variable">$(</span>pkg-config cogcore <span class="token parameter variable">--libs</span> <span class="token parameter variable">--cflags</span><span class="token variable">)</span></span>
+./minicog wpewebkit.org</code></pre>
+<p>If the current session kind is not automatically detected, a second parameter
+can be used to manually choose among <code>wl</code> (Wayland), <code>x11</code>, <code>drm</code>, and so on:</p>
+<pre class="language-sh"><code class="language-sh">./minicog wpewebkit.org x11</code></pre>
+<p>The full, unmodified source for this minimal browser is included right below.</p>
+<details>
+ <summary>Complete <code>minicog.c</code> source
+ (<a target="_blank" rel="noopener" href="https://gist.github.com/aperezdc/f6a65a95f2baa222c0ce9d65e516e13b">Gist</a>)
+ </summary>
+<!-- minicog.c <<<1 -->
+<div>
+<pre><code class="language-c">
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * cc -o minicog minicog.c $(pkg-config wpe-webkit-1.1 cogcore --cflags --libs)
+ */
+
+#include <cog/cog.h>
+
+static const char *s_starturl = NULL;
+
+static WebKitWebView*
+on_create_view(CogShell *shell, CogPlatform *platform)
+{
+ g_autoptr(GError) error = NULL;
+ WebKitWebViewBackend *view_backend = cog_platform_get_view_backend(platform, NULL, &error);
+ if (!view_backend)
+ g_error("Cannot obtain view backend: %s", error->message);
+
+ g_autoptr(WebKitWebView) web_view =
+ g_object_new(WEBKIT_TYPE_WEB_VIEW,
+ "settings", cog_shell_get_web_settings(shell),
+ "web-context", cog_shell_get_web_context(shell),
+ "backend", view_backend,
+ NULL);
+ cog_platform_init_web_view(platform, web_view);
+ webkit_web_view_load_uri(web_view, s_starturl);
+ return g_steal_pointer(&web_view);
+}
+
+int
+main(int argc, char *argv[])
+{
+ g_set_application_name("minicog");
+
+ if (argc != 2 && argc != 3) {
+ g_printerr("Usage: %s [URL [platform]]\n", argv[0]);
+ return EXIT_FAILURE;
+ }
+
+ g_autoptr(GError) error = NULL;
+ if (!(s_starturl = cog_uri_guess_from_user_input(argv[1], TRUE, &error)))
+ g_error("Invalid URL '%s': %s", argv[1], error->message);
+
+ cog_modules_add_directory(COG_MODULEDIR);
+
+ g_autoptr(GApplication) app = g_application_new(NULL, G_APPLICATION_DEFAULT_FLAGS);
+ g_autoptr(CogShell) shell = cog_shell_new("minicog", FALSE);
+ g_autoptr(CogPlatform) platform =
+ cog_platform_new((argc == 3) ? argv[2] : g_getenv("COG_PLATFORM"), &error);
+ if (!platform)
+ g_error("Cannot create platform: %s", error->message);
+
+ if (!cog_platform_setup(platform, shell, "", &error))
+ g_error("Cannot setup platform: %s\n", error->message);
+
+ g_signal_connect(shell, "create-view", G_CALLBACK(on_create_view), platform);
+ g_signal_connect_swapped(app, "shutdown", G_CALLBACK(cog_shell_shutdown), shell);
+ g_signal_connect_swapped(app, "startup", G_CALLBACK(cog_shell_startup), shell);
+ g_signal_connect(app, "activate", G_CALLBACK(g_application_hold), NULL);
+
+ return g_application_run(app, 1, argv);
+}
+</code></pre>
+<!-- 1>>> -->
+</div>
+</details>
+<h2 id="uri-scheme-handlers" tabindex="-1">URI Scheme Handlers</h2>
+<figure>
+ <img src="https://wpewebkit.org/assets/svg/URI_syntax_diagram.svg" alt="“Railroad” diagram of URI syntax" />
+ <figcaption>URI syntax (<a target="_blank" rel="noopener" href="https://creativecommons.org/licenses/by-sa/4.0">CC BY-SA 4.0</a>,
+ <a target="_blank" rel="noopener" href="https://commons.wikimedia.org/wiki/File:URI_syntax_diagram.svg">source</a>),
+ notice the “scheme” component at the top left.
+ </figcaption>
+</figure>
+<p>A URI scheme handler allows “teaching” the web engine how to handle <em>any</em>
+load (pages, subresources, the <a href="https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API">Fetch API</a>,
+<code>XmlHttpRequest</code>, …)—if you ever wondered how Firefox implements
+<code>about:config</code> or how Chromium does <code>chrome://flags</code>, this is it. Also,
+WPE WebKit has public API for this. Roughly:</p>
+<ol>
+<li>A custom URI scheme is registered using
+<a href="https://people.igalia.com/aperez/Documentation/wpe-webkit-1.1/method.WebContext.register_uri_scheme.html">webkit_web_context_register_uri_scheme()</a>. This also associates a callback function to it.</li>
+<li>When WebKit detects a load for the scheme, it invokes the provided
+function, passing a
+<a href="https://people.igalia.com/aperez/Documentation/wpe-webkit-1.1/class.URISchemeRequest.html">WebKitURISchemeRequest</a>.</li>
+<li>The function generates data to be returned as the result of the load,
+as a <a href="https://docs.gtk.org/gio/class.InputStream.html">GInputStream</a>
+and calls <a href="https://people.igalia.com/aperez/Documentation/wpe-webkit-1.1/method.URISchemeRequest.finish.html">webkit_uri_scheme_request_finish()</a>. This sends the stream to WebKit as the
+response, indicating the length of the response (if known), and the
+MIME content type of the data in the stream.</li>
+<li>WebKit will now read the data from the input stream.</li>
+</ol>
+<h3 id="echoes" tabindex="-1">Echoes</h3>
+<p>Let’s add an echo handler to our <a href="https://wpewebkit.org/wpewebkit.org/aperezdc/learn-discover-rework/blog/06-integrating-wpe.html#intermission">minimal browser</a> that
+replies back with the requested URI. Registering the scheme is
+straightforward enough:</p>
+<pre class="language-c"><code class="language-c"><span class="token keyword">static</span> <span class="token keyword">void</span>
+<span class="token function">configure_web_context</span><span class="token punctuation">(</span>WebKitWebContext <span class="token operator">*</span>context<span class="token punctuation">)</span>
+<span class="token punctuation">{</span>
+ <span class="token function">webkit_web_context_register_uri_scheme</span><span class="token punctuation">(</span>context<span class="token punctuation">,</span>
+ <span class="token string">"echo"</span><span class="token punctuation">,</span>
+ handle_echo_request<span class="token punctuation">,</span>
+ <span class="token constant">NULL</span> <span class="token comment">/* userdata */</span><span class="token punctuation">,</span>
+ <span class="token constant">NULL</span> <span class="token comment">/* destroy_notify */</span><span class="token punctuation">)</span><span class="token punctuation">;</span>
+<span class="token punctuation">}</span></code></pre>
+<details>
+ <summary>What are “user data” and “destroy notify”?</summary><div>
+<p>The <code>userdata</code> parameter above is a convention used in many C libraries, and
+specially in these based on GLib when there are callback functions involved.
+It allows the <em>user</em> to supply a pointer to arbitrary <em>data</em>, which will be
+passed later on as a parameter to the callback (<code>handle_echo_request</code> in the
+example) when it gets invoked later on.</p>
+<p>As for the <code>destroy_notify</code> parameter, it allows passing a function with the
+signature <code>void func(void*)</code> (type
+<a href="https://docs.gtk.org/glib/callback.DestroyNotify.html">GDestroyNotify</a>) which
+is invoked with <code>userdata</code> as the argument once the user data is no longer
+needed. In the example above, this callback function would be invoked when the
+URI scheme is unregistered. Or, from a different perspective, this callback is
+used to <em>notify</em> that the user data can now be <em>destroyed</em>.</p>
+</div></details>
+<p>One way of implementing <code>handle_echo_request()</code> could be wrapping the request
+URI, which is part of the <code>WebKitURISchemeRequest</code> parameter to the handler,
+stash it into a <a href="https://docs.gtk.org/glib/struct.Bytes.html">GBytes</a>
+container, and <a href="https://docs.gtk.org/gio/ctor.MemoryInputStream.new_from_bytes.html">create an input stream to read back its
+contents</a>:</p>
+<pre class="language-c"><code class="language-c"><span class="token keyword">static</span> <span class="token keyword">void</span>
+<span class="token function">handle_echo_request</span><span class="token punctuation">(</span>WebKitURISchemeRequest <span class="token operator">*</span>request<span class="token punctuation">,</span> <span class="token keyword">void</span> <span class="token operator">*</span>userdata<span class="token punctuation">)</span>
+<span class="token punctuation">{</span>
+ <span class="token keyword">const</span> <span class="token keyword">char</span> <span class="token operator">*</span>request_uri <span class="token operator">=</span> <span class="token function">webkit_uri_scheme_request_get_uri</span><span class="token punctuation">(</span>request<span class="token punctuation">)</span><span class="token punctuation">;</span>
+ <span class="token function">g_print</span><span class="token punctuation">(</span><span class="token string">"Request URI: %s\n"</span><span class="token punctuation">,</span> request_uri<span class="token punctuation">)</span><span class="token punctuation">;</span>
+
+ <span class="token function">g_autoptr</span><span class="token punctuation">(</span>GBytes<span class="token punctuation">)</span> data <span class="token operator">=</span> <span class="token function">g_bytes_new</span><span class="token punctuation">(</span>request_uri<span class="token punctuation">,</span> <span class="token function">strlen</span><span class="token punctuation">(</span>request_uri<span class="token punctuation">)</span><span class="token punctuation">)</span><span class="token punctuation">;</span>
+ <span class="token function">g_autoptr</span><span class="token punctuation">(</span>GInputStream<span class="token punctuation">)</span> stream <span class="token operator">=</span> <span class="token function">g_memory_input_stream_new_from_bytes</span><span class="token punctuation">(</span>data<span class="token punctuation">)</span><span class="token punctuation">;</span>
+
+ <span class="token function">webkit_uri_scheme_request_finish</span><span class="token punctuation">(</span>request<span class="token punctuation">,</span> stream<span class="token punctuation">,</span> <span class="token function">g_bytes_get_size</span><span class="token punctuation">(</span>data<span class="token punctuation">)</span><span class="token punctuation">,</span> <span class="token string">"text/plain"</span><span class="token punctuation">)</span><span class="token punctuation">;</span>
+<span class="token punctuation">}</span></code></pre>
+<p>Note how we need to tell WebKit how to <a href="https://people.igalia.com/aperez/Documentation/wpe-webkit-1.1/method.URISchemeRequest.finish.html">finish the load
+request</a>,
+in this case only with the data stream, but it is possible to have <a href="https://people.igalia.com/aperez/Documentation/wpe-webkit-1.1/method.URISchemeRequest.finish_with_response.html">more
+control of the
+response</a>
+or <a href="https://people.igalia.com/aperez/Documentation/wpe-webkit-1.1/method.URISchemeRequest.finish_error.html">return an
+error</a>.</p>
+<p>With these changes, it is now possible to make page loads from the new custom
+URI scheme:</p>
+<figure>
+ <img alt="Screenshot of the minicog browser loading a custom echo:// URI" src="https://wpewebkit.org/assets/img/extending-minicog-echouri.png" class="picture" />
+ <figcaption>It worked!</figcaption>
+</figure>
+<h3 id="et-tu%2C-cors%3F" tabindex="-1">Et Tu, CORS?</h3>
+<p>The main roadblock one may find when using custom URI schemes is that loads
+are affected by <abbr title="Cross-Origin Resource Sharing">CORS</abbr>
+checks. Not only that, WebKit by default does <em>not</em> allow sending cross-origin
+requests to custom URI schemes. This is by design: instead of accidentally
+leaking potentially sensitive data to websites, developers embedding a web
+view <em>need</em> to consciously opt-in to allow <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS">CORS</a> requests <em>and</em>
+send back suitable <code>Access-Control-Allow-*</code> response headers.</p>
+<p>In practice, the additional setup involves
+<a href="https://people.igalia.com/aperez/Documentation/wpe-webkit-1.1/method.WebContext.get_security_manager.html">retrieving</a>
+the <code>WebKitSecurityManager</code> being used by the <code>WebKitWebContext</code> and
+<a href="https://people.igalia.com/aperez/Documentation/wpe-webkit-1.1/method.SecurityManager.register_uri_scheme_as_cors_enabled.html">registering the scheme as
+CORS-enabled</a>.
+Then, in the handler function for the custom URI scheme, create a
+<a href="https://people.igalia.com/aperez/Documentation/wpe-webkit-1.1/class.URISchemeResponse.html">WebKitURISchemeResponse</a>,
+which allows fine-grained control of the response, including setting
+<a href="https://libsoup.org/libsoup-3.0/struct.MessageHeaders.html">headers</a>,
+and finishing the request instead with
+<code>webkit_uri_scheme_request_finish_with_response()</code>.</p>
+<p>Note that WebKit cuts some corners when using CORS with custom URI schemes:
+handlers will <em>not</em> receive preflight <code>OPTIONS</code> requests. Instead, the CORS
+headers from the replies are inspected, and if access needs to be denied
+then the data stream with the response contents is discarded.</p>
+<p>In addition to providing a complete CORS-enabled custom URI scheme <a href="https://gist.github.com/aperezdc/74809a6cd617faf445c22097a47bcb50">example</a>,
+we recommend the <a href="https://httptoolkit.com/will-it-cors">Will It CORS?</a> tool
+to help troubleshoot issues.</p>
+<h3 id="further-ideas" tabindex="-1">Further Ideas</h3>
+<p>Once we have WPE WebKit calling into our custom code, there are no limits
+to what a URI scheme handler can do—as long as it involves replying
+to requests. Here are some ideas:</p>
+<ul>
+<li>Allow pages to access a subset of paths from the local file system in a
+controlled way (as <a href="https://wpewebkit.org/wpewebkit.org/aperezdc/learn-discover-rework/blog/06-integrating-wpe.html#et-tu%2C-cors%3F">CORS applies</a>). For inspiration,
+see <a href="https://igalia.github.io/cog/class.DirectoryFilesHandler.html">CogDirectoryFilesHandler</a>.</li>
+<li>Package all your web application assets into a single ZIP file, making
+loads from <code>app:/...</code> fetch content from it. Or, make the scheme handler
+load data using <a href="https://docs.gtk.org/gio/struct.Resource.html">GResource</a> and bundle the application
+inside your program.</li>
+<li>Use the presence of a well-known custom URI to have a web application
+realize that it is running on a certain device, and make its user
+interface adapt accordingly.</li>
+<li>Provide a REST API, which internally calls into
+<a href="https://networkmanager.dev/">NetworkManager</a> to list and configure
+wireless network adapters. Combine it with a local web application and
+embedded devices can now easily get on the network.</li>
+</ul>
+<h2 id="user-script-messages" tabindex="-1">User Script Messages</h2>
+<p>While <a href="https://wpewebkit.org/wpewebkit.org/aperezdc/learn-discover-rework/blog/06-integrating-wpe.html#uri-scheme-handlers">URI scheme handlers</a>
+allow streaming large chunks of data back into the Web engine, for exchanging
+smaller pieces of information in a more programmatic fashion it may be
+preferable to exchange messages without the need to trigger resource loads.
+The user script messages part of the
+<a href="https://people.igalia.com/aperez/Documentation/wpe-webkit-1.1/class.UserContentManager.html">WebKitUserContentManager</a> API can be used this way:</p>
+<ol>
+<li>Register a user message handler with
+<a href="https://people.igalia.com/aperez/Documentation/wpe-webkit-1.1/method.UserContentManager.register_script_message_handler.html">webkit_user_content_manager_register_script_message_handler()</a>.
+As opposed to URI scheme handlers, this only enables receiving messages,
+but does not associate a callback function <em>yet</em>.</li>
+<li>Associate a callback to the
+<a href="https://people.igalia.com/aperez/Documentation/wpe-webkit-1.1/signal.UserContentManager.script-message-received.html">script-message-received</a>
+signal. The signal detail should be the name of the registered handler.</li>
+<li>Now, whenever JavaScript code calls
+<code>window.webkit.messageHandlers.<name>.postMessage()</code>, the signal is
+emitted, and the native callback functions invoked.</li>
+</ol>
+<details>
+ <summary>Haven't I seen <code>postMessage()</code> elsewhere?</summary><div>
+<p><a href="https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage">Yes</a>,
+<a href="https://developer.mozilla.org/en-US/docs/Web/API/Worker/postMessage">you</a>
+<a href="https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorker/postMessage">have</a>.
+The name is the same because it provides a similar functionality (send a
+message), it guarantees little (the receiver should validate messages), and
+there are <a href="https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm">similar
+restrictions</a>
+in the kind of values that can be passed along.</p>
+</div></details>
+<h3 id="it%E2%80%99s-all-javascript" tabindex="-1">It’s All JavaScript</h3>
+<p>Let’s add a feature to our <a href="https://wpewebkit.org/wpewebkit.org/aperezdc/learn-discover-rework/blog/06-integrating-wpe.html#intermission">minimal browser</a> that will allow
+JavaScript code to trigger rebooting or powering off the device where it is
+running. While this should definitely <em>not</em> be functionality exposed to the
+open Web, it is perfectly acceptable in an embedded device where we control
+what gets loaded with WPE, and that exclusively uses a web application as its
+user interface.</p>
+<figure>
+ <img src="https://wpewebkit.org/assets/img/pepe-silvia-all-javascript.jpg" class="picture" alt="Pepe Silvia conspiracy image meme, with the text “It's all JavaScript” superimposed" />
+ <figcaption>Yet most of the code shown in this post is C.</figcaption>
+</figure>
+<p>First, create a <code>WebKitUserContentManager</code>, register the message handler,
+and connect a callback to its associated signal:</p>
+<pre class="language-c"><code class="language-c"><span class="token keyword">static</span> WebKitUserContentManager<span class="token operator">*</span>
+<span class="token function">create_content_manager</span><span class="token punctuation">(</span><span class="token keyword">void</span><span class="token punctuation">)</span>
+<span class="token punctuation">{</span>
+ <span class="token function">g_autoptr</span><span class="token punctuation">(</span>WebKitUserContentManager<span class="token punctuation">)</span> content_manager <span class="token operator">=</span> <span class="token function">webkit_user_content_manager_new</span><span class="token punctuation">(</span><span class="token punctuation">)</span><span class="token punctuation">;</span>
+ <span class="token function">webkit_user_content_manager_register_script_message_handler</span><span class="token punctuation">(</span>content_manager<span class="token punctuation">,</span> <span class="token string">"powerControl"</span><span class="token punctuation">)</span><span class="token punctuation">;</span>
+ <span class="token function">g_signal_connect</span><span class="token punctuation">(</span>content_manager<span class="token punctuation">,</span> <span class="token string">"script-message-received::powerControl"</span><span class="token punctuation">,</span>
+ <span class="token function">G_CALLBACK</span><span class="token punctuation">(</span>handle_power_control_message<span class="token punctuation">)</span><span class="token punctuation">,</span> <span class="token constant">NULL</span><span class="token punctuation">)</span><span class="token punctuation">;</span>
+ <span class="token keyword">return</span> <span class="token function">g_steal_pointer</span><span class="token punctuation">(</span><span class="token operator">&</span>content_manager<span class="token punctuation">)</span><span class="token punctuation">;</span>
+<span class="token punctuation">}</span></code></pre>
+<p>The callback receives a <a href="https://people.igalia.com/aperez/Documentation/wpe-webkit-1.1/struct.JavascriptResult.html">WebKitJavascriptResult</a>, from which we
+can get the <a href="https://people.igalia.com/aperez/Documentation/wpe-javascriptcore-1.1/class.Value.html">JSCValue</a> with the contents of the parameter
+passed to the <code>postMessage()</code> function. The <code>JSCValue</code> can now be inspected
+to check for malformed messages and determine the action to take, and
+then arrange to call <code>reboot()</code>:</p>
+<pre class="language-c"><code class="language-c"><span class="token keyword">static</span> <span class="token keyword">void</span>
+<span class="token function">handle_power_control_message</span><span class="token punctuation">(</span>WebKitUserContentManager <span class="token operator">*</span>content_manager<span class="token punctuation">,</span>
+ WebKitJavascriptResult <span class="token operator">*</span>js_result<span class="token punctuation">,</span> <span class="token keyword">void</span> <span class="token operator">*</span>userdata<span class="token punctuation">)</span>
+<span class="token punctuation">{</span>
+ JSCValue <span class="token operator">*</span>value <span class="token operator">=</span> <span class="token function">webkit_javascript_result_get_js_value</span><span class="token punctuation">(</span>js_result<span class="token punctuation">)</span><span class="token punctuation">;</span>
+ <span class="token keyword">if</span> <span class="token punctuation">(</span><span class="token operator">!</span><span class="token function">jsc_value_is_string</span><span class="token punctuation">(</span>value<span class="token punctuation">)</span><span class="token punctuation">)</span> <span class="token punctuation">{</span>
+ <span class="token function">g_warning</span><span class="token punctuation">(</span><span class="token string">"Invalid powerControl message: argument is not a string"</span><span class="token punctuation">)</span><span class="token punctuation">;</span>
+ <span class="token keyword">return</span><span class="token punctuation">;</span>
+ <span class="token punctuation">}</span>
+
+ g_autofree <span class="token keyword">char</span> <span class="token operator">*</span>value_as_string <span class="token operator">=</span> <span class="token function">jsc_value_to_string</span><span class="token punctuation">(</span>value<span class="token punctuation">)</span><span class="token punctuation">;</span>
+ <span class="token keyword">int</span> action<span class="token punctuation">;</span>
+ <span class="token keyword">if</span> <span class="token punctuation">(</span><span class="token function">strcmp</span><span class="token punctuation">(</span>value_as_string<span class="token punctuation">,</span> <span class="token string">"poweroff"</span><span class="token punctuation">)</span> <span class="token operator">==</span> <span class="token number">0</span><span class="token punctuation">)</span> <span class="token punctuation">{</span>
+ action <span class="token operator">=</span> RB_POWER_OFF<span class="token punctuation">;</span>
+ <span class="token punctuation">}</span> <span class="token keyword">else</span> <span class="token keyword">if</span> <span class="token punctuation">(</span><span class="token function">strcmp</span><span class="token punctuation">(</span>value_as_string<span class="token punctuation">,</span> <span class="token string">"reboot"</span><span class="token punctuation">)</span> <span class="token operator">==</span> <span class="token number">0</span><span class="token punctuation">)</span> <span class="token punctuation">{</span>
+ action <span class="token operator">=</span> RB_AUTOBOOT<span class="token punctuation">;</span>
+ <span class="token punctuation">}</span> <span class="token keyword">else</span> <span class="token punctuation">{</span>
+ <span class="token function">g_warning</span><span class="token punctuation">(</span><span class="token string">"Invalid powerControl message: '%s'"</span><span class="token punctuation">,</span> value_as_string<span class="token punctuation">)</span><span class="token punctuation">;</span>
+ <span class="token keyword">return</span><span class="token punctuation">;</span>
+ <span class="token punctuation">}</span>
+
+ <span class="token function">g_message</span><span class="token punctuation">(</span><span class="token string">"Device will %s now!"</span><span class="token punctuation">,</span> value_as_string<span class="token punctuation">)</span><span class="token punctuation">;</span>
+ <span class="token function">sync</span><span class="token punctuation">(</span><span class="token punctuation">)</span><span class="token punctuation">;</span> <span class="token function">reboot</span><span class="token punctuation">(</span>action<span class="token punctuation">)</span><span class="token punctuation">;</span>
+<span class="token punctuation">}</span></code></pre>
+<p>Note that the <code>reboot()</code> system call above will most likely fail because it
+needs administrative privileges. While the browser process could run as <code>root</code>
+to sidestep this issue—definitely <em>not</em> recommended!—it would be
+better to grant the <code>CAP_SYS_BOOT</code> capability to the process, and <em>much</em>
+better to ask the system manager daemon to handle the job. In machines
+using <a href="https://systemd.io/">systemd</a> a good option is to call the <code>.Halt()</code>
+and <code>.Reboot()</code> methods of its <code>org.freedesktop.systemd1</code> interface.</p>
+<p>Now we can write a small HTML document with some JavaScript sprinkled on top
+to arrange sending the messages:</p>
+<pre class="language-html"><code class="language-html"><span class="token tag"><span class="token tag"><span class="token punctuation"><</span>html</span><span class="token punctuation">></span></span>
+ <span class="token tag"><span class="token tag"><span class="token punctuation"><</span>head</span><span class="token punctuation">></span></span>
+ <span class="token tag"><span class="token tag"><span class="token punctuation"><</span>meta</span> <span class="token attr-name">charset</span><span class="token attr-value"><span class="token punctuation attr-equals">=</span><span class="token punctuation">"</span>utf-8<span class="token punctuation">"</span></span> <span class="token punctuation">/></span></span>
+ <span class="token tag"><span class="token tag"><span class="token punctuation"><</span>title</span><span class="token punctuation">></span></span>Device Power Control<span class="token tag"><span class="token tag"><span class="token punctuation"></</span>title</span><span class="token punctuation">></span></span>
+ <span class="token tag"><span class="token tag"><span class="token punctuation"></</span>head</span><span class="token punctuation">></span></span>
+ <span class="token tag"><span class="token tag"><span class="token punctuation"><</span>body</span><span class="token punctuation">></span></span>
+ <span class="token tag"><span class="token tag"><span class="token punctuation"><</span>button</span> <span class="token attr-name">id</span><span class="token attr-value"><span class="token punctuation attr-equals">=</span><span class="token punctuation">"</span>reboot<span class="token punctuation">"</span></span><span class="token punctuation">></span></span>Reboot<span class="token tag"><span class="token tag"><span class="token punctuation"></</span>button</span><span class="token punctuation">></span></span>
+ <span class="token tag"><span class="token tag"><span class="token punctuation"><</span>button</span> <span class="token attr-name">id</span><span class="token attr-value"><span class="token punctuation attr-equals">=</span><span class="token punctuation">"</span>poweroff<span class="token punctuation">"</span></span><span class="token punctuation">></span></span>Power Off<span class="token tag"><span class="token tag"><span class="token punctuation"></</span>button</span><span class="token punctuation">></span></span>
+ <span class="token tag"><span class="token tag"><span class="token punctuation"><</span>script</span> <span class="token attr-name">type</span><span class="token attr-value"><span class="token punctuation attr-equals">=</span><span class="token punctuation">"</span>text/javascript<span class="token punctuation">"</span></span><span class="token punctuation">></span></span><span class="token script"><span class="token language-javascript">
+ <span class="token keyword">function</span> <span class="token function">addHandler</span><span class="token punctuation">(</span><span class="token parameter">name</span><span class="token punctuation">)</span> <span class="token punctuation">{</span>
+ document<span class="token punctuation">.</span><span class="token function">getElementById</span><span class="token punctuation">(</span>name<span class="token punctuation">)</span><span class="token punctuation">.</span><span class="token function">addEventListener</span><span class="token punctuation">(</span><span class="token string">"click"</span><span class="token punctuation">,</span> <span class="token punctuation">(</span><span class="token parameter">event</span><span class="token punctuation">)</span> <span class="token operator">=></span> <span class="token punctuation">{</span>
+ window<span class="token punctuation">.</span>webkit<span class="token punctuation">.</span>messageHandlers<span class="token punctuation">.</span>powerControl<span class="token punctuation">.</span><span class="token function">postMessage</span><span class="token punctuation">(</span>name<span class="token punctuation">)</span><span class="token punctuation">;</span>
+ <span class="token keyword">return</span> <span class="token boolean">false</span><span class="token punctuation">;</span>
+ <span class="token punctuation">}</span><span class="token punctuation">)</span><span class="token punctuation">;</span>
+ <span class="token punctuation">}</span>
+ <span class="token function">addHandler</span><span class="token punctuation">(</span><span class="token string">"reboot"</span><span class="token punctuation">)</span><span class="token punctuation">;</span>
+ <span class="token function">addHandler</span><span class="token punctuation">(</span><span class="token string">"poweroff"</span><span class="token punctuation">)</span><span class="token punctuation">;</span>
+ </span></span><span class="token tag"><span class="token tag"><span class="token punctuation"></</span>script</span><span class="token punctuation">></span></span>
+ <span class="token tag"><span class="token tag"><span class="token punctuation"></</span>body</span><span class="token punctuation">></span></span>
+<span class="token tag"><span class="token tag"><span class="token punctuation"></</span>html</span><span class="token punctuation">></span></span></code></pre>
+<p>The complete source code for this example can be found
+<a href="https://gist.github.com/aperezdc/621c1ec6bb78923e27fc035fa0689522">in this Gist</a>.</p>
+<h3 id="going-in-the-other-direction" tabindex="-1">Going In The Other Direction</h3>
+<p>But how can one return values from user messages back to the JavaScript code
+running in the context of the web page? Until recently, the only option
+available was exposing some known function in the page’s JavaScript code, and
+then using
+<a href="https://people.igalia.com/aperez/Documentation/wpe-webkit-1.1/method.WebView.run_javascript.html">webkit_web_view_run_javascript()</a>
+to call it from native code later on. To make this more idiomatic and allow
+waiting on a <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise">Promise</a>, an approach like the following works:</p>
+<ol>
+<li>Have convenience JavaScript functions wrapping the calls to
+<code>.postMessage()</code> which add an unique identifier as part of the message,
+create a <code>Promise</code>, and store it in a <code>Map</code> indexed by the identifier.
+The <code>Promise</code> is itself returned from the functions.</li>
+<li>When the callback in native code handle messages, they need to take
+note of the message identifier, and then use
+<code>webkit_web_view_run_javascript()</code> to pass it back, along with the
+information needed to resolve the promise.</li>
+<li>The Javascript code running in the page takes the <code>Promise</code> from
+the <code>Map</code> that corresponds to the identifier, and resolves it.</li>
+</ol>
+<p>To make this approach a bit more palatable, we could tell WebKit to <a href="https://people.igalia.com/aperez/Documentation/wpe-webkit-1.1/method.UserContentManager.add_script.html">inject a
+script</a>
+along with the regular content, which would provide the <a href="https://gist.github.com/aperezdc/a112c6a61a5a11885eac2498702e3a6d">helper
+functions</a>
+needed to achieve this.</p>
+<p>Nevertheless, the approach outlined above is cumbersome and can be
+tricky to get right, not to mention that the effort needs to be duplicated in
+each application. Therefore, we have recently added new API hooks to provide this
+as a built-in feature, so starting in WPE WebKit 2.40 the recommended approach
+involves using
+<a href="https://people.igalia.com/aperez/Documentation/wpe-webkit-2.0/method.UserContentManager.register_script_message_handler_with_reply.html">webkit_user_content_manager_register_script_message_handler_with_reply()</a>
+to register handlers instead. This way, calling <code>.postMessage()</code> now returns a
+<code>Promise</code> to the JavaScript code, and the callbacks connected to the
+<a href="https://people.igalia.com/aperez/Documentation/wpe-webkit-2.0/signal.UserContentManager.script-message-with-reply-received.html">script-message-with-reply-received</a>
+signal now receive a
+<a href="https://people.igalia.com/aperez/Documentation/wpe-webkit-2.0/struct.ScriptMessageReply.html">WebKitScriptMessageReply</a>,
+which can be used to resolve the promise—either on the spot, or
+asynchronously later on.</p>
+<h3 id="even-more-ideas" tabindex="-1">Even More Ideas</h3>
+<p>User script messages are a powerful and rather flexible facility to make WPE
+integrate web content into a complete system. The provided example is rather
+simple, but as long as we do not need to pass huge amounts of data in
+messages the possibilities are almost endless—especially with the
+added convenience in WPE WebKit 2.40. Here are more ideas that can
+be built on top of user script messages:</p>
+<ul>
+<li>A handler could receive requests to “monitor” some object, and
+return a <code>Promise</code> that gets resolved when it has received changes.
+For example, this could make the user interface of a smart thermostat
+react to temperate updates from a sensor.</li>
+<li>A generic handler that takes the message payload and converts it into
+<a href="https://en.wikipedia.org/wiki/D-Bus">D-Bus</a> method calls, allowing
+web pages to control many aspects of a typical Linux system.</li>
+</ul>
+<h2 id="wrapping-up" tabindex="-1">Wrapping Up</h2>
+<p>WPE has been designed from the ground up to integrate with the rest of the
+system, instead of having a sole focus on rendering Web content inside a
+monolithic web browser application. Accordingly, the public API must be
+comprehensive enough to use it as a component of <em>any</em> application. This
+results in features that allow plugging into the web engine at different
+layers to provide custom behaviour.</p>
+<p>At Igalia we have years of experience embedding WebKit into all kinds of
+applications, and we are always sympathetic to the needs of such systems. If
+you are interested collaborating with WPE development, or searching for a
+solution that can tightly integrate web content in your device, feel free to
+<a href="https://www.igalia.com/contact/">contact us</a>.</p>
+<!-- vim:set foldmethod=marker foldmarker=<<<,>>>: -->
+
+
+
+
+ Status of the new SVG engine in WebKit
+
+ 2023-01-19T00:00:00Z
+ https://wpewebkit.org/wpewebkit.org/aperezdc/learn-discover-rework/blog/05-new-svg-engine.html
+ <style>
+figure {
+margin: 0;
+}
+
+figure > figure {
+ border: 1px #cccccc solid;
+ padding: 4px;
+}
+
+figcaption {
+ background-color: #cccccc;
+ color: black;
+ padding: 1px;
+ text-align: center;
+ margin-bottom: 4px;
+}
+</style>
+<p>In the <a href="https://wpewebkit.org/blog/04-wpe-networking-overview.html">previous posts of this series</a>, various aspects of the WPE port architecture were covered. Besides maintaining and advancing the WPE port according to our customers’ needs, Igalia also participates in the development of the <strong>WebCore</strong> engine itself, which is shared by <em>all</em> WebKit ports. WebCore is the part of the browser engine that does the heavy lifting: it contains all functionality necessary to load, parse, lay out, and paint Web content.</p>
+<p>Since late 2019, Igalia has been working on a new SVG engine, dubbed <strong>L</strong>ayer-<strong>B</strong>ased <strong>S</strong>VG <strong>E</strong>ngine (<strong>LBSE</strong>), that will unify the HTML/SVG rendering pipelines in WebCore. This will resolve long-standing design issues of the “legacy” SVG engine and unlock a bunch of new <em>exciting</em> possibilities for Web developers to get creative with SVG. <a href="https://blogs.igalia.com/nzimmermann/posts/2021-10-13-svg-performance/">Hardware-accelerated compositing</a>, driven by CSS <code>transform</code> animations, <a href="https://blogs.igalia.com/nzimmermann/posts/2019-12-12-3d-transformations/">3D perspective transformations</a> for arbitrary SVG elements, CSS <code>z-index</code> support for all SVG graphics elements, and proper coverage rectangle computations and repaints are just a few highlights of the capabilities the future SVG engine will offer.</p>
+<p>In this article, an overview is given about the problems that LBSE aims to solve, and the importance of a performant, well-integrated SVG engine <em>especially</em> for the embedded market. Finally, the current upstreaming status is summarized including an outlook for the year <strong>2023</strong>.</p>
+<h2 id="lbse-in-a-nutshell" tabindex="-1">LBSE in a nutshell</h2>
+<p>Before diving into the technical topics, let’s take a few minutes to recap the motivations behind the LBSE work, and explain the importance of a well-integrated, performant SVG engine in WebKit, <em>especially</em> for the embedded market.</p>
+<h3 id="motivation" tabindex="-1">Motivation</h3>
+<p>Many of our customers build products that utilize a Linux-powered embedded device, typically using non-x86 CPUs, custom displays with built-in input capabilities (e.g., capacitive touchscreens) often without large amounts of memory or even permanent storage. The software stack for these devices usually consists of a device-specific Linux distribution, containing the proprietary network, GPU, and drivers for the embedded device - the vendor-approved <em>“reference distribution”</em>.</p>
+<p>No matter what type of product is built nowadays, many of them need an active Internet connection, to e.g. update their software stack and access additional information. Besides the UI needed to control the product, a lot of additional dialogs, wizards and menus have to be provided to be able to alter the devices’ “system settings”, such as date/time information, time zones, display brightness, WiFi credentials, Bluetooth settings, and so on.</p>
+<p>A variety of toolkits exist that assist in writing GUI applications for embedded devices, with a few open-source projects on the market, as well as commercial products providing closed-source, proprietary solutions, that <em>specifically</em> target the embedded market and are often optimized for specific target device families, e.g. certain ARM processors / certain GPUs.</p>
+<p>If the need arises, not only to communicate with the Internet but also to display arbitrary Web content, WPE comes into play. As presented in the <a href="https://wpewebkit.org/blog/02-overview-of-wpe.html#how-does-wpe-integrate-with-webkit%3F">first post in this series</a>, the flexible and modular WPE architecture makes it an ideal choice for any product in the embedded market that needs Web browsing abilities. The <a href="https://docs.gtk.org/glib">GLib</a>/C-based <a href="https://people.igalia.com/aperez/Documentation/wpe-webkit-1.1">WPE public APIs</a> allow for customization of the browsing engine and its settings (react on page load/input events, inject custom JS objects, modify style sheets, etc.) and allow the embedder to control/monitor all relevant Web browsing-related activities.</p>
+<p>With a full-fledged Web engine at hand, one might ponder if it is feasible to replace the whole native GUI stack with a set of Web pages/applications, and only use WPE to paint the UI in full-screen mode, thus migrating away from native GUI applications — following the trend in the desktop market. The number of organizations migrating native GUI applications into Web applications is <em>rapidly</em> increasing, since there are compelling reasons for Web apps: “write once, use everywhere”, avoiding vendor lock-in, easy/reliable deployment and update mechanisms, and efficient test/development cycles (local in-browser testing!).</p>
+<p>Due to the sheer capabilities of the Web platform, it has grown to an environment in which any kind of application can be developed – ranging from video editing applications, big data processing pipelines to 3D games, all using JS/WebAssembly in a browser, presented using HTML5/CSS. And as an important bonus: in 2023, it’s much easier to find and attract talented Web developers and designers that are fluent in HTML/CSS/JS, than those that are comfortable designing UI applications in proprietary, closed-source C/C++ frameworks.</p>
+<p>A long-term customer, successfully using WPE in their products, had very similar thoughts and carried out a study, contracting external Web designers to build a complete UI prototype using Web technology. The mock-up made extensive use of SVG2, embedded inline into HTML5 documents or via other mechanisms (CSS <code>background-image</code>, etc.). The UI fulfilled all expectations and worked great in Blink and WebKit-based browsers, delivering smooth animations. On the target device, however, the performance was too slow, far away from usable. A thorough analysis revealed that large parts of the Web page were constantly repainted, and layout operations were repeated for every frame when animations were active. The accumulated time to display a new frame during animations was in the order of a few milliseconds on desktop machines, but took 20-25 milliseconds on the target device, making smooth 60 FPS animations <em>impossible</em>.</p>
+<p>The poor performance is not the result of shortcomings in the WPE port of WebKit: when replacing the aforementioned animated SVG document fragments with HTML/CSS “equivalents” (e.g. simulating SVG circles with CSS <code>border-radius</code> tricks) the performance issue vanisheed. Why? SVG lacks support for a key feature called <strong>accelerated compositing</strong>, which has been available for HTML/CSS since its introduction more than a decade ago. This compositing heavily relies on the <strong>Layer Tree</strong>, which is unaware of SVG. Extending the <strong>Layer Tree</strong> implementation to account for SVG is the <strong>main motivation for LBSE</strong>.</p>
+<p>If you are unfamiliar with the concepts of <strong>Render Tree</strong> and <strong>Layer Tree</strong>, you might want to read the <em>“Key concepts”</em> section of an earlier <a href="https://blogs.igalia.com/nzimmermann/posts/2021-10-29-layer-based-svg-engine/page/3/#key-concepts">LBSE design document</a>, which provides an overview of the topic.</p>
+<h3 id="prototyping" tabindex="-1">Prototyping</h3>
+<p>The LBSE effort began in October 2019 as <strong>a research project</strong>, to find out an ideal design for the SVG <strong>Render Tree</strong>, that allows SVG to re-use the existing <strong>Layer Tree</strong> implementation with minimal changes. The aim for LBSE is to share as much code as possible with the HTML/CSS implementation, removing the need for things like SVG specific clipping/masking/filter code and disjoint HTML counterparts for the same operations.</p>
+<p>After an extensive phase of experimentation, two abandoned approaches, and a long time spent on regression fixing, the LBSE prototype was finally finished after almost two years of work. It passed all 60k+ WebKit layout tests and offered initial support for compositing, 3D transformations, <code>z-index</code>, and more. The intent was to prove that we can reach feature parity with the legacy SVG engine and retrieve the very same visual results, pixel-by-pixel (except for progressions of LBSE). Shortly after the finalization, the prototype was presented during the <a href="https://blogs.igalia.com/nzimmermann/posts/2021-10-13-svg-performance/">WebKit contributors meeting in 2021</a>.</p>
+<p>As the name “prototype” indicates, LBSE was not ready for integration into WebKit at this point. It <strong>replaced</strong> the old SVG engine with a new one, resulting in a monolithic patch exceeding <em>650 KB</em> of code changes. External contributions generally demand small patches, with ChangeLogs, tests, etc. – no conscientious reviewer in any company would approve a patch replacing a core component of a browser engine in one shot. Splitting up into small pieces is also not going to work, since SVG needs to be kept intact upstream all the time. Duplicating the whole SVG engine? Not practicable either. With that problem in mind, a fruitful discussion took place with Apple during and after the WebKit contributors meeting: a realistic upstreaming strategy was defined - thanks <em>Simon Fraser</em> for suggesting a pragmatic approach!</p>
+<p>The idea is simple: bootstrap LBSE <em>in parallel</em> to the legacy SVG engine. Upstream LBSE behind a compile-time flag and additionally a runtime setting. This way the LBSE code is compiled by the <a href="https://trac.webkit.org/wiki/EarlyWarningSystem">EWS bots</a> during upstreaming (rules out bit-rot) and we gain the ability to turn LBSE on, selectively, from our layout tests – very useful during early bootstrapping. For WebKit, that strategy is the best – for LBSE another <em>major</em> effort is necessary: moving from a <strong>drop-in replacement</strong> approach to a <strong>dual-stack</strong> SVG engine: LBSE + legacy built into the same WebKit binaries. At least the timing was good since a split-up into small pieces was needed anyhow for upstreaming. Time to dissect the huge branch into logical, atomic pieces with proper change logs.</p>
+<p>Before we jump to the upstreaming status, one question should be answered, that came up during the WebKit contributors meeting and also during various discussions: why don’t you just <em>fix</em> the existing SVG engine and instead propose a new one - isn’t that too risky for Web compatibility?</p>
+<h3 id="why-don%E2%80%99t-you-fix-the-existing-svg-engine%3F" tabindex="-1">Why don’t you fix the existing SVG engine?</h3>
+<img style="float: right; width: 55%;" alt="LBSE logo" src="https://wpewebkit.org/assets/lbse-logo-wide.png" />
+<p>There was <em>no initial intention</em> to come up with a new SVG engine. During LBSE development it became apparent how much SVG-specific code can be erased when unifying certain aspects with HTML/CSS. After carrying out the integration work, layout/painting and hit-testing work fundamentally different than before. Since that time, LBSE is labeled as a <em>“new SVG engine”</em>, even though the SVG DOM tree part remained almost identical. Web compatibility will <em>improve</em> with LBSE: a few long-standing, critical interop issues with other browser vendors are solved in LBSE. Therefore, there are no concerns regarding Web compatibility risks from our side.</p>
+<p>To answer the initial question, whether it is possible to fix the existing SVG engine to add layer support without adding a “new” SVG engine in parallel? Short answer: <em>no</em>.</p>
+<p>In the following section, it is shown that adding support for layers implies changing the class hierarchy of the SVG render tree. All SVG renderers need to inherit from <code>RenderLayerModelObject</code> – a change like this cannot be split up easily into small, atomic pieces. Improving the design is difficult if there’s a requirement to keep the SVG engine working all the time upstream: all patches in that direction end up being large as many renderers have to be changed at the same time. Having distinct, LBSE-only implementations of SVG renderers, independent of the legacy engine, leaves a lot of freedom to strive for an optimal design, free of legacy constraints, and avoids huge patches that are <em>impossible</em> to review.</p>
+<p>Let’s close the introduction and review the upstreaming status, and discuss where we stand today.</p>
+<h2 id="upstreaming-progress" tabindex="-1">Upstreaming progress</h2>
+<h3 id="planning" tabindex="-1">Planning</h3>
+<p>To unify the HTML/CSS and SVG rendering pipelines there are two possible paths to choose from: teach the <strong>Layer Tree</strong> about the SVG <strong>Render Tree</strong> and its rendering model, or vice-versa. For the latter path, the HTML/CSS-specific <code>RenderLayer</code> needs to split into HTML/SVG subclasses and a base class, that is constructible from non-<code>RenderLayerModelObject</code>-derived renderers. The layer management code currently in <code>RenderLayerModelObject</code> would need to move into another place, and so forth. This <em>invasive</em> approach can potentially break lots of things. Besides that danger, many places in the layer/compositing system would need subtle changes to account for the specific needs of SVG (e.g. different coordinate system origin/convention).</p>
+<p>Therefore the former route was chosen, which requires transforming the SVG render tree class hierarchy, such that all renderers that need to manage layers derive from <strong><code>RenderLayerModelObject</code></strong>. Using this approach support, for SVG can be added to the layer/compositing system in a <em>non-invasive</em> manner, with only a minimum of SVG-specific changes. The following class hierarchy diagrams illustrate the planned changes.</p>
+<figure style="display: inline-block;">
+<figure style="margin-left: 0; margin-right: auto; display: inline-block; width: 48%;">
+<figcaption><a href="https://wpewebkit.org/assets/svg/svg_render_tree_legacy.svg" target="_blank">Legacy design (click to enlarge)</a></figcaption>
+<img alt="Visualization of the legacy SVG render tree class hierarchy in WebCore" src="https://wpewebkit.org/assets/svg/svg_render_tree_legacy.svg" />
+</figure>
+<figure style="margin-left: auto; margin-right: 0; display: inline-block; width: 48%">
+<figcaption><a href="https://wpewebkit.org/assets/svg/svg_render_tree_lbse.svg" target="_blank">LBSE design (click to enlarge)</a></figcaption>
+<img alt="Visualization of the LBSE SVG render tree class hierarchy in WebCore" src="https://wpewebkit.org/assets/svg/svg_render_tree_lbse.svg" />
+</figure>
+</figure>
+<p>The first graph shows the class hierarchy of the render tree in the legacy SVG engine: <code>RenderObject</code> is the base class for all nodes in the render tree. <code>RenderBoxModelObject</code> is the common base class for all HTML/CSS renderers. It inherits from <code>RenderLayerModelObject</code>, potentially allowing HTML renderers to create layers. For the SVG part of the render tree, there is no common base class shared by all the SVG renderers, for historical reasons.</p>
+<p>The second graph shows only the SVG renderers of the LBSE class hierarchy. In that design, all relevant SVG renderers may create/destroy/manage layers, via <code>RenderLayerModelObject</code>. More information regarding the challenges can be found in the earlier <a href="https://blogs.igalia.com/nzimmermann/posts/2021-10-29-layer-based-svg-engine/page/6/#legacy-class-hierarchy">LBSE design document</a>.</p>
+<h3 id="report" tabindex="-1">Report</h3>
+<p>The upstreaming work started in <strong>December 2021</strong>, with the introduction of a new layer-aware root renderer for the SVG render subtree: <code>RenderSVGRoot</code>. The existing <a href="https://trac.webkit.org/changeset/286392/webkit"><code>RenderSVGRoot</code> class was renamed to <code>LegacyRenderSVGRoot</code></a> (as well as any files, comments, etc.) and all call sites and build systems were adapted. Afterward, a stub implementation <a href="https://trac.webkit.org/changeset/286842/webkit">of a layer-aware <code>RenderSVGRoot</code> class was added</a> and assured that the <a href="https://trac.webkit.org/changeset/286846/webkit">new renderer is created for the corresponding SVG DOM element</a> if LBSE is activated.</p>
+<p>That process needs to be repeated for all SVG renderers that have substantially changed in LBSE and thus deserve an LBSE-specific upstream implementation. For all other cases, in-file <code>#if ENABLE(LAYER_BASED_SVG_ENGINE) ... #endif</code> blocks will be used to encapsulate LBSE-specific behavior. For example, <code>RenderSVGText</code> / <code>RenderSVGInlineText</code> are almost identical in LBSE downstream, compared to their legacy variants; thus, they are going to share the renderer implementation between the legacy SVG engine and LBSE.</p>
+<p>The multi-step procedure was repeated for <a href="https://trac.webkit.org/changeset/287538/webkit"><code>RenderSVGModelObject</code></a> (the base class for SVG graphics primitives), <a href="https://trac.webkit.org/changeset/287832/webkit"><code>RenderSVGShape</code></a>, <a href="https://trac.webkit.org/changeset/287834/webkit"><code>RenderSVGRect</code></a>, and <a href="https://trac.webkit.org/changeset/287921/webkit"><code>RenderSVGContainer</code></a>. Core functionality such as laying out children of a container, previously hidden in <a href="https://github.com/WebKit/WebKit/blob/main/Source/WebCore/rendering/svg/SVGRenderSupport.cpp#L241"><code>SVGRenderSupport::layoutChildren()</code></a> in the legacy SVG engine, now lives in a dedicated class: <a href="https://trac.webkit.org/changeset/288011/webkit"><code>SVGContainerLayout</code></a>. Computing the various SVG bounding boxes - <strong>object/stroke/decorated bounding box</strong> - is <a href="https://svgwg.org/svg2-draft/coords.html#BoundingBoxes">precisely specified in SVG2</a> and got a dedicated implementation as the <a href="https://trac.webkit.org/changeset/287873/webkit"><code>SVGBoundingBoxComputation</code></a> class, instead of fragmenting the algorithms all over the SVG render tree as in the legacy SVG engine.</p>
+<p>By <strong>February 2022</strong>, enough functionality was in place to construct the LBSE render tree for basic SVG documents, utilizing nested containers and rectangles as leaves. While this doesn’t sound exciting <em>at all</em>, it provided an ideal environment to implement support for SVG in the <code>RenderLayer</code>-related code - <strong>before</strong> converting all SVG renderers to LBSE, and <strong>before</strong> implementing painting in the SVG renderers.</p>
+<p>Both <code>RenderLayer</code> and <code>RenderLayerBacking</code> query CSS geometry information such as <strong>border box</strong>, <strong>padding box</strong>, or <strong>content box</strong> from their associated renderer, which is expected to be a <strong><code>RenderBox</code></strong> in many places. This is <em>incorrect</em> for SVG: <code>RenderSVGModelObject</code> inherits from <code>RenderLayerModelObject</code>, but not from <code>RenderBox</code> since it doesn’t adhere to the CSS box model. Various call sites cast the associated renderer to <code>RenderBox</code> to call e.g. <code>borderBoxRect()</code> to retrieve the border box rectangle. There are similar accessors in SVG to query the geometry, but there is no equivalent of a <strong>border box</strong> or other CSS concetps in SVG. Therefore, we extended <code>RenderSVGModelObject</code> to provide a <strong>CSS box model view</strong> of an SVG renderer, by offering methods such as <code>borderBoxRectEquivalent()</code> or <code>visualOverflowRectEquivalent()</code> that return geometry information in the same coordinate system using the same conventions as their HTML/CSS counterparts.</p>
+<p>We also refactored <code>RenderLayer</code> to use a proxy method - <code>rendererBorderBoxRect()</code> - <a href="https://trac.webkit.org/changeset/289210/webkit">that provides access</a> to the <code>borderBoxRect()</code> for HTML and the <code>borderBoxRectEquivalent()</code> for SVG renderers, and the same <a href="https://trac.webkit.org/changeset/289213/webkit">fix</a> to <code>RenderLayerBacking</code>. With these fixes in place, support to <a href="https://wpewebkit.org/wpewebkit.org/aperezdc/learn-discover-rework/blog/%3Ehttps://trac.webkit.org/changeset/289207/webkit">position and size SVG layers</a> and to <a href="https://trac.webkit.org/changeset/289204/webkit">compute overflow information</a> could be added – <em>both</em> pre-conditions to enable painting.</p>
+<p>By <strong>March 2022</strong>, LBSE <a href="https://trac.webkit.org/changeset/290324/webkit">was able to paint basic SVG documents</a> - a major milestone for the bootstrapping process, demonstrating that the layer painting code was functional for SVG. It was time to move on to <em>transformations</em>: implementing <a href="https://trac.webkit.org/changeset/290880/webkit"><code>RenderSVGTransformableContainer</code></a> (e.g. <code><g></code> elements with a non-identity <code>transform</code> attribute or CSS <code>transform</code> property) and CSS/SVG <code>transform</code> support for all other graphics primitives, utilizing the <code>RenderLayer</code>-based <strong>CSS Transform</strong> implementation. As preparation, the existing code was reviewed and <a href="https://trac.webkit.org/changeset/291338/webkit">cleaned up</a>: <code>transform-origin</code> computation <a href="https://trac.webkit.org/changeset/291338/webkit">was decoupled</a> from CTM computation (CTM = current transformation matrix, see <a href="https://www.w3.org/TR/css-transforms-1/#current-transformation-matrix">CSS Transforms Module Level 1</a>) and <code>transform-box</code> computations <a href="https://trac.webkit.org/changeset/292525/webkit">were unified in a single place</a>.</p>
+<p>In <strong>April 2022</strong>, <strong>2D transforms</strong> <a href="https://trac.webkit.org/changeset/292706/webkit">were enabled</a> and became <a href="https://trac.webkit.org/changeset/293504/webkit">fully functional</a> a few weeks later. Besides missing <em>compositing support</em> upstream, downstream work showed that enabling 3D transforms for SVG required <a href="https://trac.webkit.org/changeset/294615/webkit">fixing a decade-old bug</a> that made the computed <code>perspective</code> transformation dependent on the choice of <code>transform-origin</code>. That became apparent when testing the layer code with SVG, which uses different default values for certain transform-related CSS properties than HTML does: <code>transform-box: view-box</code> and <code>transform-origin: 0 0</code> are the relevant defaults for SVG, referring to the top-left corner of nearest SVG viewport vs. the center of the element in HTML.</p>
+<p>By <strong>May 2022</strong>, the legacy SVG text rendering code was <a href="https://trac.webkit.org/changeset/294385/webkit">altered to be usable for LBSE as well</a>. At this point, it made sense to run layout tests using LBSE. Previously most tests were expected to fail, as most either utilize text, paths, or shapes, and sometimes all three together. LBSE render tree text dumps (dumping the parsed render tree structure in a text file) were added for all tests in the <code>LayoutTests/svg</code> subdirectory, as well as a new pixel test baseline (screenshots of the rendering as PNGs), generated using the legacy SVG engine, to verify that LBSE produces pixel-accurate results. All upcoming LBSE patches are expected to <em>change</em> the expected layout test result baseline, and/or the <code>TestExpectations</code> file, depending on the type of patch. This will ease the reviewing process a lot for future patches.</p>
+<p>To further proceed, a <strong>test-driven approach</strong> was used to prioritize the implementation of the missing functionality. At that time, missing <code>viewBox</code> support for outer <svg> elements was causing many broken tests. The effect of the transformation induced by the <strong>viewBox</strong> attribute, specified on outer <svg> elements, cannot be implemented as an additional CSS transformation applied to the outermost <svg> element, as that would affect the painted dimensions of the SVG document, which are subject to the CSS <code>width</code>/<code>height</code> properties and the size negotiation logic only. The <code>viewBox</code> attribute is supposed to only affect the visual appearance of the descendants, by establishing a new local coordinate system for them. The legacy SVG engine manually handled the <code>viewBox</code>-induced transformation in various places throughout <code>LegacyRenderSVGRoot</code>, to only affect the painting of the descendants and not e.g. the position/dimension of the border surrounding the <svg>, if the CSS <code>border</code> property is specified. In LBSE, transformations are handled on <code>RenderLayer</code>-level and not in the renderers anymore.</p>
+<p>By <strong>July 2022</strong>, after testing different approaches, a proper solution <a href="https://commits.webkit.org/252643@main">to add <code>viewBox</code> support was upstreamed</a>. The chosen solution makes use of another CSS concept that arises in the context of generated content: <em>“anonymous boxes”</em>. The idea is to wrap the direct descendants of <code>RenderSVGRoot</code> in an anonymous <code>RenderSVGViewportContainer</code> (“anonymous” = no associated DOM element) and apply the <code>viewBox</code> transformation as a regular CSS transformation on the anonymous renderer. With that approach, LBSE is left with just a <em>single, unified</em> <code>viewBox</code> implementation, without error-prone special cases in <code>RenderSVGRoot</code>, unlike the legacy SVG engine which has two disjoint implementations in <code>LegacyRenderSVGViewportContainer</code> and <code>LegacyRenderSVGRoot</code>.</p>
+<p>After the summer holidays, in <strong>August 2022</strong>, the next major milestone was reached: <a href="https://bugs.webkit.org/show_bug.cgi?id=242833">enabling compositing support for arbitrary SVG elements</a>, bringing <strong>z-index</strong> support, <strong>hardware-accelerated compositing</strong> and <strong>3D transforms</strong> to SVG. This time <em>all lessons</em> learned from the previous LBSE prototypes were taken into account, resulting in a <em>complete</em> compositing implementation, that works in various scenarios: different <code>transform-box</code> / <code>transform-origin</code> combinations, inline SVG enclosed by absolute/relative positioned CSS boxes and many more, all way more polished than in the “final” LBSE prototype.</p>
+<p>The aforementioned patch contained a fix for a <a href="https://webkit.org/b/27684">long-standing bug</a> (<em>“Composited elements appear pixelated when scaled up using transform”</em>), that made composited elements look blurry when scaling up with a CSS <code>transform</code> animation. The so-called <em>“backing scale factor”</em> of the associated <code>GraphicLayers</code> (see <a href="https://wpewebkit.org/blog/03-wpe-graphics-architecture.html">here for details</a> about the role of <code>GraphicLayer</code> in the compositing system) never changes during the animation. Therefore, the rendered image was scaled up instead of re-rendering the content at the right scale. LBSE now enforces updates of that scale factor, to avoid blurry SVGs. The fix is <em>not</em> activated yet for HTML as that requires more thought - see the previously-linked bug report for details.</p>
+<p>With all the new features in place and covered by tests, it was time to finish the remaining SVG renderers: <a href="https://commits.webkit.org/250913@main">RenderSVGEllipse</a>, <a href="https://commits.webkit.org/251688@main">RenderSVGPath</a> and <a href="https://commits.webkit.org/252500@main">RenderSVGViewportContainer</a> (for inner <svg> elements), <a href="https://commits.webkit.org/253510@main">RenderSVGHiddenContainer</a>, <a href="https://commits.webkit.org/253793@main">RenderSVGImage</a>, and <a href="https://commits.webkit.org/253816@main">RenderSVGForeignObject</a>. A proper <foreignObject> implementation was lacking in WebKit for 15+ years, due to the fundamental problem that the layer tree was not aware of the SVG subtree. The LBSE variant of <code>RenderSVGForeignObject</code> looks trivial, yet offers a fully compatible <strong><foreignObject> implementation</strong> - for the first time without issues with non-static positioned content as a direct child of <foreignObject>, at least a few weeks later after <a href="https://commits.webkit.org/256960@main">it landed</a>.</p>
+<p>Returning to the test-driven approach, the next best target to fix was text rendering, which was working but not pixel-perfect. The legacy SVG engine takes into account the transformation from the text element up to the topmost renderer when computing the effective “on-screen” font size used to select a font for drawing/measuring, during <em>layout</em> time. LBSE needed a way to calculate the CTM for a given SVG renderer, up to a given ancestor renderer (or root), taking into account all possible transformation scenarios, including CSS <code>transform</code>, <code>translate</code>, <code>rotate</code>, SVG <code>transform</code> attribute, shifts due to <code>transform-origin</code>, perspective transformations, and much more. The <em>same functionality</em> is required to implement <code>getCTM()</code> / <code>getScreenCTM()</code>.</p>
+<p>By the end of <strong>August 2022</strong>, <a href="https://commits.webkit.org/253938@main"><code>SVGLayerTransformComputation</code> was added</a> that re-used the existing <code>mapLocalToContainer()</code> / <code>TranformState</code> API to obtain the CTM. The CTM construction and ancestor chain walk - to accumulate the final transformation matrix - is performed by <code>mapLocalToContainer()</code> and no longer needs a special, <em>incomplete</em> SVG approach: the existing general approach now works for SVG too.</p>
+<p><strong>September 2022</strong> was mostly devoted to bug fixes related to <strong>pixel-snapping</strong>. Outermost <svg> elements <a href="https://commits.webkit.org/254314@main">were not always enforcing stacking contexts</a> and <a href="https://commits.webkit.org/254558@main">failed to align to device pixels</a>. All other elements behaved fine with respect to pixel snapping (<em>not</em> applied for SVG elements) unless compositing layers were active. In that case, a <code>RenderLayerBacking</code> code path was used that unconditionally applied pixel-snapping - <a href="https://commits.webkit.org/254863@main">avoid that for SVG</a>.</p>
+<p>By <strong>October 2022</strong> LBSE could <a href="https://commits.webkit.org/255291@main">properly display</a> SVGs embedded into HTML host documents via <object> elements – the size negotiation logic failed to take into account the LBSE-specific renderers before. CSS <code>background-image</code> / <code>list-image</code> / HTML <img> / etc. <a href="https://commits.webkit.org/255625@main">were fixed as well</a>. Zooming and panning support were <a href="https://commits.webkit.org/255727@main">implemented and improved compared to the legacy engine</a>. Along the way an important bug was fixed, one that other browsers had already fixed back in 2014. The bug caused percentage-sized documents (e.g. <code>width: 100%; height: 100%</code>) that also specify a <code>viewBox</code> to always keep the document size, regardless of the zoom level. Thus, upon zooming, only the stroke width enlarged, but not the boundaries of the document, and thus scrollbars never appeared.</p>
+<p>Over the following weeks, text-related issues had to be fixed, which were responsible for a bunch of the remaining test issues. Transformed text did not render, which turned out to be a simple <a href="https://commits.webkit.org/255801@main">mistake</a>. More tests were upstreamed, related to <a href="https://commits.webkit.org/256502@main">compositing</a> and <a href="https://commits.webkit.org/256948@main">transformations</a>. More test coverage revealed that transform changes were not handled consistently – it took a period of investigation to <a href="https://commits.webkit.org/256787@main">land a proper fix</a>. SVG transform / SMIL <animateMotion> / SMIL <animateTransform> / CSS transform changes are now handled consistently in LBSE, leading to proper repaints, as expected.</p>
+<p>Transformation support can be considered complete and properly handled both during the painting and layout phases. Dynamic changes at runtime are correctly triggering invalidations. However, the Web-exposed <strong>SVG DOM API</strong> that allows querying the transformation matrices of SVG elements, such as <code>getCTM()</code> and <code>getScreenCTM()</code>, was still missing. By <strong>November 2022</strong> a complete implementation <a href="https://commits.webkit.org/256862@main">was upstreamed</a>, that utilized the new <code>SVGLayerTransformComputation</code> class to construct the desired transformation matrices. This way the same internal API is used for painting/layout/hit-testing and implementing the <strong>SVG DOM accessors</strong>.</p>
+<p>By <strong>December 2022</strong> LBSE was in a good shape: most important architectural changes were upstreamed and the most basic features were implemented. The year closed with a proposed <a href="https://github.com/WebKit/WebKit/pull/7482">patch</a> that will avoid re-layout when an element’s transform changes. The legacy SVG engine always needs a re-layout if transform changes, as the size of each ancestor can depend on the presence of transformations on the child elements – a bad design decision two decades ago that LBSE will resolve. Only repainting should happen, but no layouts, in LBSE.</p>
+<p>Let’s move on to 2023, and recap what’s still missing in LBSE.</p>
+<h3 id="next-steps" tabindex="-1">Next steps</h3>
+<p>Besides fixing all remaining test regressions (see <a href="https://github.com/WebKit/WebKit/blob/main/LayoutTests/platform/mac-ventura-wk2-lbse-text/TestExpectations"><code>LayoutTests/platform/mac-ventura-wk2-lbse-text/TestExpectations</code></a>) “SVG resources” are missing in LBSE. That includes all “paint servers” and advanced painting operations: there is no support for linear/radial gradients, no support for patterns, and no support for clipping/masking and filters.</p>
+<p>From the painting capabilities, LBSE is still in a <em>basic shape</em>. However, this was intentional, since a lot of the existing code for SVG resource handling is <em>no longer needed</em> in LBSE. Clipping/masking and filters will be handled via <code>RenderLayer</code>, reusing the existing HTML/CSS implementations. Temporary <code>ImageBuffers</code> are no longer needed for clipping, and thus there is no need to cache the “per client” state in the resource system (e.g. re-using the cached clipping mask for repainting). This will simplify the implementation of the “SVG resources” a lot.</p>
+<p>Therefore the first task in 2023 is to implement clipping, then masking, gradients, patterns, and as the last item, filters, since they require a substantial amount of refactoring in <code>RenderLayerFilters</code>.
+Note that these implementations are already complete in LBSE downstream and do not need to be invented from scratch. The first patches in that direction should be up for review by <strong>February 2023</strong>.</p>
+<p>After all “SVG resources” are implemented in LBSE, feature parity is almost there and performance work will follow afterward. WebKit has a golden rule to never ship a performance regression; therefore, LBSE needs to be at least as fast in the standard performance tests, such as <em>MotionMark</em>, before it can replace the legacy engine. Currently, LBSE is <em>slower than the legacy engine</em> with respect to static rendering performance. Quoting numbers does not help at present, since the problem is well understood and will be resolved in the following months.</p>
+<p>LBSE currently creates more <code>RenderLayer</code> objects than necessary: for each renderer, unconditionally. This is a great stress test of the layer system, and helpful for bootstrapping, but the associated overhead and complexity are simply not necessary for many cases, and actively hurt performance. LBSE already outperforms the legacy SVG engine whenever animated content is viewed, if it benefits from the <em>hardware acceleration</em> in LBSE.</p>
+<p>2023 will be an exciting year, and hopefully brings LBSE to the masses, stay tuned!</p>
+<h2 id="demos" tabindex="-1">Demos</h2>
+<p>“A picture is worth a thousand words”, so we’d like to share with you the videos shown during the <strong>WebKit contributors meeting in 2022</strong> that demo the LBSE capabilities. Be sure to check them out so you can get a good picture of the state of the work. Enjoy!</p>
+<ol>
+<li>
+<p><a href="https://cloud.igalia.com/s/fXjsXmqQocxF5P7/download/01-demo-tiger-2d.mp4">Accelerated 2D transforms (Tiger)</a></p>
+<p style="text-align: center">
+ <video width="800" height="600" controls=""><source src="https://cloud.igalia.com/s/fXjsXmqQocxF5P7/download/01-demo-tiger-2d.mp4" /></video>
+</p>
+</li>
+<li>
+<p><a href="https://cloud.igalia.com/s/FDx9koYej65wcFb/download/02-demo-tiger-3d.mp4">Accelerated 3D transform (Tiger)</a></p>
+<p style="text-align: center">
+ <video width="800" height="600" controls=""><source src="https://cloud.igalia.com/s/FDx9koYej65wcFb/download/02-demo-tiger-3d.mp4" /></video>
+</p>
+</li>
+<li>
+<p><a href="https://cloud.igalia.com/s/zyAAwLWRaFQMatL/download/03-demo-tiger-transition-storm.mp4">Transition storm (Tiger)</a></p>
+<p style="text-align: center">
+ <video width="800" height="600" controls=""><source src="https://cloud.igalia.com/s/zyAAwLWRaFQMatL/download/03-demo-tiger-transition-storm.mp4" /></video>
+</p>
+</li>
+<li>
+<p><a href="https://cloud.igalia.com/s/e2ZfqWpnT44awEZ/download/04-demo-vibrant.mp4">Vibrant example</a></p>
+<p style="text-align: center">
+ <video width="800" height="600" controls=""><source src="https://cloud.igalia.com/s/e2ZfqWpnT44awEZ/download/04-demo-vibrant.mp4" /></video>
+</p>
+</li>
+</ol>
+<h2 id="final-thoughts" tabindex="-1">Final thoughts</h2>
+<p>We at Igalia are doing our best to fulfill the mission and complete the LBSE upstreaming as fast as possible. In the meanwhile, let us know about <em>your</em> thoughts:</p>
+<ul>
+<li>What would you do with a performant, next-level SVG engine?</li>
+<li>Any particular desktop / embedded project that would benefit from it?</li>
+<li>Anything in reach now, that seemed impossible before with the given constraints in WebKit?</li>
+</ul>
+<p>Thanks for your attention! Be sure to keep an eye on <a href="https://github.com/nikolaszimmermann/WebKitIgalia/issues/1">our “Upstreaming status” page at GitHub</a> to follow LBSE development.</p>
+
+
+
+
+ Use Case: WPE in digital signage
+
+ 2023-01-06T00:00:00Z
+ https://wpewebkit.org/wpewebkit.org/aperezdc/learn-discover-rework/blog/2023-use-case-digital-signage.html
+ <div class="success-top">
+<img alt="WPE WebKit in digital signage" align="center" src="https://wpewebkit.org/assets/img/logo-digital-signage.png" srcset="https://wpewebkit.org/assets/img/logo-digital-signage@2x.png 2x" />
+<img alt="WPE" align="center" src="https://wpewebkit.org/assets/img/logo-blue.svg" />
+</div>
+<p>Digital signage web rendering players have many advantages and are a trend nowadays. They allow to use HTML5 for composing the UI, provisioning and scheduling new contents to the screens from the cloud is simple and effortless, they provide a robust environment with an automatic crash recovery system, etc. They are also a great choice for digital signage kiosk deployments.</p>
+<p>WPE WebKit is an excellent option to use as web rendering engine for Linux-based digital signage players, specially for the low-end market, where WPE Webkit allows to achieve great graphics and rendering performance in the less powerful devices like the ones based on the Raspberry Pi. As a result, WPE WebKit is naturally compatible with the hardware of the main digital signage manufactures that rely on these kind of lower-powered devices.</p>
+
+
+
+
+ Success Story: Metrological
+
+ 2022-10-15T00:00:00Z
+ https://wpewebkit.org/wpewebkit.org/aperezdc/learn-discover-rework/blog/2022-success-metrological.html
+ <div class="success-top">
+<img alt="Metrological: A Comcast Company" align="center" src="https://wpewebkit.org/assets/img/logo-metrological@2x.png" />
+<img alt="WPE" align="center" src="https://wpewebkit.org/assets/img/logo-blue.svg" />
+</div>
+<p>WPE WebKit brought <strong>RDK (Reference Design Kit)</strong>, a modern, performant web browser, to millions of screens. It enables operators to manage devices and easily customize their UIs and apps and provides analytics to improve the customer experience and drive business results.</p>
+<p>Delivering a fast and memory-efficient browser for embedded systems is a challenging task, so Igalia helped Metrological build a new full-screen browser engine which stripped away all unnecessary toolkit elements.</p>
+<p>With years of experience around WebKit platform integration, Igalia worked to produce a new WebKit port, WPE, which interfaced directly with Wayland and the graphics driver. Additionally, Igalia pushed forward the implementation of a multi-platform multi-threaded compositor, enabling better performance on low-end multicore processors. WPE is an official port of WebKit.</p>
+
+
+
diff --git a/aperezdc/learn-discover-rework/blog/01-happy-birthday-wpe.html b/aperezdc/learn-discover-rework/blog/01-happy-birthday-wpe.html
new file mode 100644
index 000000000..87cf26930
--- /dev/null
+++ b/aperezdc/learn-discover-rework/blog/01-happy-birthday-wpe.html
@@ -0,0 +1,353 @@
+
+
+
+
+
+
+
+
+
+
+
+ Happy birthday WPE!
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Today is a special day for Igalia, especially for those colleagues that work on WebKit:
+Five years ago, on the 21st of April 2017, the WPE port was announced by our colleague
+Žan Doberšek on the WebKit mailing list.
+
Let’s take some time to celebrate and recap how WPE evolved from the early prototyping days to the product empowering hundreds of millions of devices
+worldwide today.
+
+
+
+
WPE is … what exactly?
+
To get everyone on the same page, let’s start by reiterating what WPE is: a WebKit port optimized for embedded devices.
+It allows you to embed a full-fledged Web browser engine that supports a large set of modern Web technologies into your product.
+WPE itself is not a Web browser such as Safari, Chrome or Firefox but contains the underlying building blocks to load, parse and
+render websites. To learn more about the distinction between a Web browser and a Web browser engine read our explainer.
+
You might ask yourself, what does “optimized for embedded devices” mean in practice? Unlike most other WebKit ports, WPE does not
+rely on a specific user-interface toolkit, such as Qt, GTK, Cocoa,
+etc., nor does it offer any integration with these kinds of toolkits. WPE WebKit is light-weight, integrates well with a
+variety of hardware configurations, and only requires a minimum set of APIs on your side:
+EGL and OpenGL ES 2.
+
The early days 2014 - 2017
+
The idea for a new WebKit port was born in 2014, as part of a collaboration between Metrological
+and Igalia. The goal of this collaboration was to have a WebKit port running efficiently on their set-top boxes,
+utilizing a modern Wayland based Linux graphics architecture. Back then, QtWebKit was popular
+among embedders; however, it was unmaintained and its future was unclear since Qt wanted to transition
+from using WebKit to Blink.
+
In September 2014 a group of Igalians forked the WebKitGtk port, removed all GTK toolkit dependencies, and prototyped what was necessary
+to achieve the goal: rendering websites without involving any of the traditional toolkits and instead utilizing a Wayland-based rendering approach.
+
During development it became apparent that this WebKit port is generally useful for all our customers and the community as a whole.
+Therefore Igalia decided to aim for an even more flexible design, where Wayland is only one of the possible backends.
+Our fellow Igalian Miguel Gomez reported in his late 2016 blog post
+about this change, and the renaming of the port: WPE appears for the first time in public.
+
The project’s removal of the Wayland dependency and the subsequent reorganization lead to the architecture we have today,
+consisting of not only the WPE port itself but a whole ecosystem of projects such as libwpe,
+WPEBackend-fdo, WPEBackend-rdk, etc.,
+that together form the WPE project.
+
2017 - today
+
After months of focused engineering efforts, the downstream work was finished and Igalia was ready to announce WPE to the
+public on the 17th of April 2017, with the promise that Igalia
+will maintain the port alongside the existing WebKitGtk port. That is not a cheap bill: maintaining an upstream port is a recurring
+multi-million dollar investment. Just in order to keep the port itself healthy, as updates are made all around it, requires infrastructure,
+bots and a team of fully dedicated engineers to deal with maintenance, testing, triaging, tickets, etc. To implement new Web standards, fix
+related bugs or design and contribute features requires an even more considerable amount of resources.
+
Since then, Igalia ramped up the WPE investments and steadily advanced the port while helping customers to integrate WPE into their
+environments. Today WPE is healthy, runs on many platforms, and offers the most flexible browser architecture at present. Also, thanks in great
+part to this work, Igalia was responsible for nearly 16.5% of all commits in WebKit itself last year, helping make the larger project
+and ecosystem around it healthier too.
+
However, none of this would be possible without the commitment of many Igalians pushing the project forward every day for the past 8 years.
+A new People Behind WPE series will be launched soon: over the following months, the Igalians involved with WPE will introduce themselves, their area of
+expertise, and talk about a specific WPE related technical topic. You’ll get to know the people behind the product and a first-class technical overview
+of individual parts of the WPE architecture! We plan to release a new article every 3-4 weeks, so be sure to visit wpewebkit.org/blog
+again soon and enjoy the upcoming People Behind WPE series.
+
Feel free to spread the word and make noise about WPE. Stay healthy, stay tuned!
I'm a proud Igalian since 2019 and have been working on WebKits predecessors since the early 2000s, namely kjs/khtml/ksvg, and kdom/kcanvas/ksvg2/khtml2 that all found their way into WebKit. Since that time, Web technology - especially SVG - is my main area of interest.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
In the previous post in this series,
+we explained that WPE is a WebKit
+port optimized for embedded devices. In this post, we’ll dive into a
+more technical overview of the different components of WPE, WebKit,
+and how they all fit together. If you’re still wondering what a web
+engine is or how WPE came to be, we recommend you to go back to the
+first post in the series and then come back here.
+
WebKit architecture in a nutshell
+
To understand what makes WPE special, we first need to have a basic
+understanding of the architecture of WebKit itself, and how it ties
+together a given architecture/platform and a user-facing web browser.
+
WebKit, the engine, is split into different components that
+encapsulate its different parts. At the heart of it is WebCore. As the
+name suggests, this contains the core features of the engine
+(rendering, layout, platform access, HTML and DOM support, the
+graphics layer, etc). However, some of these ultimately depend heavily
+on the OS and underlying software platform in order to function. For
+example: how do we actually do any I/O on different platforms? How do
+we render onscreen? What’s the underlying multimedia platform and how
+does it decode media and play it?
+
WebCore handles the multitude of potential answers to these questions
+by abstracting the implementation of each component and allowing port
+developers to fill the gaps for each supported platforms. For example,
+for rendering on Mac, Cocoa APIs implement the graphics APIs
+needed. On Linux, this can be done through different implementations
+via Wayland, Vulkan, etc. For networking I/O on Mac, the networking
+APIs in the Foundation framework are used. On Linux, libsoup fills
+that gap, and so on.
+
On the opposite side, for browser implementors to be able to write a
+browser using WebKit, an API is needed. WebKit, after all, is a
+library. WebKit ports, besides providing the platform support
+described above, also provide APIs that suit the target environments:
+The Apple ports provide Objective-C APIs (which are then used to write
+Safari and the iOS browsers, for instance), while the GTK+ port
+provides a GObject-based APIs for Linux (that are used in Epiphany,
+the GNOME browser, and other GNOME applications that rely on WebKit to
+render HTML). All of these APIs are built on top of an internal,
+middle-man, C API that is meant to make it easy for each port to
+provide a high-level API for browser developers.
+
With all this in place, it would seem that it shouldn’t be so
+difficult for any vendor trying to reuse WebKit in a new platform to
+support new hardware and implement a browser, right? All that you need
+to do is:
+
+
Implement backends that integrate with your hardware platform: for
+multimedia, IO, OS support, networking, graphics, etc.
+
Write an API that you can use to plug the engine into your browser.
+
Maintain the changes needed off-tree, that is, outside the source code tree
+of WebKit.
+
Keep your implementation up-to-date with the many changes that happen in the
+WebKit codebase on a daily basis, so that you can update WebKit regularly
+and take advantage of the many bug fixes, improvements, and new features
+that land on WebKit continuously.
+
+
Does that sound easy? No, it’s not easy at all! In fact,
+implementation of ports in this fashion is strongly discouraged and
+vendors who have tried this approach in the past have had to do a huge
+effort just to play catch-up with the fast-paced development of
+WebKit. This is where WPE comes to the rescue.
+
Simplifying browsers development in the diverse embedded world
+
To simplify the task of porting WebKit to different platforms, Igalia
+started working on a platform-agnostic, Linux-based, and full-featured
+port of WebKit. This port relies on existing and mature platform
+backends for everything that can be easily reused across platforms:
+multimedia, networking, and I/O, which are already present in-tree and
+are used by Linux ports, like the GTK one. For the areas that are most
+likely to require hardware-specific support (that is, graphics and
+input), WPE abstracts the implementation so that it can be more easily
+provided out of tree, allowing implementors to avoid having to deal
+with the WebKit internals more than what’s strictly needed.
+
Additionally, WPE provides a high-level API that can be used to
+implement actual browsers. This API is very similar to the WebKitGTK
+API, making it easy for developers already familiar with the latter to
+start working with WPE. The cog library also serves as a wrapper
+around WPE to make it easier still. Once WPE was mature enough, it was
+accepted by Apple as an official WebKit port, meaning that the port
+lives now in-tree and takes immediate advantage of the many
+improvements that land on the WebKit repository on a daily basis.
+
How does WPE integrate with WebKit?
+
+
The WPE port has several components. Some are in-tree (that is, are a
+part of WebKit itself), while others are out-of-tree. Let’s examine
+those components and how they relate to each other, from top to
+bottom:
+
+
The Cog library.
+While not an integral part of WPE, libcog is a shell library that simplifies
+the task of writing a WPE browser from the scratch, by providing common
+functionality and helper APIs. This component also includes the cog browser,
+a simple WPE browser built on top of libcog that can be used as a reference
+or a starting point for the development of a new browser for a specific use
+case.
+
The WPE WebKit API:
+the entry point for browser developers to the WebKit engine, provides a
+comprehensive GObject/C API. The cog library uses this API extensively and
+we recommend relying on it, but for more specific needs and more fine-tuning
+of the engine, working directly with the WebKit API can be often necessary.
+The API is stable and easy to use, especially, and for those familiar with
+the GTK/GNOME platform.
+
WPE’s WebCore implementation: This part, internal to WebKit, implements
+an abstraction of the graphics and input layers of WebKit. This
+implementation relies on the libwpe library to provide the functionality
+required in an abstract way. Thanks to the architecture of WPE, implementors
+don’t need to bother with the complexities of WebCore and WebKit internals.
+
The libwpe
+library. This is an out-of-tree library that provides the API required by
+the WPE port in a generic way to implement the graphical and input backends.
+Specific functionality for a concrete platform is not provided, but the
+library relies on the existence of a backend implementation, as is described
+next.
+
Finally, a WPE backend implementation. This is where all the
+platform-specific code lives. Backends are loadable modules that can be
+chosen depending on the underlying hardware. These should provide access to
+graphics and input depending on the specific architecture, platform, and
+operating system requirements. As a reference, WPEBackend-fdo is a
+freedesktop.org-based backend, which uses Wayland and freekdesktop.org
+technologies, and is
+supported for several architectures, including NXP and Broadcom chipsets, like the
+Raspberry Pi, and also regular PC architectures, easing testing and
+development.
+
+
An implementor interested in building a browser in a new architecture
+only needs to focus on the development of the last component – a WPE
+backend. Having a backend, starting the development of a
+WebKit-powered browser is already much easier than it ever was!
+
For a more detailed description of the architecture of WPE and WebKit,
+check this article on the architecture of WPE.
+
OK, sounds interesting, how do I get my hands dirty?
+
If you have made it this far, you should give WPE a try!
+
We have listed several on the exploring WPE
+page. From there, you will see that depending on how interested you
+are in the project, your background, and what you’d like to do with
+it, there are different ways!
+
It can be as easy as installing WPE directly from the most popular
+Linux distributions. If you want to build WPE yourself,
+you can use Yocto and if
+you’d like to contribute—that’s very welcome!
Claudio is long-time WebKit contributor from Igalia, working in different areas of WebKit, WPE, and the stack around it.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Following the previous post in the series about WPE where we talked about the WPE components, this post will explain briefly the WPE graphics architecture, and how the engine is able to render HTML content into the display. If you haven’t read the previous entries in this blog post series about WPE, we recommend you to start with the first post in the series for an introduction, and then come back to this.
+
DOM + CSS = RenderTree
+
As the document is parsed, it will begin building the DOM tree and load-blocking CSS resources. At some point, possibly before the entire DOM tree is built, it’s time to draw things on the screen. The first step to render the content of a page is to perform what’s called the attachment, which is merging the DOM tree with the CSS rules, in order to create the RenderTree. This RenderTree is a collection of RenderObjects, structured into a tree, and each of these RenderObjects represent the elements in the DOM tree that have visual output. RenderObjects have the capability to render the associated DOM tree node into a surface by using the GraphicsContext class (in the case of WPE, this GraphicsContext uses Cairo to perform the rendering).
+
Once the RenderTree is created, the layout is performed, ensuring that each of the RenderObjects have their proper size and position set.
+
+
It would be possible to render the content of the web page just traversing this RenderTree and painting each of the RenderObjects, but there would be problems when rendering elements that overlap each other, because the order of the elements in the RenderTree doesn’t necessarily match the order in which they must be painted in order to get the appropriate result. For example, an element with a big z-index value should be painted last, no matter its position in the RenderTree.
+
This is an example of how some HTML content is translated into the RenderTree (there are some RenderObjects missing here that are not relevant for the explanation).
+
+
RenderLayers
+
In order to ensure that the elements of the RenderTree are rendered in the appropriate order, the concept of RenderLayer is added. A RenderLayer represents a layer in the document containing some elements that have to be rendered at the same depth (even though this is not exactly the case, you can think of each RenderLayer as a group of RenderObjects that are at a certain z-index). Each RenderObject is associated to a RenderLayer either directly or indirectly via an ancestor RenderObject.
+
RenderLayers are grouped into a tree, which is called the RenderLayer tree, and RenderLayer children are sorted into two lists: those that are below the RenderLayer, and those that are above. With this we have a structure that has grouped all the RenderObjects that have to be rendered together: they will be on top of the content that has been rendered by the RenderLayers below this one, and below the content rendered by the RenderLayers over this one.
+
There are several conditions that can decide whether a RenderLayer is needed for some element, it doesn’t necessarily needs to be due to the usage of z-index. It can be required due to transparency, CSS filters, overflow, transformations, and so on.
+
Continuing with the example, these are RenderLayers that we would get for that HTML code:
The root one, corresponding to the RenderView element. This is mandatory.
+
Another one corresponding to the first RenderBlock.
+
One corresponding to the RenderVideo element, because video elements always get their own RenderLayer.
+
One corresponding to the transformed RenderBlock.
+
+
RenderLayers have a paint method that is able to paint all the RenderObjects associated to the layer into a GraphicsContext (as mentioned, WPE uses Cairo for this). As in the previous case, it’s possible to paint the content of the page at this point just by traversing the RenderLayer tree and requesting the RenderLayers to paint their content, but in this case the result will be the correct one. Actually this is what WebKitGTK does when it’s run with accelerated compositing disabled.
+
Layer composition
+
While with the previous step we are already able to render the page contents, this approach is not very efficient, especially when the page contains animations, elements with transparency, etc. This is because in order to paint a single pixel, all the RenderLayers need to be traversed, and those that are contributing to that pixel need to be repainted (totally or partially), even if the content of those RenderLayers hasn’t changed. For example, think about an animation that’s moving an element. For each frame of that animation, the animated element needs to be repainted, but the area that was covered by the animated element in the last frame needs to be repainted as well. The same happens if there’s a translucent element on top of other content. If the translucent element changes, it needs to be repainted, but the content below the translucent element needs to be repainted as well because the blend needs to be performed again.
+
This would be much more efficient if the content that doesn’t change was somehow separated from the content that’s changing, and we could render those two types of content separately. This is where the composition stage comes into action.
+
The idea here is that we’re going to paint the RenderLayer contents into intermediate buffers, and then compose those buffers one on top of the other to get the final result. This last step is what we call composition. And it fixes the problems we mentioned with animations of transparency: animations don’t require repainting several RenderLayers. Actually moving an element just means painting one buffer with an offset during the composition. And for transparency, we just need to perform the new blending of the two buffers during the composition, but the RenderLayers of the content below the translucent element don’t need to be repainted.
+
Once we have the RenderLayer tree, we could just paint each RenderLayer in its own buffer in order to perform the composition. But this would be a waste of memory, as not every RenderLayer needs a buffer. We introduce here a new component, the GraphicsLayer.
+
GraphicsLayers are a structure used to group those RenderLayers that will render into the same buffer, and it will also contain all the information required to perform the composition of these buffers. A RenderLayer may have a GraphicsLayer associated to it if it requires its own buffer to render. Otherwise, it will render into an ancestor’s buffer (specifically, the first ancestor that has a GraphicsLayer). As usual, GraphicsLayers are structured into a tree.
+
This is how the example code would be translated into GraphicsLayers.
The root one, which is mandatory. It belongs to the RenderView element, but the first RenderBlock will render into this GraphicsLayer's buffer as well.
+
The one for the RenderVideo element, as videos are updated independently from the rest of the content.
+
The one for the transformed element, as the transformed elements are updated independently from the rest of the content.
+
+
With this structure, now we can render the intermediate buffers of the RenderView and the transformed RenderBlock, and we don’t need to update them any more. For each frame, those buffers will be composited together with the RenderVideo buffer. This RenderVideo will be updating its buffer whenever a new video frame arrives, but it won’t affect the content of the other GraphicsLayers.
+
So now we have successfully separated the content that is changing and needs to be updated from the content that remains constant and doesn’t need to be repainted anymore, just composited.
+
Accelerated compositing and threaded accelerated compositing
+
There’s something else that be done in order to increase the rendering performance, and it’s using the GPU to perform the composition. The GPU is highly optimized to perform operations like the buffer composition that we need to do, as well as handle 3D transforms, blending, etc. We just need to upload the buffers into textures and let the GPU handle the required operations. WPE does this though the usage of the EGL and GLES2 graphics APIs. In order to perform the composition, EGL is used to create a GLES2EGLContext. Using that context, the intermediate buffers are uploaded to textures, and then those textures are positioned and composited according to their appropriate positions. This leverages the GPU for the composition work, leaving the CPU free to perform other tasks.
+
This is why this step is called accelerated compositing.
+
But there’s more.
+
Until this point, all the steps that are needed to render the content of the page are performed in the main thread. This means that while the main thread is rendering and compositing, it’s not able to perform other tasks, like run JS code.
+
WPE improves this by using a parallel thread whose only mission is to perform the composition. You can think of it as a thread that runs a loop that composites the incoming buffers using the GPU when there’s content to render. This is what we call threaded accelerated compositing.
+
This is specially useful when there’s a video or an animation running on the page:
+
+
+
If there’s a video running in the page, in the non-threaded case, for each video frame the main thread would need to get the frame and perform the composition with the rest of the page content. In the threaded case, the video element delivers the frames directly to the compositor thread, and requests a composition to be done, without the main thread being involved at all.
+
+
+
If there’s an animation, in the non-threaded case, for each frame of the animation the main thread would need to calculate the animation step and then perform the composition of the animated element with the rest of the page content. In the threaded case, the animation is passed to the compositor thread, and the animation steps are calculated on that thread, triggering a composition when needed. The main thread doesn’t need to do anything besides starting the animation.
+
+
+
It would take another post to explain in detail how the threaded accelerated composition is implemented on WPE, but if you’re curious about it, know that WPE uses an specialization of the GraphicsLayer called CoordinatedGraphicsLayer in order to implement this. You can use that as an starting point.
+
So this is the whole process that’s performed in WPE in order to display the content of a page. We hope it’s useful!
+
Future
+
At Igalia we’re constantly evolving and improving WPE, and have ongoing efforts to improve the graphics architecture as well. Besides small optimizations and refactors here and there, the most important goals that we have are:
+
+
+
Add a GPU process. Currently the EGL and GLES2 operations are performed in the web process. As there can be several web processes running when several pages are open, this means the browser can be using a lot of EGL contexts in total, which is a waste of memory. Also, all these processes could potentially be affected by errors, leaks, etc., in the code that handles the GPU operations. The idea is to centralize all the GPU operations into a single process, the GPU one, so all the web processes will issue paint requests to the GPU process instead of painting their content themselves. This will reduce the memory usage and improve the software’s robustness.
+
+
+
Remove CPU rasterization and paint all the content with GLES2. Using the CPU to paint the layer contents with cairo is expensive, especially in platforms with slow CPUs, as embedded devices sometimes do. Our goal here is to completely remove the cairo rasterization and use GLES2 calls to render the 2D primitives. This will greatly improve the rendering performance.
+
+
+
Use ANGLE to perform WebGL operations. WPE currently implements the WebGL 1.0 specification through direct calls to GLES2 methods. We are changing this in order to perform the operations using ANGLE, which will allow WPE to support the WebGL 2.0 specification as well.
+
+
+
But what about the backends?
+
In the previous post there was a mention of backends that are used to integrate with the underlying platform. How is this relevant to the graphics architecture?
+
Backends have several missions when it comes to communicate with the platform, but regarding graphics, they have two functions to achieve:
+
+
+
Provide a platform dependent surface that WPE will render to. This can be a normal buffer, a Wayland buffer, a native window, or whatever, as long as the system EGL implementation allows creating an EGLContext to render to it.
+
+
+
Process WPE indications that a new frame has been rendered, performing whatever tasks are necessary to take that frame to the display. Also notify WPE when that frame was been displayed.
+
+
+
The most common example of this is a Wayland backend, which provides a buffer to WPE for rendering. When WPE has finished rendering the content, it notifies the backend, which sends the buffer to the Wayland compositor, and notifies back to WPE when the frame has been displayed.
+
So, whatever platform you want to run WPE on, you need to have a backend providing at least these capabilities.
+
Final thoughts
+
This was a brief overview of how WPE rendering works, and also what are the major improvements we’re trying to achieve at Igalia. We’re constantly putting in a lot of work to keep WPE the best web engine available for embedded devices.
+
If this post got you interested in collaborating with WPE development, or you are in need of a web engine to run on your embedded device, feel free to contact us. We’ll be pleased to help!
+
We also have open positions at the WebKit team at Igalia. If you’re motivated by this field and you’re interested in developing your career around it, you can apply here!
Miguel has been contributing to WebKit and WPE for almost ten years now, focusing specially on the graphics part of the code.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
At the heart of any browser engine is networking: Connecting with services and other users. Unlike other engines, WebKit approaches this more abstractly by leaving a large portion of the networking up to individual ports. This includes network protocols such as HTTP, WebSockets, and WebRTC. The upside to this approach is a higher level of integration with the system-provided libraries and features so WebKit will behave similarly to other software on the platform often with more centralized configuration.
+
Due to this abstraction there are a few independent layers that make up the networking stack of WPE. In this post, I’ll break down what each layer accomplishes as well as give some insight into the codebase’s structure.
+
Networking Layers
+
+
+
+
WebKit
+
Before we get into the libraries used for WPE, let’s discuss WebKit itself. Despite abstracting out a lot of the protocol handling, WebKit itself still needs to understand a lot of fundamentals of HTTP.
+
WebCore (discussed in WPE Overview) understands HTTP requests, headers, and cookies, as they are required to implement many higher-level features. What it does not do is the network operations, most parsing, or on-disk storage. In the codebase, these are represented by ResourceRequest and ResourceResponse objects, which map to general HTTP functionality.
+
NetworkProcess
+
A core part of modern web engine security is the multi-process model. In order to defend against exploits, each website runs in its own isolated process that does not have network access. In order to allow for network access, they must talk over IPC to a dedicated NetworkProcess, typically one per browser instance. The NetworkProcess receives a ResourceRequest, creates a NetworkDataTask with it to download the data, and responds with a ResourceResponse to the WebProcess which looks like this:
+
+
+
+
WPE
+
WPE implements the platform-specific versions of the classes above as ResourceRequestSoup and NetworkDataTaskSoup, primarily using a library called libsoup.
+
The libsoup library was originally created for the GNOME project’s email client and has since grown to be a very featureful HTTP implementation, now maintained by Igalia.
+
At a high level, the main task that libsoup does is manage connections and queued requests to websites and then efficiently streams the responses back to WPE. Properly implementing HTTP is a fairly large task, and this is a non-exhaustive list of features it implements: HTTP/1.1, HTTP/2, WebSockets, cookies, decompression, multiple authentication standards, HSTS, and HTTP proxies.
+
On its own, libsoup is really focused on the HTTP layer and uses the GLib library to implement many of its networking features in a portable way. This is where TCP, DNS, and TLS are handled. It is also directly used by WebKit for URI parsing and DNS pre-caching.
+
Using GLib also helps standardize behavior across modern Linux systems. It allows configuration of a global proxy resolver that WebKit, along with other applications, can use.
+
TLS
+
Another unique detail of our stack is that TLS is fully abstracted inside of GLib by a project called GLib-Networking. This project provides multiple implementations of TLS that can be chosen at runtime, including OpenSSL and gnutls on Linux. The benefit here is that clients can choose the implementation they prefer—whether for licensing, certification, or technical reasons.
+
Usage
+
Let’s go step by step to see some real world usage. If we call webkit_web_view_load_uri() for a new domain it will:
+
+
Create a ResourceRequest in WebCore that represents an HTTP request with a few basic headers set.
+
+
ResourceRequestSoup will create its own internal representation for the request using soup_message_new_for_uri().
+
+
+
This is passed to the NetworkProcess to load this request as a NetworkDataTask.
+
NetworkDataTaskSoup will send/receive the request/response with soup_session_send() which queues the message to be sent.
+
libsoup will connect to the host using GSocketClient which does a DNS lookup and TCP connection.
+
+
If this is a TLS connection GTlsClientConnection will use a library such as gnutls to do a TLS handshake.
+
+
+
libsoup will write the HTTP request and read from the socket parsing the HTTP responses eventually returning the data to WebKit.
+
WebKit receives this data, along with periodic updates about the state of the request, and sends it out of the NetworkProcess back to the main process as a ResourceResponse eventually loading the data in the WebProcess.
+
+
Summary
+
In conclusion, WebKit provides a very flexible abstraction for platforms, and WPE leverages mature system libraries to provide a portable implementation. It has many layers, but they are all well organized and suited to their tasks.
+
If you are working with WPE and are interested in collaborating, feel free to contact us. If you are interested in working with Igalia, you can apply here.
Patrick has been contributing to WebKit since 2018 and does work around networking, security, and the platform libraries WPE uses.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
In the previous posts, my colleagues Claudio and Miguel wrote respectively about the major components of the project and, specifically, the graphics architecture of WPE. Today, you’ll see our efforts to improve the quality of both WPE and the experience of working and using it. While the previous entries in this blog post series about WPE aren’t necessarily required in order to read this one, we recommend you to starting with the first post in the series.
+
Automated testing
+
Testing is an essential part of the WebKit project, primarily due to the large number of use cases covered by HTML/CSS/Javascript specifications and the need for the project to work correctly in a wide range of configurations.
+
As an official port of WebKit, WPE uses the former’s testing infrastructure, based on BuildBot. There are two primary servers, one working as an early warning system by testing the patches before they’re committed to the main repository, and another for more extensive testing after accepting the incoming changes.
+
+
+
+
+
Currently, the WPE testing bots target debug and release configurations using the Flatpak SDK (more on it later in this article) on 64bit Intel-based Linux Debian systems. We have plans of adding bots running on Raspberry Pi boards in the future. Alongside nightly testing, we keep builder bots covering the Ubuntu LTS/Debian versions we support. After August 14th, 2022, the earliest supported versions will be Ubuntu 20.04 LTS and Debian 11 (Bullseye).
+
Test suites
+
Initially, the WPE builder bots build WPE in both release and debug configurations and feed the built packages into the tester bots, which run some test suites according to their configuration, each suite focused in one aspect of the project:
+
+
Layout tests: The main suite tests whether WebKit correctly renders web pages and its implementation of web APIs. This suite comprises both WebKit’s test cases and the imported tests from Web Platform Test. At the time of writing, it runs over 50,000 test cases.
+
API Tests: This suite tests the API provided to developers by WebKit and its ports. For example, this step tests the WPE API used in Cog.
+
Javascriptcore tests: Covers the JavascriptCore engine, running WebKit’s tests alongside test262, the reference test suite for JS/ECMAScript implementations.
Other small suites: Tests for WebKit’s tooling components.
+
+
Due to a large number of tests and the fast development of both WebKit and the specifications—it’s not uncommon to have dozens of daily commits touching dozens of tests—it’s hard to keep the testing bots green.
+
For example, while we try to make the tests work on all platforms, many old layout tests use the -expected.txt scheme, where the render tree is printed in a textual format with the text sized in pixels for every node. While this works fine in most cases, many tests have minor differences between the expected result in the Mac platform and the WPE/GTK platform. One of the causes is the font rendering particularities of each port.
+
Thankfully, this situation improved significantly since the beginning of the project. Among the efforts, many tests are now using a “reference” HTML file, which are HTML files that render to the same expected result as the test case, so both the test case and the reference will use the same font rendering scheme and can be compared pixel by pixel.
+
Building and running WPE
+
This section focuses on the experience of building and running WPE in a regular Linux x86–64 system. In a future post, we’ll cover building for and running on embedded devices.
Note: Due to the size of the project history, you might want to use --depth=1 to clone a single revision, followed by git pull --unshallow from inside the cloned repository to fetch the history if needed.
+
There’s more information in WebKit’s GitHub wiki about setting up the git checkout for contributing code back to WebKit. It’ll set up some git hooks to do some tasks required by the project, like formatting the commit message and automatically linking the pull request to the Bugzilla issue.
+
All commands in the following sections are run from inside the cloned repository.
+
Updating the dependencies (aka The WebKit Flatpak SDK)
+
Like most complex software projects, WebKit has a reasonably extensive list of dependencies. Keeping a reference set of their versions frozen during development is desirable to make it easier to reproduce bugs and test results. In older times, WPE and WebKitGTK used JHBuild to freeze a set of dependencies. While this worked for a long time, it did not cover all dependencies. Sometimes, there could be minor differences in the layout tests between the reference test bots and the developer machine due to some dependency resolved by the host system outside JHBuild.
+
To improve reproducibility, since 2020, WPE and WebKitGTK have been using an SDK based on Flatpak (kudos to my colleagues Thibault Saunier and Philippe Normand), with a much more extensive dependency coverage and isolation from the host system. Alongside the dependencies, it ships some tools like rr and supports tools like clangd. Almost all bots enable this SDK, the exception being the LTS/Stable bots; as in the latter, we want to build with the already available packages in each distribution.
+
$ ./Tools/Scripts/update-webkit-flatpak
+
+
The command will set up the local flatpak repository at ./WebKitBuild/UserFlatpak with the downloaded SDK and create some bundled icecc toolchains. This enables distributed builds in local networks…
+
Building
+
Once the SDK download finishes, you can use the helper script ./Tools/Scripts/build-webkit, which wraps the cmake command with some pre-set options commonly used in normal development, like enabling developer-only features usually disabled in regular builds. Manually invoking cmake is possible, although usually only when you want more control over the build. To build WPE in release mode, use:
+
$ ./Tools/Scripts/build-webkit --release --wpe
+
+
Optionally, you can pass it multiple arguments to be fed directly to make or cmake with the switches --makeargs=... and --cmakeargs=..., respectively. For example, --makeargs="-j8" will limit make to 8 parallel jobs and --cmakeargs="-DENABLE_GAMEPAD=1" will enable gamepad support (requires libmanette, bundled in the SDK).
+
The first build might take a while (up to almost one hour in a regular laptop). Fortunately, the SDK uses ccache to avoid recompiling the same object files, so subsequent builds without significant changes usually are faster. For more info on speeding the build, check the wiki.
+
Running the browser (Cog)
+
To run Cog, the reference WPE browser, you need a Wayland server, which is common in most Linux systems nowadays.
As stated when we described the test suites, the main challenge in testing is keeping up with the fast pace of development, as it’s not uncommon to have some revisions updating hundreds of tests.
+
Contributing code to WPE
+
After hacking locally, you can submit your changes following the workflow listed in the WebKit wiki.
+
Testing WPE in the wild
+
If you don’t want to build your WPE build or image, there are some options to get a taste of WPE listed on our website.
+
Final thoughts
+
With this, we conclude this brief overview of WPE automated testing and the main tools we use in our daily work with WPE. In future posts in this area we’ll go deeper in other subjects like testing on embedded boards and debugging practices.
+
If this post got you interested in collaborating with WPE development, or you are in need of a web engine to run on your embedded device, feel free to contact us. We’ll be pleased to help!
+
We also have open positions at the WebKit team at Igalia. If you’re motivated by this field and you’re interested in developing your career around it, you can apply here!
Lauro is webkit contributor from Igalia, working mainly on QA.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
In the previous posts of this series, various aspects of the WPE port architecture were covered. Besides maintaining and advancing the WPE port according to our customers’ needs, Igalia also participates in the development of the WebCore engine itself, which is shared by all WebKit ports. WebCore is the part of the browser engine that does the heavy lifting: it contains all functionality necessary to load, parse, lay out, and paint Web content.
+
Since late 2019, Igalia has been working on a new SVG engine, dubbed Layer-Based SVG Engine (LBSE), that will unify the HTML/SVG rendering pipelines in WebCore. This will resolve long-standing design issues of the “legacy” SVG engine and unlock a bunch of new exciting possibilities for Web developers to get creative with SVG. Hardware-accelerated compositing, driven by CSS transform animations, 3D perspective transformations for arbitrary SVG elements, CSS z-index support for all SVG graphics elements, and proper coverage rectangle computations and repaints are just a few highlights of the capabilities the future SVG engine will offer.
+
In this article, an overview is given about the problems that LBSE aims to solve, and the importance of a performant, well-integrated SVG engine especially for the embedded market. Finally, the current upstreaming status is summarized including an outlook for the year 2023.
+
LBSE in a nutshell
+
Before diving into the technical topics, let’s take a few minutes to recap the motivations behind the LBSE work, and explain the importance of a well-integrated, performant SVG engine in WebKit, especially for the embedded market.
+
Motivation
+
Many of our customers build products that utilize a Linux-powered embedded device, typically using non-x86 CPUs, custom displays with built-in input capabilities (e.g., capacitive touchscreens) often without large amounts of memory or even permanent storage. The software stack for these devices usually consists of a device-specific Linux distribution, containing the proprietary network, GPU, and drivers for the embedded device - the vendor-approved “reference distribution”.
+
No matter what type of product is built nowadays, many of them need an active Internet connection, to e.g. update their software stack and access additional information. Besides the UI needed to control the product, a lot of additional dialogs, wizards and menus have to be provided to be able to alter the devices’ “system settings”, such as date/time information, time zones, display brightness, WiFi credentials, Bluetooth settings, and so on.
+
A variety of toolkits exist that assist in writing GUI applications for embedded devices, with a few open-source projects on the market, as well as commercial products providing closed-source, proprietary solutions, that specifically target the embedded market and are often optimized for specific target device families, e.g. certain ARM processors / certain GPUs.
+
If the need arises, not only to communicate with the Internet but also to display arbitrary Web content, WPE comes into play. As presented in the first post in this series, the flexible and modular WPE architecture makes it an ideal choice for any product in the embedded market that needs Web browsing abilities. The GLib/C-based WPE public APIs allow for customization of the browsing engine and its settings (react on page load/input events, inject custom JS objects, modify style sheets, etc.) and allow the embedder to control/monitor all relevant Web browsing-related activities.
+
With a full-fledged Web engine at hand, one might ponder if it is feasible to replace the whole native GUI stack with a set of Web pages/applications, and only use WPE to paint the UI in full-screen mode, thus migrating away from native GUI applications — following the trend in the desktop market. The number of organizations migrating native GUI applications into Web applications is rapidly increasing, since there are compelling reasons for Web apps: “write once, use everywhere”, avoiding vendor lock-in, easy/reliable deployment and update mechanisms, and efficient test/development cycles (local in-browser testing!).
+
Due to the sheer capabilities of the Web platform, it has grown to an environment in which any kind of application can be developed – ranging from video editing applications, big data processing pipelines to 3D games, all using JS/WebAssembly in a browser, presented using HTML5/CSS. And as an important bonus: in 2023, it’s much easier to find and attract talented Web developers and designers that are fluent in HTML/CSS/JS, than those that are comfortable designing UI applications in proprietary, closed-source C/C++ frameworks.
+
A long-term customer, successfully using WPE in their products, had very similar thoughts and carried out a study, contracting external Web designers to build a complete UI prototype using Web technology. The mock-up made extensive use of SVG2, embedded inline into HTML5 documents or via other mechanisms (CSS background-image, etc.). The UI fulfilled all expectations and worked great in Blink and WebKit-based browsers, delivering smooth animations. On the target device, however, the performance was too slow, far away from usable. A thorough analysis revealed that large parts of the Web page were constantly repainted, and layout operations were repeated for every frame when animations were active. The accumulated time to display a new frame during animations was in the order of a few milliseconds on desktop machines, but took 20-25 milliseconds on the target device, making smooth 60 FPS animations impossible.
+
The poor performance is not the result of shortcomings in the WPE port of WebKit: when replacing the aforementioned animated SVG document fragments with HTML/CSS “equivalents” (e.g. simulating SVG circles with CSS border-radius tricks) the performance issue vanisheed. Why? SVG lacks support for a key feature called accelerated compositing, which has been available for HTML/CSS since its introduction more than a decade ago. This compositing heavily relies on the Layer Tree, which is unaware of SVG. Extending the Layer Tree implementation to account for SVG is the main motivation for LBSE.
+
If you are unfamiliar with the concepts of Render Tree and Layer Tree, you might want to read the “Key concepts” section of an earlier LBSE design document, which provides an overview of the topic.
+
Prototyping
+
The LBSE effort began in October 2019 as a research project, to find out an ideal design for the SVG Render Tree, that allows SVG to re-use the existing Layer Tree implementation with minimal changes. The aim for LBSE is to share as much code as possible with the HTML/CSS implementation, removing the need for things like SVG specific clipping/masking/filter code and disjoint HTML counterparts for the same operations.
+
After an extensive phase of experimentation, two abandoned approaches, and a long time spent on regression fixing, the LBSE prototype was finally finished after almost two years of work. It passed all 60k+ WebKit layout tests and offered initial support for compositing, 3D transformations, z-index, and more. The intent was to prove that we can reach feature parity with the legacy SVG engine and retrieve the very same visual results, pixel-by-pixel (except for progressions of LBSE). Shortly after the finalization, the prototype was presented during the WebKit contributors meeting in 2021.
+
As the name “prototype” indicates, LBSE was not ready for integration into WebKit at this point. It replaced the old SVG engine with a new one, resulting in a monolithic patch exceeding 650 KB of code changes. External contributions generally demand small patches, with ChangeLogs, tests, etc. – no conscientious reviewer in any company would approve a patch replacing a core component of a browser engine in one shot. Splitting up into small pieces is also not going to work, since SVG needs to be kept intact upstream all the time. Duplicating the whole SVG engine? Not practicable either. With that problem in mind, a fruitful discussion took place with Apple during and after the WebKit contributors meeting: a realistic upstreaming strategy was defined - thanks Simon Fraser for suggesting a pragmatic approach!
+
The idea is simple: bootstrap LBSE in parallel to the legacy SVG engine. Upstream LBSE behind a compile-time flag and additionally a runtime setting. This way the LBSE code is compiled by the EWS bots during upstreaming (rules out bit-rot) and we gain the ability to turn LBSE on, selectively, from our layout tests – very useful during early bootstrapping. For WebKit, that strategy is the best – for LBSE another major effort is necessary: moving from a drop-in replacement approach to a dual-stack SVG engine: LBSE + legacy built into the same WebKit binaries. At least the timing was good since a split-up into small pieces was needed anyhow for upstreaming. Time to dissect the huge branch into logical, atomic pieces with proper change logs.
+
Before we jump to the upstreaming status, one question should be answered, that came up during the WebKit contributors meeting and also during various discussions: why don’t you just fix the existing SVG engine and instead propose a new one - isn’t that too risky for Web compatibility?
+
Why don’t you fix the existing SVG engine?
+
+
There was no initial intention to come up with a new SVG engine. During LBSE development it became apparent how much SVG-specific code can be erased when unifying certain aspects with HTML/CSS. After carrying out the integration work, layout/painting and hit-testing work fundamentally different than before. Since that time, LBSE is labeled as a “new SVG engine”, even though the SVG DOM tree part remained almost identical. Web compatibility will improve with LBSE: a few long-standing, critical interop issues with other browser vendors are solved in LBSE. Therefore, there are no concerns regarding Web compatibility risks from our side.
+
To answer the initial question, whether it is possible to fix the existing SVG engine to add layer support without adding a “new” SVG engine in parallel? Short answer: no.
+
In the following section, it is shown that adding support for layers implies changing the class hierarchy of the SVG render tree. All SVG renderers need to inherit from RenderLayerModelObject – a change like this cannot be split up easily into small, atomic pieces. Improving the design is difficult if there’s a requirement to keep the SVG engine working all the time upstream: all patches in that direction end up being large as many renderers have to be changed at the same time. Having distinct, LBSE-only implementations of SVG renderers, independent of the legacy engine, leaves a lot of freedom to strive for an optimal design, free of legacy constraints, and avoids huge patches that are impossible to review.
+
Let’s close the introduction and review the upstreaming status, and discuss where we stand today.
+
Upstreaming progress
+
Planning
+
To unify the HTML/CSS and SVG rendering pipelines there are two possible paths to choose from: teach the Layer Tree about the SVG Render Tree and its rendering model, or vice-versa. For the latter path, the HTML/CSS-specific RenderLayer needs to split into HTML/SVG subclasses and a base class, that is constructible from non-RenderLayerModelObject-derived renderers. The layer management code currently in RenderLayerModelObject would need to move into another place, and so forth. This invasive approach can potentially break lots of things. Besides that danger, many places in the layer/compositing system would need subtle changes to account for the specific needs of SVG (e.g. different coordinate system origin/convention).
+
Therefore the former route was chosen, which requires transforming the SVG render tree class hierarchy, such that all renderers that need to manage layers derive from RenderLayerModelObject. Using this approach support, for SVG can be added to the layer/compositing system in a non-invasive manner, with only a minimum of SVG-specific changes. The following class hierarchy diagrams illustrate the planned changes.
+
+
The first graph shows the class hierarchy of the render tree in the legacy SVG engine: RenderObject is the base class for all nodes in the render tree. RenderBoxModelObject is the common base class for all HTML/CSS renderers. It inherits from RenderLayerModelObject, potentially allowing HTML renderers to create layers. For the SVG part of the render tree, there is no common base class shared by all the SVG renderers, for historical reasons.
+
The second graph shows only the SVG renderers of the LBSE class hierarchy. In that design, all relevant SVG renderers may create/destroy/manage layers, via RenderLayerModelObject. More information regarding the challenges can be found in the earlier LBSE design document.
That process needs to be repeated for all SVG renderers that have substantially changed in LBSE and thus deserve an LBSE-specific upstream implementation. For all other cases, in-file #if ENABLE(LAYER_BASED_SVG_ENGINE) ... #endif blocks will be used to encapsulate LBSE-specific behavior. For example, RenderSVGText / RenderSVGInlineText are almost identical in LBSE downstream, compared to their legacy variants; thus, they are going to share the renderer implementation between the legacy SVG engine and LBSE.
By February 2022, enough functionality was in place to construct the LBSE render tree for basic SVG documents, utilizing nested containers and rectangles as leaves. While this doesn’t sound exciting at all, it provided an ideal environment to implement support for SVG in the RenderLayer-related code - before converting all SVG renderers to LBSE, and before implementing painting in the SVG renderers.
+
Both RenderLayer and RenderLayerBacking query CSS geometry information such as border box, padding box, or content box from their associated renderer, which is expected to be a RenderBox in many places. This is incorrect for SVG: RenderSVGModelObject inherits from RenderLayerModelObject, but not from RenderBox since it doesn’t adhere to the CSS box model. Various call sites cast the associated renderer to RenderBox to call e.g. borderBoxRect() to retrieve the border box rectangle. There are similar accessors in SVG to query the geometry, but there is no equivalent of a border box or other CSS concetps in SVG. Therefore, we extended RenderSVGModelObject to provide a CSS box model view of an SVG renderer, by offering methods such as borderBoxRectEquivalent() or visualOverflowRectEquivalent() that return geometry information in the same coordinate system using the same conventions as their HTML/CSS counterparts.
+
We also refactored RenderLayer to use a proxy method - rendererBorderBoxRect() - that provides access to the borderBoxRect() for HTML and the borderBoxRectEquivalent() for SVG renderers, and the same fix to RenderLayerBacking. With these fixes in place, support to position and size SVG layers and to compute overflow information could be added – both pre-conditions to enable painting.
+
By March 2022, LBSE was able to paint basic SVG documents - a major milestone for the bootstrapping process, demonstrating that the layer painting code was functional for SVG. It was time to move on to transformations: implementing RenderSVGTransformableContainer (e.g. <g> elements with a non-identity transform attribute or CSS transform property) and CSS/SVG transform support for all other graphics primitives, utilizing the RenderLayer-based CSS Transform implementation. As preparation, the existing code was reviewed and cleaned up: transform-origin computation was decoupled from CTM computation (CTM = current transformation matrix, see CSS Transforms Module Level 1) and transform-box computations were unified in a single place.
+
In April 2022, 2D transformswere enabled and became fully functional a few weeks later. Besides missing compositing support upstream, downstream work showed that enabling 3D transforms for SVG required fixing a decade-old bug that made the computed perspective transformation dependent on the choice of transform-origin. That became apparent when testing the layer code with SVG, which uses different default values for certain transform-related CSS properties than HTML does: transform-box: view-box and transform-origin: 0 0 are the relevant defaults for SVG, referring to the top-left corner of nearest SVG viewport vs. the center of the element in HTML.
+
By May 2022, the legacy SVG text rendering code was altered to be usable for LBSE as well. At this point, it made sense to run layout tests using LBSE. Previously most tests were expected to fail, as most either utilize text, paths, or shapes, and sometimes all three together. LBSE render tree text dumps (dumping the parsed render tree structure in a text file) were added for all tests in the LayoutTests/svg subdirectory, as well as a new pixel test baseline (screenshots of the rendering as PNGs), generated using the legacy SVG engine, to verify that LBSE produces pixel-accurate results. All upcoming LBSE patches are expected to change the expected layout test result baseline, and/or the TestExpectations file, depending on the type of patch. This will ease the reviewing process a lot for future patches.
+
To further proceed, a test-driven approach was used to prioritize the implementation of the missing functionality. At that time, missing viewBox support for outer <svg> elements was causing many broken tests. The effect of the transformation induced by the viewBox attribute, specified on outer <svg> elements, cannot be implemented as an additional CSS transformation applied to the outermost <svg> element, as that would affect the painted dimensions of the SVG document, which are subject to the CSS width/height properties and the size negotiation logic only. The viewBox attribute is supposed to only affect the visual appearance of the descendants, by establishing a new local coordinate system for them. The legacy SVG engine manually handled the viewBox-induced transformation in various places throughout LegacyRenderSVGRoot, to only affect the painting of the descendants and not e.g. the position/dimension of the border surrounding the <svg>, if the CSS border property is specified. In LBSE, transformations are handled on RenderLayer-level and not in the renderers anymore.
+
By July 2022, after testing different approaches, a proper solution to add viewBox support was upstreamed. The chosen solution makes use of another CSS concept that arises in the context of generated content: “anonymous boxes”. The idea is to wrap the direct descendants of RenderSVGRoot in an anonymous RenderSVGViewportContainer (“anonymous” = no associated DOM element) and apply the viewBox transformation as a regular CSS transformation on the anonymous renderer. With that approach, LBSE is left with just a single, unifiedviewBox implementation, without error-prone special cases in RenderSVGRoot, unlike the legacy SVG engine which has two disjoint implementations in LegacyRenderSVGViewportContainer and LegacyRenderSVGRoot.
+
After the summer holidays, in August 2022, the next major milestone was reached: enabling compositing support for arbitrary SVG elements, bringing z-index support, hardware-accelerated compositing and 3D transforms to SVG. This time all lessons learned from the previous LBSE prototypes were taken into account, resulting in a complete compositing implementation, that works in various scenarios: different transform-box / transform-origin combinations, inline SVG enclosed by absolute/relative positioned CSS boxes and many more, all way more polished than in the “final” LBSE prototype.
+
The aforementioned patch contained a fix for a long-standing bug (“Composited elements appear pixelated when scaled up using transform”), that made composited elements look blurry when scaling up with a CSS transform animation. The so-called “backing scale factor” of the associated GraphicLayers (see here for details about the role of GraphicLayer in the compositing system) never changes during the animation. Therefore, the rendered image was scaled up instead of re-rendering the content at the right scale. LBSE now enforces updates of that scale factor, to avoid blurry SVGs. The fix is not activated yet for HTML as that requires more thought - see the previously-linked bug report for details.
+
With all the new features in place and covered by tests, it was time to finish the remaining SVG renderers: RenderSVGEllipse, RenderSVGPath and RenderSVGViewportContainer (for inner <svg> elements), RenderSVGHiddenContainer, RenderSVGImage, and RenderSVGForeignObject. A proper <foreignObject> implementation was lacking in WebKit for 15+ years, due to the fundamental problem that the layer tree was not aware of the SVG subtree. The LBSE variant of RenderSVGForeignObject looks trivial, yet offers a fully compatible <foreignObject> implementation - for the first time without issues with non-static positioned content as a direct child of <foreignObject>, at least a few weeks later after it landed.
+
Returning to the test-driven approach, the next best target to fix was text rendering, which was working but not pixel-perfect. The legacy SVG engine takes into account the transformation from the text element up to the topmost renderer when computing the effective “on-screen” font size used to select a font for drawing/measuring, during layout time. LBSE needed a way to calculate the CTM for a given SVG renderer, up to a given ancestor renderer (or root), taking into account all possible transformation scenarios, including CSS transform, translate, rotate, SVG transform attribute, shifts due to transform-origin, perspective transformations, and much more. The same functionality is required to implement getCTM() / getScreenCTM().
+
By the end of August 2022, SVGLayerTransformComputation was added that re-used the existing mapLocalToContainer() / TranformState API to obtain the CTM. The CTM construction and ancestor chain walk - to accumulate the final transformation matrix - is performed by mapLocalToContainer() and no longer needs a special, incomplete SVG approach: the existing general approach now works for SVG too.
+
September 2022 was mostly devoted to bug fixes related to pixel-snapping. Outermost <svg> elements were not always enforcing stacking contexts and failed to align to device pixels. All other elements behaved fine with respect to pixel snapping (not applied for SVG elements) unless compositing layers were active. In that case, a RenderLayerBacking code path was used that unconditionally applied pixel-snapping - avoid that for SVG.
+
By October 2022 LBSE could properly display SVGs embedded into HTML host documents via <object> elements – the size negotiation logic failed to take into account the LBSE-specific renderers before. CSS background-image / list-image / HTML <img> / etc. were fixed as well. Zooming and panning support were implemented and improved compared to the legacy engine. Along the way an important bug was fixed, one that other browsers had already fixed back in 2014. The bug caused percentage-sized documents (e.g. width: 100%; height: 100%) that also specify a viewBox to always keep the document size, regardless of the zoom level. Thus, upon zooming, only the stroke width enlarged, but not the boundaries of the document, and thus scrollbars never appeared.
+
Over the following weeks, text-related issues had to be fixed, which were responsible for a bunch of the remaining test issues. Transformed text did not render, which turned out to be a simple mistake. More tests were upstreamed, related to compositing and transformations. More test coverage revealed that transform changes were not handled consistently – it took a period of investigation to land a proper fix. SVG transform / SMIL <animateMotion> / SMIL <animateTransform> / CSS transform changes are now handled consistently in LBSE, leading to proper repaints, as expected.
+
Transformation support can be considered complete and properly handled both during the painting and layout phases. Dynamic changes at runtime are correctly triggering invalidations. However, the Web-exposed SVG DOM API that allows querying the transformation matrices of SVG elements, such as getCTM() and getScreenCTM(), was still missing. By November 2022 a complete implementation was upstreamed, that utilized the new SVGLayerTransformComputation class to construct the desired transformation matrices. This way the same internal API is used for painting/layout/hit-testing and implementing the SVG DOM accessors.
+
By December 2022 LBSE was in a good shape: most important architectural changes were upstreamed and the most basic features were implemented. The year closed with a proposed patch that will avoid re-layout when an element’s transform changes. The legacy SVG engine always needs a re-layout if transform changes, as the size of each ancestor can depend on the presence of transformations on the child elements – a bad design decision two decades ago that LBSE will resolve. Only repainting should happen, but no layouts, in LBSE.
+
Let’s move on to 2023, and recap what’s still missing in LBSE.
+
Next steps
+
Besides fixing all remaining test regressions (see LayoutTests/platform/mac-ventura-wk2-lbse-text/TestExpectations) “SVG resources” are missing in LBSE. That includes all “paint servers” and advanced painting operations: there is no support for linear/radial gradients, no support for patterns, and no support for clipping/masking and filters.
+
From the painting capabilities, LBSE is still in a basic shape. However, this was intentional, since a lot of the existing code for SVG resource handling is no longer needed in LBSE. Clipping/masking and filters will be handled via RenderLayer, reusing the existing HTML/CSS implementations. Temporary ImageBuffers are no longer needed for clipping, and thus there is no need to cache the “per client” state in the resource system (e.g. re-using the cached clipping mask for repainting). This will simplify the implementation of the “SVG resources” a lot.
+
Therefore the first task in 2023 is to implement clipping, then masking, gradients, patterns, and as the last item, filters, since they require a substantial amount of refactoring in RenderLayerFilters.
+Note that these implementations are already complete in LBSE downstream and do not need to be invented from scratch. The first patches in that direction should be up for review by February 2023.
+
After all “SVG resources” are implemented in LBSE, feature parity is almost there and performance work will follow afterward. WebKit has a golden rule to never ship a performance regression; therefore, LBSE needs to be at least as fast in the standard performance tests, such as MotionMark, before it can replace the legacy engine. Currently, LBSE is slower than the legacy engine with respect to static rendering performance. Quoting numbers does not help at present, since the problem is well understood and will be resolved in the following months.
+
LBSE currently creates more RenderLayer objects than necessary: for each renderer, unconditionally. This is a great stress test of the layer system, and helpful for bootstrapping, but the associated overhead and complexity are simply not necessary for many cases, and actively hurt performance. LBSE already outperforms the legacy SVG engine whenever animated content is viewed, if it benefits from the hardware acceleration in LBSE.
+
2023 will be an exciting year, and hopefully brings LBSE to the masses, stay tuned!
+
Demos
+
“A picture is worth a thousand words”, so we’d like to share with you the videos shown during the WebKit contributors meeting in 2022 that demo the LBSE capabilities. Be sure to check them out so you can get a good picture of the state of the work. Enjoy!
We at Igalia are doing our best to fulfill the mission and complete the LBSE upstreaming as fast as possible. In the meanwhile, let us know about your thoughts:
+
+
What would you do with a performant, next-level SVG engine?
+
Any particular desktop / embedded project that would benefit from it?
+
Anything in reach now, that seemed impossible before with the given constraints in WebKit?
I'm a proud Igalian since 2019 and have been working on WebKits predecessors since the early 2000s, namely kjs/khtml/ksvg, and kdom/kcanvas/ksvg2/khtml2 that all found their way into WebKit. Since that time, Web technology - especially SVG - is my main area of interest.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Integrating WPE: URI Scheme Handlers and Script Messages
+
+
+
+
+
+
+
+
+
+
Most Web content is designed entirely for screen display—and there is a
+lot of it—so it will spend its life in the somewhat restricted sandbox
+implemented by a web browser. But rich user interfaces using Web technologies
+in all kinds of consumer devices require some degree of integration, an
+escape hatch to interact with the rest of their software and hardware. This is
+where a Web engine like WPE designed to be embeddable shines: not only does
+WPE provide a stable API, it is also comprehensive in
+supporting a number of ways to integrate with its environment further than
+the plethora of available Web platform APIs.
+
Integrating a “Web view” (the main entry point of the WPE embedding
+API) involves providing extension points, which allow the
+Web content (HTML/CSS/JavaScript) it loads to call into native code provided
+by the client application (typically written in C/C++) from JavaScript, and
+vice versa. There are a number of ways in which this can be achieved:
+
+
URI scheme handlers allow native code to
+register a custom URI
+scheme, which will run a user provided
+function to produce content that can be “fetched” regularly.
+
User script messaging can be used to send JSON
+messages from JavaScript running in the same context as Web pages to an user
+function, and vice versa.
+
The JavaScriptCore API is a powerful solution to provide new JavaScript
+functionality to Web content seamlessly, almost as if they were implemented
+inside the Web engine itself—akin to NodeJS C++ addons.
+
+
In this post we will explore the first two, as they can support many
+interesting use cases without introducing the additional complexity of
+extending the JavaScript virtual machine. Let’s dive in!
+
Intermission
+
We will be referring to the code of a tiny browser written for the occasion.
+Telling WebKit how to call our native code involves creating a
+WebKitUserContentManager, customizing it, and then
+associating it with web views during their creation. The only exception to
+this are URI scheme handlers, which are registered
+using webkit_web_context_register_uri_scheme(). This
+minimal browser includes an on_create_view function, which is the perfect
+place to do the configuration:
+
+ What is g_autoptr?
+ Does it relate to g_steal_pointer?
+ This does not look like C!
+
In the shown code examples, g_autoptr(T) is a preprocessor macro provided by
+GLib that declares a pointer variable of the T type, and arranges for
+freeing resources automatically when the variable goes out of scope. For
+objects this results in
+g_object_unref()
+being called.
+
Internally the macro takes advantage of the __attribute__((cleanup, ...))
+compiler extension, which is supported by GCC and Clang. GLib also includes a
+convenience
+macro that
+can be used to define cleanups for your own types.
+
As for g_steal_pointer, it is useful to indicate that the ownership of a
+pointer declared with g_autoptr is transferred outside from the current
+scope. The function returns the same pointer passed as parameter and
+resets it to NULL, thus preventing cleanup functions from running.
+
+
The size has been kept small thanks to reusing code from the Cog
+core library. As a bonus, it should
+run on Wayland, X11, and even on a bare display using the DRM/KMS
+subsystem directly. Compiling and running it, assuming you already have the
+dependencies installed, should be as easy as running:
+
cc -o minicog minicog.c $(pkg-config cogcore --libs--cflags)
+./minicog wpewebkit.org
+
If the current session kind is not automatically detected, a second parameter
+can be used to manually choose among wl (Wayland), x11, drm, and so on:
+
./minicog wpewebkit.org x11
+
The full, unmodified source for this minimal browser is included right below.
+
+
+ URI syntax (CC BY-SA 4.0,
+ source),
+ notice the “scheme” component at the top left.
+
+
+
A URI scheme handler allows “teaching” the web engine how to handle any
+load (pages, subresources, the Fetch API,
+XmlHttpRequest, …)—if you ever wondered how Firefox implements
+about:config or how Chromium does chrome://flags, this is it. Also,
+WPE WebKit has public API for this. Roughly:
When WebKit detects a load for the scheme, it invokes the provided
+function, passing a
+WebKitURISchemeRequest.
+
The function generates data to be returned as the result of the load,
+as a GInputStream
+and calls webkit_uri_scheme_request_finish(). This sends the stream to WebKit as the
+response, indicating the length of the response (if known), and the
+MIME content type of the data in the stream.
+
WebKit will now read the data from the input stream.
+
+
Echoes
+
Let’s add an echo handler to our minimal browser that
+replies back with the requested URI. Registering the scheme is
+straightforward enough:
The userdata parameter above is a convention used in many C libraries, and
+specially in these based on GLib when there are callback functions involved.
+It allows the user to supply a pointer to arbitrary data, which will be
+passed later on as a parameter to the callback (handle_echo_request in the
+example) when it gets invoked later on.
+
As for the destroy_notify parameter, it allows passing a function with the
+signature void func(void*) (type
+GDestroyNotify) which
+is invoked with userdata as the argument once the user data is no longer
+needed. In the example above, this callback function would be invoked when the
+URI scheme is unregistered. Or, from a different perspective, this callback is
+used to notify that the user data can now be destroyed.
+
+
One way of implementing handle_echo_request() could be wrapping the request
+URI, which is part of the WebKitURISchemeRequest parameter to the handler,
+stash it into a GBytes
+container, and create an input stream to read back its
+contents:
With these changes, it is now possible to make page loads from the new custom
+URI scheme:
+
+
+ It worked!
+
+
Et Tu, CORS?
+
The main roadblock one may find when using custom URI schemes is that loads
+are affected by CORS
+checks. Not only that, WebKit by default does not allow sending cross-origin
+requests to custom URI schemes. This is by design: instead of accidentally
+leaking potentially sensitive data to websites, developers embedding a web
+view need to consciously opt-in to allow CORS requests and
+send back suitable Access-Control-Allow-* response headers.
+
In practice, the additional setup involves
+retrieving
+the WebKitSecurityManager being used by the WebKitWebContext and
+registering the scheme as
+CORS-enabled.
+Then, in the handler function for the custom URI scheme, create a
+WebKitURISchemeResponse,
+which allows fine-grained control of the response, including setting
+headers,
+and finishing the request instead with
+webkit_uri_scheme_request_finish_with_response().
+
Note that WebKit cuts some corners when using CORS with custom URI schemes:
+handlers will not receive preflight OPTIONS requests. Instead, the CORS
+headers from the replies are inspected, and if access needs to be denied
+then the data stream with the response contents is discarded.
+
In addition to providing a complete CORS-enabled custom URI scheme example,
+we recommend the Will It CORS? tool
+to help troubleshoot issues.
+
Further Ideas
+
Once we have WPE WebKit calling into our custom code, there are no limits
+to what a URI scheme handler can do—as long as it involves replying
+to requests. Here are some ideas:
+
+
Allow pages to access a subset of paths from the local file system in a
+controlled way (as CORS applies). For inspiration,
+see CogDirectoryFilesHandler.
+
Package all your web application assets into a single ZIP file, making
+loads from app:/... fetch content from it. Or, make the scheme handler
+load data using GResource and bundle the application
+inside your program.
+
Use the presence of a well-known custom URI to have a web application
+realize that it is running on a certain device, and make its user
+interface adapt accordingly.
+
Provide a REST API, which internally calls into
+NetworkManager to list and configure
+wireless network adapters. Combine it with a local web application and
+embedded devices can now easily get on the network.
+
+
User Script Messages
+
While URI scheme handlers
+allow streaming large chunks of data back into the Web engine, for exchanging
+smaller pieces of information in a more programmatic fashion it may be
+preferable to exchange messages without the need to trigger resource loads.
+The user script messages part of the
+WebKitUserContentManager API can be used this way:
Associate a callback to the
+script-message-received
+signal. The signal detail should be the name of the registered handler.
+
Now, whenever JavaScript code calls
+window.webkit.messageHandlers.<name>.postMessage(), the signal is
+emitted, and the native callback functions invoked.
+
+
+ Haven't I seen postMessage() elsewhere?
+
Yes,
+you
+have.
+The name is the same because it provides a similar functionality (send a
+message), it guarantees little (the receiver should validate messages), and
+there are similar
+restrictions
+in the kind of values that can be passed along.
+
+
It’s All JavaScript
+
Let’s add a feature to our minimal browser that will allow
+JavaScript code to trigger rebooting or powering off the device where it is
+running. While this should definitely not be functionality exposed to the
+open Web, it is perfectly acceptable in an embedded device where we control
+what gets loaded with WPE, and that exclusively uses a web application as its
+user interface.
+
+
+ Yet most of the code shown in this post is C.
+
+
First, create a WebKitUserContentManager, register the message handler,
+and connect a callback to its associated signal:
The callback receives a WebKitJavascriptResult, from which we
+can get the JSCValue with the contents of the parameter
+passed to the postMessage() function. The JSCValue can now be inspected
+to check for malformed messages and determine the action to take, and
+then arrange to call reboot():
Note that the reboot() system call above will most likely fail because it
+needs administrative privileges. While the browser process could run as root
+to sidestep this issue—definitely not recommended!—it would be
+better to grant the CAP_SYS_BOOT capability to the process, and much
+better to ask the system manager daemon to handle the job. In machines
+using systemd a good option is to call the .Halt()
+and .Reboot() methods of its org.freedesktop.systemd1 interface.
+
Now we can write a small HTML document with some JavaScript sprinkled on top
+to arrange sending the messages:
The complete source code for this example can be found
+in this Gist.
+
Going In The Other Direction
+
But how can one return values from user messages back to the JavaScript code
+running in the context of the web page? Until recently, the only option
+available was exposing some known function in the page’s JavaScript code, and
+then using
+webkit_web_view_run_javascript()
+to call it from native code later on. To make this more idiomatic and allow
+waiting on a Promise, an approach like the following works:
+
+
Have convenience JavaScript functions wrapping the calls to
+.postMessage() which add an unique identifier as part of the message,
+create a Promise, and store it in a Map indexed by the identifier.
+The Promise is itself returned from the functions.
+
When the callback in native code handle messages, they need to take
+note of the message identifier, and then use
+webkit_web_view_run_javascript() to pass it back, along with the
+information needed to resolve the promise.
+
The Javascript code running in the page takes the Promise from
+the Map that corresponds to the identifier, and resolves it.
+
+
To make this approach a bit more palatable, we could tell WebKit to inject a
+script
+along with the regular content, which would provide the helper
+functions
+needed to achieve this.
+
Nevertheless, the approach outlined above is cumbersome and can be
+tricky to get right, not to mention that the effort needs to be duplicated in
+each application. Therefore, we have recently added new API hooks to provide this
+as a built-in feature, so starting in WPE WebKit 2.40 the recommended approach
+involves using
+webkit_user_content_manager_register_script_message_handler_with_reply()
+to register handlers instead. This way, calling .postMessage() now returns a
+Promise to the JavaScript code, and the callbacks connected to the
+script-message-with-reply-received
+signal now receive a
+WebKitScriptMessageReply,
+which can be used to resolve the promise—either on the spot, or
+asynchronously later on.
+
Even More Ideas
+
User script messages are a powerful and rather flexible facility to make WPE
+integrate web content into a complete system. The provided example is rather
+simple, but as long as we do not need to pass huge amounts of data in
+messages the possibilities are almost endless—especially with the
+added convenience in WPE WebKit 2.40. Here are more ideas that can
+be built on top of user script messages:
+
+
A handler could receive requests to “monitor” some object, and
+return a Promise that gets resolved when it has received changes.
+For example, this could make the user interface of a smart thermostat
+react to temperate updates from a sensor.
+
A generic handler that takes the message payload and converts it into
+D-Bus method calls, allowing
+web pages to control many aspects of a typical Linux system.
+
+
Wrapping Up
+
WPE has been designed from the ground up to integrate with the rest of the
+system, instead of having a sole focus on rendering Web content inside a
+monolithic web browser application. Accordingly, the public API must be
+comprehensive enough to use it as a component of any application. This
+results in features that allow plugging into the web engine at different
+layers to provide custom behaviour.
+
At Igalia we have years of experience embedding WebKit into all kinds of
+applications, and we are always sympathetic to the needs of such systems. If
+you are interested collaborating with WPE development, or searching for a
+solution that can tightly integrate web content in your device, feel free to
+contact us.
+
+
+
+
+
+
+
+
+
+
+
+ This article was written by Adrián Pérez.
+
+ I have been working on WebKit since 2012, with a focus on
+ environment integration, embedding, and distribution. Igalia
+ has been a life-long project since even earlier.
+
+
+
+
+
+
+
+
+
+
+
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Depending on the target hardware WPE may need to use different techniques and
+technologies to ensure correct graphical rendering. To be independent of any
+user-interface toolkit and windowing system, WPE WebKit delegates the rendering
+to a third-party API defined in the
+libwpe library. A concrete
+implementation of this API is a “WPE backend”.
+
WPE WebKit is a multiprocess application, the end-user starts and controls the
+web widgets in the application process (which we often call “the UI process” while the web engine itself uses
+different subprocesses: WPENetworkProcess is in charge of managing network
+connections and WPEWebProcess (or “web process”) in charge of the HTML and
+JavaScript parsing, execution and rendering. The WPE backend is at a crossroads
+between the UI process and one or more web process instances.
The WPE backend is a shared library that is loaded at runtime by the web
+process and by the UI process. It is used to render the visual aspect of a web
+page and transfer the resulting video buffer from the web process to the
+application process.
+
Backend Interfaces
+
The WPE backend shared library must export at least one symbol called
+_wpe_loader_interface of type struct wpe_loader_interface as defined in
+the libwpe
+API.
+Presently its only member is load_object, a callback function that receives a
+string with an interface name and returns concrete implementations of the
+following interfaces:
The names passed to the .load_object() function are the same as those of the
+interface types, prefixed with an underscore. For example, a
+.load_object("_wpe_renderer_host_interface") call must return a pointer to a
+struct wpe_renderer_host_interface object.
+
+ Example C code for a load_object callback.
+
+
Each of these interfaces follow the same base structure: the struct members
+are callback functions, all interfaces have create and destroy members which
+act as instance constructor and destructor, plus any additional “methods”.
+The pointer returned by the create callback will be passed as the object
+“instance” of the other methods:
One “renderer host” instance, using wpe_renderer_host_interface.create().
+
Multiple “renderer host client” instances, using wpe_renderer_host_interface.create_client().
+These are mainly used for IPC communication, one instance gets created for
+each web process launched by WebKit.
+
Multiple “view backend” instances, using wpe_view_backend_interface.create().
+One instance is created for each rendering target in the web process.
+
+
In each web process—there can be more than one—WPE WebKit
+will create:
+
+
One “renderer backend EGL” instance, using wpe_renderer_backend_egl_interface.create().
+
Multiple “renderer backend EGL target” instances, using
+wpe_renderer_backend_egl_target_interface.create(). An instance is created
+for each new rendering target needed by the application.
+
+
+ How about wpe_renderer_backend_egl_offscreen_target_interface?
+
+
The rendererBackendEGLTarget instances may be created by the wpe_renderer_backend_egl_target_interface, or
+the wpe_renderer_backend_egl_offscreen_target_interface depending on the interfaces implemented in the backend.
+
Here we are only focusing on the wpe_renderer_backend_egl_target_interface that is relying on a classical EGL
+display (defined in the rendererBackendEGL instance). The wpe_renderer_backend_egl_offscreen_target_interface may
+be used in very specific use-cases that are out of the scope of this post. You can check its usage in the WPE WebKit
+source code
+for more information.
+
+
+
These instances typically communicate with each others using Unix sockets for
+IPC. The IPC layer must be
+implemented in the WPE backend itself because the libwpe interfaces only pass
+around the file descriptors to be used as communication endpoints.
+
From a topological point of view, all those instances are organized as follows:
The rendererHost and rendererHostClient instances are only used to manage
+IPC endpoints on the UI process side that are connected to each running
+web process. They are not used by the graphical rendering system.
+
The rendererBackendEGL instance (one per web process) is only used to
+connect to the native display for a specific platform. For example, on a
+desktop Linux, the platform may be X11 where the native display would be the
+result of calling XOpenDisplay(); or the platform may be Wayland and in
+this case the native display would be the result of calling
+wl_display_connect(); and so on.
+
The rendererBackendEGLTarget (on the web process side) and viewBackend
+(on the UI process side) instances are the ones truly managing the web page
+graphical rendering.
+
+
Graphics Rendering
+
As seen above, the interfaces in charge of the rendering are
+wpe_renderer_backend_egl_target_interface and wpe_view_backend_interface.
+During their creation, WPE WebKit exchanges the file descriptors used to
+establish a direct IPC connection between a rendererBackendEGL (in the
+web process), and a viewBackend (in the UI process).
+
During the EGL initialization phase, when a new web process is launched, WebKit
+will use the native display and platform provided by the
+wpe_renderer_backend_egl_interface.get_native_display() and .get_platform()
+functions to create a suitable OpenGL ES context.
+
When WebKit’s
+ThreadedCompositor
+is ready to render a new frame (in the web process), it calls the
+wpe_renderer_backend_egl_target_interface.frame_will_render() function to let
+the WPE backend know that rendering is about to start. At this moment, the
+previously created OpenGL ES context is made current to be used as the target
+for GL drawing commands.
+
Once the threaded compositor has finished drawing, it will swap the front and
+back EGL buffers and call the
+wpe_renderer_backend_egl_target_interface.frame_rendered() function to signal
+that the frame is ready. The compositor will then wait until the WPE backend
+calls wpe_renderer_backend_egl_target_dispatch_frame_complete() to indicate
+that the compositor may produce a new frame.
+
What happens inside the .frame_will_render() and .frame_rendered()
+implementations is up to the WPE backend. As en example, it could
+set up a Frame Buffer Object
+to have the web content draw offscreen, in a texture that can be passed
+back to the UI process for further processing, or use extensions like
+EGLStream,
+or DMA-BUF exports
+to transfer the frame to the UI process without copying the pixel data.
Typically the backend sends each new frame to the corresponding view backend in
+in its .frame_rendered() function. The application can use the frame until it
+sends back an IPC message to the renderer target (in the web
+process) to indicate that the frame is not in use anymore and may be be freed
+or recycled. Although it is not a requirement to do it at this exact point,
+usually when a renderer backend receives this message it calls the
+wpe_renderer_backend_egl_target_dispatch_frame_complete() function to trigger
+the rendering of a new frame. As a side effect, this mechanism also allows
+controlling the pace at which new frames are produced.
+
Using EGLStream
+
EGLStream is an EGL extension that defines a mechanism to transfer hardware
+video buffers from one process to another efficiently, without getting them
+out of GPU memory. Although the extension is supported only in Nvidia
+hardware, it makes for a good example as it transparently handles some
+complexities involved, like buffers with multiple planes.
+
This backend uses the EGLStream extension to transfer graphics buffers from the
+web process, which acts as a producer, to the UI process acting as a consumer.
+The producer extension
+EGL_KHR_stream_producer_eglsurface
+allows creating a surface that may be used as target for rendering, then using
+eglSwapBuffers()
+finishes drawing and sends the result to the consumer. Meanwhile, in the
+consumer side, the
+EGL_NV_stream_consumer_eglimage
+extension is used to turn each buffer into an EGLImage.
+
The reference source code for this WPE backend is available in the
+WPEBackend-offscreen-nvidia
+repository, which has been tested with WPE WebKit 2.38.x or 2.40.x, and
+libwpe version 1.14.x.
+
+ Behold, the Future Belongs to DMA-BUF!
+
+
With the growing adoption of
+DMA-BUF for sharing memory
+buffers on modern Linux platforms, the WPE WebKit architecture will be
+evolving and, in the future, the need for a WPE Backend should disappear in
+most cases.
+
Ongoing work on WPE WebKit removes the need to provide a WPE backend
+implementation for most hardware platforms, with a generic implementation
+using DMA-BUF provided as an integral, built-in feature of WebKit. It will
+still be possible to provide external implementations for platforms that
+might need to use custom buffer sharing mechanisms.
+
From the application developer point of view, in most cases writing
+programs that use the WPE WebKit API will be simpler, with the complexity
+of the communication among multiple processes handled by WebKit.
+
+
+
Stream Setup
+
The steps needed to set up EGLStream endpoints need to be done in a particular
+order:
The EGL_STREAM_FIFO_LENGTH_KHR parameter defines the length of the EGLStream
+queue. If set to zero, the stream will work in “mailbox” mode and each time the
+producer has a new frame it will empty the stream content and replace the frame
+by the new one. If non-zero, the stream works work in “FIFO” mode, which means that the stream queue can contain up
+to EGL_STREAM_FIFO_LENGTH_KHR frames.
+
Here we configure a queue for one frame because in this case the specification
+of EGL_KHR_stream_producer_eglsurface guarantees that calling
+eglSwapBuffers() on the producer the call will block until the consumer
+retires the previous frame from queue. This is used as implicit synchronization
+between the UI process side and the web process side without needing to rely on
+custom IPC, which would add a small delay between frames.
+
The EGL_CONSUMER_ACQUIRE_TIMEOUT_USEC_KHR parameter defines the maximum
+timeout in microseconds to wait on the consumer side to acquire a frame when
+calling eglStreamConsumerAcquireKHR(). It is only used with the
+EGL_KHR_stream_consumer_gltexture extension because the
+EGL_NV_stream_consumer_eglimage extension allows setting a timeout on each
+call to eglQueryStreamConsumerEventNV() function.
+
Second, to initialize the consumer using the EGL_NV_stream_consumer_eglimage
+extension it is enough to call the eglStreamImageConsumerConnectNV() function.
+
Once the consumer has been initialized, you need to send the EGLStream
+file descriptor to the producer process. The usual way of achieving this would
+be using IPC between the two processes, sending the file descriptor in a
+SCM_RIGHTS message through an Unix socket—although with recent kernels
+using pidfd_getfd() may be an option if
+both processes are related.
+
When the file descriptor is finally received, the producer endpoint can be
+created using the EGL_KHR_stream_producer_eglsurface extension:
As with pbuffer surfaces, the dimensions
+need to be specified as surface attributes. When picking a frame buffer
+configuration with eglChooseConfig() the EGL_SURFACE_TYPE attribute must
+be set to EGL_STREAM_BIT_KHR. From this point onwards, rendering proceeds as
+usual: the EGL surface and context are made active, and once the painting is
+done a call to eglSwapBuffers() will “present” the frame, which in this case
+means sending the buffer with the pixel data down the EGLStream to the
+consumer.
While on the producer side rendering treats the EGLStream surface like any
+other, on the consumer some more work is needed to manager the lifetime of
+the data received: frames have to be manually acquired and released once
+they are not needed anymore.
+
The producer calls eglQueryStreamConsumerEventNV() repeatedly to retire the
+next event from the stream:
+
+
EGL_STREAM_IMAGE_ADD_NV indicates that there is a buffer in the stream
+that has not yet been bound to an EGLImage, and the application needs to
+create a new one to which the actual data will be bound later.
+
EGL_STREAM_IMAGE_AVAILABLE_NV indicates that a new frame is available
+and that it can be bound to the previously created EGLImage.
+
EGL_STREAM_IMAGE_REMOVE_NV indicates that a buffer has been retired from
+the stream, and that its associated EGLImage may be released once the
+application has finished using it.
+
+
This translates roughly to the following code:
+
staticconstexpr EGLTime MAX_TIMEOUT_USEC =1000*1000;
+EGLImage eglImage = EGL_NO_IMAGE;
+
+while(true){
+ EGLenum event =0;
+ EGLAttrib data =0;
+
+ // WARNING: The specification states that the timeout is in nanoseconds
+ // (see: https://registry.khronos.org/EGL/extensions/NV/EGL_NV_stream_consumer_eglimage.txt)
+ // but in reality it is in microseconds, at least with the version 535.113.01 of the NVidia drivers.
+ if(!eglQueryStreamConsumerEventNV(display, eglStream, MAX_TIMEOUT_USEC,&event,&data))
+ break;
+
+ switch(event){
+ case EGL_STREAM_IMAGE_ADD_NV:// Bind an incoming buffer to an EGLImage.
+ if(eglImage)eglDestroyImage(display, eglImage);
+ eglImage =eglCreateImage(display, EGL_NO_CONTEXT, EGL_STREAM_CONSUMER_IMAGE_NV,
+ static_cast<EGLClientBuffer>(eglStream),nullptr);
+ continue;// Handle the next event.
+
+ case EGL_STREAM_IMAGE_REMOVE_NV:// Buffer removed, EGLImage may be disposed.
+ if(data){
+ EGLImage image =reinterpret_cast<EGLImage>(data);
+ eglDestroyImage(display, image);
+ if(image == eglImage)
+ eglImage = EGL_NO_IMAGE;
+ }
+ continue;// Handle the next event.
+
+ case EGL_STREAM_IMAGE_AVAILABLE_NV:// New frame available.
+ if(eglStreamAcquireImageNV(display, eglStream,&eglImage, EGL_NO_SYNC))
+ break;
+
+ default:
+ continue;// Handle the next event.
+ }
+
+ /*** Use the EGLImage here ***/
+
+ eglStreamReleaseImageNV(display, eglStream, eglImage, EGL_NO_SYNC);
+}
+
The application is free to use each EGLImage as it sees fit. An obvious
+example would be to use it as the contents for a texture, which then gets
+painted in the “content” area of a web browser; or as the contents of the
+screen for an in-game computer that the player can interact with, enabling
+display of real, live web content as part of the gaming experience—now
+that would be a deeply embedded browser!
+
One Last Thing
+
There is a small showstopper to have EGLStream support working:
+currently
+when WPE WebKit uses surfaceless EGL contexts it sets the surface type to
+EGL_WINDOW_BIT attribute, while EGL_STREAM_BIT_KHR would be needed
+instead. A small
+patch
+is enough to apply this tweak:
+
+ This article was written by Loïc Le Page.
+
+ I have worked in different industries like video games,
+ cinema, and multimedia—the latter being where my
+ focus lies at the moment. Did anyone say Web engines need
+ that, too?
+
+
+
+
+
+
+
+
+
+
+
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Don’t miss any news related to WPE – our blog aims to share information regarding WPE: explainers, how-to articles and general information regarding WPE, WebKit
+and the Web platform. Also check out the official WebKit blog regarding news on the engine itself.
In the previous posts, my colleagues Claudio and Miguel wrote respectively about the major components of the project and, specifically, the graphics architecture of WPE. Today, you'll see our efforts to improve the quality of both WPE and the experience of working and using it.
Following the previous post in the series about WPE where we talked about the WPE components, this post will explain briefly the WPE graphics architecture, and how the engine is able to render HTML content into the display.
In the previous post in this series, we explained that WPE is a WebKit port optimized for embedded devices. In this post, we'll dive into a more technical overview of the different components of WPE, WebKit, and how they all fit together.
Welcome to the new Blog section on wpewebkit.org! Let's take some time to celebrate and recap how WPE evolved from the early prototyping days to the product empowering hundreds of millions of devices worldwide today.
+
+
+
+
+
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
WPE WebKit brought RDK (Reference Design Kit), a modern, performant web browser, to millions of screens. It enables operators to manage devices and easily customize their UIs and apps and provides analytics to improve the customer experience and drive business results.
+
Delivering a fast and memory-efficient browser for embedded systems is a challenging task, so Igalia helped Metrological build a new full-screen browser engine which stripped away all unnecessary toolkit elements.
+
With years of experience around WebKit platform integration, Igalia worked to produce a new WebKit port, WPE, which interfaced directly with Wayland and the graphics driver. Additionally, Igalia pushed forward the implementation of a multi-platform multi-threaded compositor, enabling better performance on low-end multicore processors. WPE is an official port of WebKit.
+
+
+
+
+
+
+
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+
+
\ No newline at end of file
diff --git a/aperezdc/learn-discover-rework/blog/2023-use-case-digital-signage.html b/aperezdc/learn-discover-rework/blog/2023-use-case-digital-signage.html
new file mode 100644
index 000000000..377294151
--- /dev/null
+++ b/aperezdc/learn-discover-rework/blog/2023-use-case-digital-signage.html
@@ -0,0 +1,291 @@
+
+
+
+
+
+
+
+
+
+
+
+ Use Case: WPE in digital signage
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Use Case: WPE in digital signage
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Digital signage web rendering players have many advantages and are a trend nowadays. They allow to use HTML5 for composing the UI, provisioning and scheduling new contents to the screens from the cloud is simple and effortless, they provide a robust environment with an automatic crash recovery system, etc. They are also a great choice for digital signage kiosk deployments.
+
WPE WebKit is an excellent option to use as web rendering engine for Linux-based digital signage players, specially for the low-end market, where WPE Webkit allows to achieve great graphics and rendering performance in the less powerful devices like the ones based on the Raspberry Pi. As a result, WPE WebKit is naturally compatible with the hardware of the main digital signage manufactures that rely on these kind of lower-powered devices.
+
+
+
+
+
+
+
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
In many distributed applications, it can be useful to run a light web browser on the server side to render some HTML content or process images, video and/or audio using JavaScript.
+
Some concrete use-cases can be:
+
+
Video post-production using HTML overlays.
+
Easy 3D rendering with WebGL that can be broadcasted as a video stream.
+
Reusing the same JavaScript code between a frontend web application and the backend processing.
+
+
WPE WebKit is the perfect solution for all those use cases as it offers a lightweight solution which can run on low-end hardware or even within a container. It provides a lot of flexibility at the moment of choosing the backend infrastructure as WPE WebKit can, for instance, run from within a container with a very minimal Linux configuration (no need for any windowing system) and with full hardware acceleration and zero-copy of the video buffers between the GPU and the CPU.
+
Additionally, the fact that WPE WebKit is optimized for lower-powered devices, makes it also the perfect option for server-side rendering when scaling commercial deployments while keeping cost under control, which is yet another important factor to take into account when considering cloud rendering.
+
+
+
+
+
+
+
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Don’t miss any news related to WPE – our blog aims to share information regarding WPE: explainers, how-to articles and general information regarding WPE, WebKit
+and the Web platform. Also check out the official WebKit blog regarding news on the engine itself.
WPE backends allow adapting the web engine to the particularities of
+the graphics stack of the devices where it needs to run. In this article
+we cover their basics and build a WPE WebKit backend from scratch.
This post explores some of the ways in which WPE WebKit can integrate with
+its surrounding environment, in order to expose platform functionality to
+Web content seamlessly.
Let's take a detour from the previous WPE architecture related posts to other aspects of our work on WebKit at Igalia. Today, the status of the development of WebKits' new SVG engine is presented, along with an introduction to the topic, and an outlook for 2023.
WPE WebKit brought RDK (Reference Design Kit), a modern, performant web browser, to millions of screens.
+
+
+
+
+
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
While there are several simple ways for developers to experiment with and explore WPE, none are tuned for performance. Generally, shipping products for embedded systems are performance-tuned custom builds. To make this easier, there is also meta-webkit, which provides build recipes, WebKit based runtimes, and browsers for use with OpenEmbedded and/or Yocto.
There are two feature releases every year, typically in March and September.
+
Within feature releases, there may be any number of bug-fixes.
+
Development releases are the base for the feature releases that follow them. They do not follow a fixed schedule in the release cycle.
+
+
WPE WebKit and WebKitGTK share a fair amount of code. Therefore, both projects produce their feature releases simultaneously, and share the same release branches. For bug-fix releases, the release teams for both projects try to sync their version numbers as well as they can.
WPE is the official WebKit port for Linux-based embedded platforms. WPE is uniquely designed for embedded systems in that it doesn’t depend on any user-interface toolkits such as the traditional Cocoa, GTK, etc toolkits.
We've been collecting answers to lots of common questions we've been asked. If you've got questions, you might just find a ready answer in the FAQ.
+
+
+
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/aperezdc/learn-discover-rework/feed.xml b/aperezdc/learn-discover-rework/feed.xml
new file mode 100644
index 000000000..8169a849d
--- /dev/null
+++ b/aperezdc/learn-discover-rework/feed.xml
@@ -0,0 +1,675 @@
+
+
+ WPEwebkit.org
+ Release announcements and security advisories from WPEwebkit.org.
+
+
+ 2024-02-26T00:00:00Z
+ https://wpewebkit.org/
+
+
+ Cog 0.18.3 released
+
+ 2024-02-26T00:00:00Z
+ https://wpewebkit.org/wpewebkit.org/aperezdc/learn-discover-rework/release/cog-0.18.3.html
+ <p>This is a bug fix release in the stable 0.18 series.</p>
+<h3 id="what%E2%80%99s-new-in-cog-0.18.3%3F" tabindex="-1">What’s new in Cog 0.18.3?</h3>
+<ul>
+<li>drm: Fix handling of the scaling factor setting.</li>
+<li>gtk4: Take scaling factor into account for pointer events.</li>
+<li>launcher: Support toggling WebKit features with a new <code>--features</code>/<code>-F</code> command
+line option, when built against WebKit 2.42.0 or newer.</li>
+</ul>
+<h4 id="checksums" tabindex="-1">Checksums</h4>
+<pre>
+cog-0.18.3.tar.xz (123.9 KiB)
+ md5sum: e457de5b5ac8994ae9971c0a5a22b8a2
+ sha1sum: 21df2a84c651b45e78d08e45e71631250a0078c3
+ sha256sum: cd4ec937175a290ccd7c8ec398e4569aec04084cd94b11b2d83518778ba9d055
+</pre>
+
+
+
+
+ WebKitGTK and WPE WebKit Security Advisory WSA-2024-0001
+
+ 2024-02-05T00:00:00Z
+ https://wpewebkit.org/wpewebkit.org/aperezdc/learn-discover-rework/security/WSA-2024-0001.html
+ <ul>
+<li>
+<p>Date Reported: <strong>February 05, 2024</strong></p>
+</li>
+<li>
+<p>Advisory ID: <strong>WSA-2024-0001</strong></p>
+</li>
+<li>
+<p>CVE identifiers: <a href="https://wpewebkit.org/wpewebkit.org/aperezdc/learn-discover-rework/security/WSA-2024-0001.html#CVE-2024-23222">CVE-2024-23222</a>, <a href="https://wpewebkit.org/wpewebkit.org/aperezdc/learn-discover-rework/security/WSA-2024-0001.html#CVE-2024-23206">CVE-2024-23206</a>,
+<a href="https://wpewebkit.org/wpewebkit.org/aperezdc/learn-discover-rework/security/WSA-2024-0001.html#CVE-2024-23213">CVE-2024-23213</a>, <a href="https://wpewebkit.org/wpewebkit.org/aperezdc/learn-discover-rework/security/WSA-2024-0001.html#CVE-2023-40414">CVE-2023-40414</a>,
+<a href="https://wpewebkit.org/wpewebkit.org/aperezdc/learn-discover-rework/security/WSA-2024-0001.html#CVE-2023-42833">CVE-2023-42833</a>, <a href="https://wpewebkit.org/wpewebkit.org/aperezdc/learn-discover-rework/security/WSA-2024-0001.html#CVE-2014-1745">CVE-2014-1745</a>.</p>
+</li>
+</ul>
+<p>Several vulnerabilities were discovered in WebKitGTK and WPE WebKit.</p>
+<ul>
+<li>
+<p><a name="CVE-2024-23222" href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-23222">CVE-2024-23222</a></p>
+<ul>
+<li>Versions affected: WebKitGTK and WPE WebKit before 2.42.5.</li>
+<li>Credit to Apple.</li>
+<li>Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Apple is aware of a report that this issue
+may have been exploited. Description: A type confusion issue was
+addressed with improved checks.</li>
+<li>WebKit Bugzilla: 267134</li>
+</ul>
+</li>
+<li>
+<p><a name="CVE-2024-23206" href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-23206">CVE-2024-23206</a></p>
+<ul>
+<li>Versions affected: WebKitGTK and WPE WebKit before 2.42.5.</li>
+<li>Credit to An anonymous researcher.</li>
+<li>Impact: A maliciously crafted webpage may be able to fingerprint the
+user. Description: An access issue was addressed with improved
+access restrictions.</li>
+<li>WebKit Bugzilla: 262699</li>
+</ul>
+</li>
+<li>
+<p><a name="CVE-2024-23213" href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-23213">CVE-2024-23213</a></p>
+<ul>
+<li>Versions affected: WebKitGTK and WPE WebKit before 2.42.5.</li>
+<li>Credit to Wangtaiyu of Zhongfu info.</li>
+<li>Impact: Processing web content may lead to arbitrary code execution.
+Description: The issue was addressed with improved memory handling.</li>
+<li>WebKit Bugzilla: 266619</li>
+</ul>
+</li>
+<li>
+<p><a name="CVE-2023-40414" href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-40414">CVE-2023-40414</a></p>
+<ul>
+<li>Versions affected: WebKitGTK and WPE WebKit before 2.42.1.</li>
+<li>Credit to Francisco Alonso (@revskills).</li>
+<li>Impact: Processing web content may lead to arbitrary code execution.
+Description: A use-after-free issue was addressed with improved
+memory management.</li>
+<li>WebKit Bugzilla: 258992</li>
+</ul>
+</li>
+<li>
+<p><a name="CVE-2023-42833" href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-42833">CVE-2023-42833</a></p>
+<ul>
+<li>Versions affected: WebKitGTK and WPE WebKit before 2.38.0.</li>
+<li>Credit to Dong Jun Kim (@smlijun) and Jong Seong Kim (@nevul37) of
+AbyssLab.</li>
+<li>Impact: Processing web content may lead to arbitrary code execution.
+Description: A correctness issue was addressed with improved checks.</li>
+<li>WebKit Bugzilla: 258592</li>
+</ul>
+</li>
+<li>
+<p><a name="CVE-2014-1745" href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-1745">CVE-2014-1745</a></p>
+<ul>
+<li>Versions affected: WebKitGTK and WPE WebKit before 2.42.0.</li>
+<li>Credit to An anonymous researcher.</li>
+<li>Impact: Processing a file may lead to a denial-of-service or
+potentially disclose memory contents. Description: The issue was
+addressed with improved checks.</li>
+<li>WebKit Bugzilla: 249434</li>
+</ul>
+</li>
+</ul>
+<p>We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.</p>
+<p>Further information about WebKitGTK and WPE WebKit security advisories can be found at:
+<a href="https://webkitgtk.org/security.html">https://webkitgtk.org/security.html</a> or <a href="https://wpewebkit.org/security/">https://wpewebkit.org/security/</a>.</p>
+
+
+
+
+ WPE WebKit 2.42.5 released
+
+ 2024-02-05T00:00:00Z
+ https://wpewebkit.org/wpewebkit.org/aperezdc/learn-discover-rework/release/wpewebkit-2.42.5.html
+ <p>This is a bug fix release in the stable 2.42 series.</p>
+<h3 id="what%E2%80%99s-new-in-wpe-webkit-2.42.5%3F" tabindex="-1">What’s new in WPE WebKit 2.42.5?</h3>
+<ul>
+<li>Fix <code>webkit_web_context_allow_tls_certificate_for_host()</code> to handle IPv6
+URIs produced by <code>SoupURI</code>.</li>
+<li>Ignore stops with offset zero before last one when rendering gradients
+with Cairo.</li>
+<li>Write <code>bwrapinfo.json</code> to disk for <code>xdg-desktop-portal</code>.</li>
+<li>Support gamepad button sixteen (center button in center cluster).</li>
+<li>Update quirks to fix compatibility issues in a number of websites,
+including <code>bing.com</code>, <code>nfl.com</code>, <code>msn.com</code>, <code>bankofamerica.com</code>,
+<code>outlook.live.com</code>, <code>hulu.com</code>, <code>jsfiddle.net</code>, <code>vote.gov</code>,
+<code>youtube.com</code>, <code>airtable.com</code>, <code>gizmodo.com</code>, and <code>ceac.state.gov</code>
+among others.</li>
+<li>Fix incorrect periodic deletion of LocalStorage and IndexedDB databases
+for all websites.</li>
+<li>Fix several crashes and rendering issues.</li>
+</ul>
+<h4 id="checksums" tabindex="-1">Checksums</h4>
+<pre>
+wpewebkit-2.42.5.tar.xz (31.0 MiB)
+ md5sum: d4bfd427199ded5a6fd91d7080290751
+ sha1sum: 50a18f43452520e9f34f84c04bc0166af655ffff
+ sha256sum: 4dbab6c5e6dc0c65a3d7dffc1c2390be5f9abd423faf983fe3a55fe081df0532
+</pre>
+
+
+
+
+ Use Case: Server-side headless rendering
+
+ 2024-02-01T00:00:00Z
+ https://wpewebkit.org/wpewebkit.org/aperezdc/learn-discover-rework/blog/2024-use-case-server-side-rendering.html
+ <div class="success-top">
+<img alt="WPE and server-side headless rendering" align="center" src="https://wpewebkit.org/assets/img/logo-server-side-rendering.png" srcset="https://wpewebkit.org/assets/img/logo-server-side-rendering@2x.png 2x" />
+</div>
+<p>In many distributed applications, it can be useful to run a light web browser on the server side to render some HTML content or process images, video and/or audio using JavaScript.</p>
+<p>Some concrete use-cases can be:</p>
+<ul>
+<li>Video post-production using HTML overlays.</li>
+<li>Easy 3D rendering with WebGL that can be broadcasted as a video stream.</li>
+<li>Reusing the same JavaScript code between a frontend web application and the backend processing.</li>
+</ul>
+<p>WPE WebKit is the perfect solution for all those use cases as it offers a lightweight solution which can run on low-end hardware or even within a container. It provides a lot of flexibility at the moment of choosing the backend infrastructure as WPE WebKit can, for instance, run from within a container with a very minimal Linux configuration (no need for any windowing system) and with full hardware acceleration and zero-copy of the video buffers between the GPU and the CPU.</p>
+<p>Additionally, the fact that WPE WebKit is optimized for lower-powered devices, makes it also the perfect option for server-side rendering when scaling commercial deployments while keeping cost under control, which is yet another important factor to take into account when considering cloud rendering.</p>
+
+
+
+
+ A New WPE Backend Using EGLStream
+
+ 2024-01-29T06:00:00Z
+ https://wpewebkit.org/wpewebkit.org/aperezdc/learn-discover-rework/blog/07-creating-wpe-backends.html
+ <h2 id="what-is-a-wpe-backend%3F" tabindex="-1">What is a WPE Backend?</h2>
+<div class="sidebar">
+<p>This article is a mashup of <a href="https://blogs.igalia.com/llepage/the-process-of-creating-a-new-wpe-backend/">The process of creating a new WPE
+backend</a>
+and <a href="https://blogs.igalia.com/llepage/use-eglstreams-in-a-wpe-webkit-backend/">Use EGLStreams in a WPE WebKit
+backend</a>,
+originally published at Loïc’s blog.</p>
+</div>
+<p>Depending on the target hardware WPE may need to use different techniques and
+technologies to ensure correct graphical rendering. To be independent of any
+user-interface toolkit and windowing system, WPE WebKit delegates the rendering
+to a third-party API defined in the
+<a href="https://github.com/WebPlatformForEmbedded/libwpe">libwpe</a> library. A concrete
+implementation of this API is a “WPE backend”.</p>
+<p>WPE WebKit is a multiprocess application, the end-user starts and controls the
+web widgets in the application process (which we often call “the <abbr title="User Interface">UI</abbr> process” while the web engine itself uses
+different subprocesses: <code>WPENetworkProcess</code> is in charge of managing network
+connections and <code>WPEWebProcess</code> (or “web process”) in charge of the HTML and
+JavaScript parsing, execution and rendering. The WPE backend is at a crossroads
+between the UI process and one or more web process instances.</p>
+<figure>
+ <a href="https://wpewebkit.org/assets/svg/part1-basics.md-1.svg" target="_blank"><img src="https://wpewebkit.org/assets/svg/part1-basics.md-1.svg" alt="Diagram showing a box for the WPE backend in between the UI process and WPEWebProcess" />
+ </a>
+</figure>
+<p>The WPE backend is a shared library that is loaded at runtime by the web
+process and by the UI process. It is used to render the visual aspect of a web
+page and transfer the resulting video buffer from the web process to the
+application process.</p>
+<h2 id="backend-interfaces" tabindex="-1">Backend Interfaces</h2>
+<p>The WPE backend shared library must export at least one symbol called
+<code>_wpe_loader_interface</code> of type <code>struct wpe_loader_interface</code> as defined <a href="https://github.com/WebPlatformForEmbedded/libwpe/blob/d7c669ca6f5ec0d544c264016d270669b336c931/include/wpe/loader.h#L57">in
+the <em>libwpe</em>
+API</a>.
+Presently its only member is <code>load_object</code>, a callback function that receives a
+string with an interface name and returns concrete implementations of the
+following interfaces:</p>
+<ul>
+<li><a href="https://github.com/WebPlatformForEmbedded/libwpe/blob/d7c669ca6f5ec0d544c264016d270669b336c931/include/wpe/renderer-host.h#L48">struct wpe_renderer_host_interface</a></li>
+<li><a href="https://github.com/WebPlatformForEmbedded/libwpe/blob/d7c669ca6f5ec0d544c264016d270669b336c931/include/wpe/renderer-backend-egl.h#L75">struct wpe_renderer_backend_egl_interface</a></li>
+<li><a href="https://github.com/WebPlatformForEmbedded/libwpe/blob/d7c669ca6f5ec0d544c264016d270669b336c931/include/wpe/renderer-backend-egl.h#L93">struct wpe_renderer_backend_egl_target_interface</a></li>
+<li><a href="https://github.com/WebPlatformForEmbedded/libwpe/blob/d7c669ca6f5ec0d544c264016d270669b336c931/include/wpe/renderer-backend-egl.h#L115">struct wpe_renderer_backend_egl_offscreen_target_interface</a></li>
+<li><a href="https://github.com/WebPlatformForEmbedded/libwpe/blob/d7c669ca6f5ec0d544c264016d270669b336c931/include/wpe/view-backend.h#L63">struct wpe_view_backend_interface</a></li>
+</ul>
+<p>The names passed to the <code>.load_object()</code> function are the same as those of the
+interface types, prefixed with an underscore. For example, a
+<code>.load_object("_wpe_renderer_host_interface")</code> call must return a pointer to a
+<code>struct wpe_renderer_host_interface</code> object.</p>
+<details>
+ <summary>Example C code for a <code>load_object</code> callback.</summary>
+<!-- load_object example <<<1 -->
+<pre class="language-c"><code class="language-c"><span class="token keyword">static</span> <span class="token keyword">struct</span> <span class="token class-name">wpe_renderer_host_interface</span> <span class="token operator">=</span> <span class="token punctuation">{</span> <span class="token comment">/* ... */</span> <span class="token punctuation">}</span><span class="token punctuation">;</span>
+<span class="token keyword">static</span> <span class="token keyword">struct</span> <span class="token class-name">wpe_renderer_backend_egl_interface</span> <span class="token operator">=</span> <span class="token punctuation">{</span> <span class="token comment">/* ... */</span> <span class="token punctuation">}</span><span class="token punctuation">;</span>
+
+<span class="token keyword">static</span> <span class="token keyword">void</span><span class="token operator">*</span>
+<span class="token function">my_backend_load_object</span><span class="token punctuation">(</span><span class="token keyword">const</span> <span class="token keyword">char</span> <span class="token operator">*</span>name<span class="token punctuation">)</span>
+<span class="token punctuation">{</span>
+ <span class="token keyword">if</span> <span class="token punctuation">(</span><span class="token operator">!</span><span class="token function">strcmp</span><span class="token punctuation">(</span>name<span class="token punctuation">,</span> <span class="token string">"_wpe_renderer_host_interface"</span><span class="token punctuation">)</span><span class="token punctuation">)</span>
+ <span class="token keyword">return</span> <span class="token operator">&</span>my_renderer_host<span class="token punctuation">;</span>
+ <span class="token keyword">if</span> <span class="token punctuation">(</span><span class="token operator">!</span><span class="token function">strcmp</span><span class="token punctuation">(</span>name<span class="token punctuation">,</span> <span class="token string">"_wpe_renderer_backend_egl_interface"</span><span class="token punctuation">)</span><span class="token punctuation">)</span>
+ <span class="token keyword">return</span> <span class="token operator">&</span>my_renderer_backend_egl<span class="token punctuation">;</span>
+
+ <span class="token comment">/* ... */</span>
+
+ <span class="token keyword">return</span> <span class="token constant">NULL</span><span class="token punctuation">;</span>
+<span class="token punctuation">}</span>
+
+<span class="token keyword">struct</span> <span class="token class-name">wpe_loader_interface</span> _wpe_loader_interface <span class="token operator">=</span> <span class="token punctuation">{</span>
+ <span class="token punctuation">.</span>load_object <span class="token operator">=</span> my_backend_load_object<span class="token punctuation">,</span>
+<span class="token punctuation">}</span><span class="token punctuation">;</span></code></pre>
+<!-- 1>>> -->
+</details>
+<p>Each of these interfaces follow the same base structure: the <code>struct</code> members
+are callback functions, all interfaces have <code>create</code> and <code>destroy</code> members which
+act as instance constructor and destructor, plus any additional “methods”.
+The pointer returned by the <code>create</code> callback will be passed as the <code>object</code>
+“instance” of the other methods:</p>
+<pre class="language-c"><code class="language-c"><span class="token keyword">struct</span> <span class="token class-name">wpe_renderer_host_interface</span> <span class="token punctuation">{</span>
+ <span class="token keyword">void</span><span class="token operator">*</span> <span class="token punctuation">(</span><span class="token operator">*</span>create<span class="token punctuation">)</span><span class="token punctuation">(</span><span class="token keyword">void</span><span class="token punctuation">)</span><span class="token punctuation">;</span>
+ <span class="token keyword">void</span> <span class="token punctuation">(</span><span class="token operator">*</span>destroy<span class="token punctuation">)</span><span class="token punctuation">(</span><span class="token keyword">void</span> <span class="token operator">*</span>object<span class="token punctuation">)</span><span class="token punctuation">;</span>
+ <span class="token comment">/* ... */</span>
+<span class="token punctuation">}</span><span class="token punctuation">;</span></code></pre>
+<p>In the <strong>UI process</strong> side WPE WebKit will create:</p>
+<ul>
+<li>One “renderer host” instance, using <code>wpe_renderer_host_interface.create()</code>.</li>
+<li>Multiple “renderer host client” instances, using <code>wpe_renderer_host_interface.create_client()</code>.
+These are mainly used for IPC communication, one instance gets created for
+each web process launched by WebKit.</li>
+<li>Multiple “view backend” instances, using <code>wpe_view_backend_interface.create()</code>.
+One instance is created for each rendering target in the web process.</li>
+</ul>
+<p>In each <strong>web process</strong>—there can be more than one—WPE WebKit
+will create:</p>
+<ul>
+<li>One “renderer backend EGL” instance, using <code>wpe_renderer_backend_egl_interface.create()</code>.</li>
+<li>Multiple “renderer backend EGL target” instances, using
+<code>wpe_renderer_backend_egl_target_interface.create()</code>. An instance is created
+for each new rendering target needed by the application.</li>
+</ul>
+<details>
+ <summary>How about <code>wpe_renderer_backend_egl_offscreen_target_interface</code>?</summary>
+ <div>
+<p>The <code>rendererBackendEGLTarget</code> instances may be created by the <code>wpe_renderer_backend_egl_target_interface</code>, or
+the <code>wpe_renderer_backend_egl_offscreen_target_interface</code> depending on the interfaces implemented in the backend.</p>
+<p>Here we are only focusing on the <code>wpe_renderer_backend_egl_target_interface</code> that is relying on a classical EGL
+display (defined in the <code>rendererBackendEGL</code> instance). The <code>wpe_renderer_backend_egl_offscreen_target_interface</code> may
+be used in very specific use-cases that are out of the scope of this post. You can check its usage in the WPE WebKit
+<a href="https://github.com/WebKit/WebKit/blob/f32cd0f7cb7961420ce08ae78b8f01f287bec199/Source/WebCore/platform/graphics/egl/GLContextLibWPE.cpp#L61">source code</a>
+for more information.</p>
+ </div>
+</details>
+<p>These instances typically communicate with each others using Unix sockets for
+<abbr title="Inter-Process Communication">IPC</abbr>. The IPC layer must be
+implemented in the WPE backend itself because the <em>libwpe</em> interfaces only pass
+around the file descriptors to be used as communication endpoints.</p>
+<p>From a topological point of view, all those instances are organized as follows:</p>
+<figure>
+ <a href="https://wpewebkit.org/assets/svg/part1-basics.md-2.svg" target="_blank"><img src="https://wpewebkit.org/assets/svg/part1-basics.md-2.svg" />
+ </a>
+</figure>
+<p>From an usage point of view:</p>
+<ul>
+<li>The <code>rendererHost</code> and <code>rendererHostClient</code> instances are only used to manage
+IPC endpoints on the UI process side that are connected to each running
+web process. They are not used by the graphical rendering system.</li>
+<li>The <code>rendererBackendEGL</code> instance (one per web process) is only used to
+connect to the native display for a specific platform. For example, on a
+desktop Linux, the platform may be X11 where the native display would be the
+result of calling <code>XOpenDisplay()</code>; or the platform may be Wayland and in
+this case the native display would be the result of calling
+<code>wl_display_connect()</code>; and so on.</li>
+<li>The <code>rendererBackendEGLTarget</code> (on the web process side) and <code>viewBackend</code>
+(on the UI process side) instances are the ones truly managing the web page
+graphical rendering.</li>
+</ul>
+<h2 id="graphics-rendering" tabindex="-1">Graphics Rendering</h2>
+<p>As seen above, the interfaces in charge of the rendering are
+<code>wpe_renderer_backend_egl_target_interface</code> and <code>wpe_view_backend_interface</code>.
+During their creation, WPE WebKit exchanges the file descriptors used to
+establish a direct IPC connection between a <code>rendererBackendEGL</code> (in the
+web process), and a <code>viewBackend</code> (in the UI process).</p>
+<p>During the EGL initialization phase, when a new web process is launched, WebKit
+will use the native display and platform provided by the
+<code>wpe_renderer_backend_egl_interface.get_native_display()</code> and <code>.get_platform()</code>
+functions to create a suitable OpenGL ES context.</p>
+<p>When WebKit’s
+<a href="https://github.com/WebKit/WebKit/blob/c22f641da18b8c4eee23b8021b37aeec69268675/Source/WebKit/Shared/CoordinatedGraphics/threadedcompositor/ThreadedCompositor.cpp#L220">ThreadedCompositor</a>
+is ready to render a new frame (in the web process), it calls the
+<code>wpe_renderer_backend_egl_target_interface.frame_will_render()</code> function to let
+the WPE backend know that rendering is about to start. At this moment, the
+previously created OpenGL ES context is made current to be used as the target
+for GL drawing commands.</p>
+<p>Once the threaded compositor has finished drawing, it will swap the front and
+back EGL buffers and call the
+<code>wpe_renderer_backend_egl_target_interface.frame_rendered()</code> function to signal
+that the frame is ready. The compositor will then wait until the WPE backend
+calls <code>wpe_renderer_backend_egl_target_dispatch_frame_complete()</code> to indicate
+that the compositor may produce a new frame.</p>
+<p>What happens inside the <code>.frame_will_render()</code> and <code>.frame_rendered()</code>
+implementations is up to the WPE backend. As en example, it could
+set up a <a href="https://www.khronos.org/opengl/wiki/Framebuffer_Object">Frame Buffer Object</a>
+to have the web content draw offscreen, in a texture that can be passed
+back to the UI process for further processing, or use extensions like
+<a href="https://registry.khronos.org/EGL/extensions/KHR/EGL_KHR_stream.txt">EGLStream</a>,
+or <a href="https://registry.khronos.org/EGL/extensions/MESA/EGL_MESA_image_dma_buf_export.txt">DMA-BUF exports</a>
+to transfer the frame to the UI process without copying the pixel data.</p>
+<figure>
+ <a href="https://wpewebkit.org/assets/svg/part1-basics.md-3.svg" target="_blank"><img src="https://wpewebkit.org/assets/svg/part1-basics.md-3.svg" />
+ </a>
+</figure>
+<p>Typically the backend sends each new frame to the corresponding view backend in
+in its <code>.frame_rendered()</code> function. The application can use the frame until it
+sends back an <abbr>IPC</abbr> message to the renderer target (in the web
+process) to indicate that the frame is not in use anymore and may be be freed
+or recycled. Although it is not a requirement to do it at this exact point,
+usually when a renderer backend receives this message it calls the
+<code>wpe_renderer_backend_egl_target_dispatch_frame_complete()</code> function to trigger
+the rendering of a new frame. As a side effect, this mechanism also allows
+controlling the pace at which new frames are produced.</p>
+<h2 id="using-eglstream" tabindex="-1">Using EGLStream</h2>
+<p>EGLStream is an EGL extension that defines a mechanism to transfer hardware
+video buffers from one process to another efficiently, without getting them
+out of GPU memory. Although the extension is supported only in Nvidia
+hardware, it makes for a good example as it transparently handles some
+complexities involved, like buffers with multiple planes.</p>
+<p>This backend uses the EGLStream extension to transfer graphics buffers from the
+web process, which acts as a producer, to the UI process acting as a consumer.
+The producer extension
+<a href="https://registry.khronos.org/EGL/extensions/KHR/EGL_KHR_stream_producer_eglsurface.txt">EGL_KHR_stream_producer_eglsurface</a>
+allows creating a surface that may be used as target for rendering, then using
+<a href="https://registry.khronos.org/EGL/sdk/docs/man/html/eglSwapBuffers.xhtml">eglSwapBuffers()</a>
+finishes drawing and sends the result to the consumer. Meanwhile, in the
+consumer side, the
+<a href="https://registry.khronos.org/EGL/extensions/NV/EGL_NV_stream_consumer_eglimage.txt">EGL_NV_stream_consumer_eglimage</a>
+extension is used to turn each buffer into an <code>EGLImage</code>.</p>
+<p>The reference source code for this WPE backend is available in the
+<a href="https://github.com/Igalia/WPEBackend-offscreen-nvidia">WPEBackend-offscreen-nvidia</a>
+repository, which has been tested with WPE WebKit 2.38.x or 2.40.x, and
+<em>libwpe</em> version 1.14.x.</p>
+<details>
+ <summary>Behold, the Future Belongs to DMA-BUF!</summary>
+ <div>
+<p>With the growing adoption of
+<a href="https://docs.kernel.org/driver-api/dma-buf.html">DMA-BUF</a> for sharing memory
+buffers on modern Linux platforms, the WPE WebKit architecture will be
+evolving and, in the future, the need for a WPE Backend should disappear in
+most cases.</p>
+<p>Ongoing work on WPE WebKit removes the need to provide a WPE backend
+implementation for most hardware platforms, with a generic implementation
+using DMA-BUF provided as an integral, built-in feature of WebKit. It will
+still be possible to provide external implementations for platforms that
+might need to use custom buffer sharing mechanisms.</p>
+<p>From the application developer point of view, in most cases writing
+programs that use the WPE WebKit API will be simpler, with the complexity
+of the communication among multiple processes handled by WebKit.</p>
+ </div>
+</details>
+<h3 id="stream-setup" tabindex="-1">Stream Setup</h3>
+<p>The steps needed to set up EGLStream endpoints need to be done in a particular
+order:</p>
+<ol>
+<li>Create the consumer.</li>
+<li>Get the stream file descriptor for the consumer.</li>
+<li>Send the stream file descriptor to the producer.</li>
+<li>Create the producer.</li>
+</ol>
+<p><strong>First</strong>, the consumer needs to be created:</p>
+<pre class="language-cpp"><code class="language-cpp">EGLStream <span class="token function">createConsumerStream</span><span class="token punctuation">(</span>EGLDisplay eglDisplay<span class="token punctuation">)</span> <span class="token punctuation">{</span>
+ <span class="token keyword">static</span> <span class="token keyword">const</span> EGLint s_streamAttribs<span class="token punctuation">[</span><span class="token punctuation">]</span> <span class="token operator">=</span> <span class="token punctuation">{</span>
+ EGL_STREAM_FIFO_LENGTH_KHR<span class="token punctuation">,</span> <span class="token number">1</span><span class="token punctuation">,</span>
+ EGL_CONSUMER_ACQUIRE_TIMEOUT_USEC_KHR<span class="token punctuation">,</span> <span class="token number">1000</span> <span class="token operator">*</span> <span class="token number">1000</span><span class="token punctuation">,</span>
+ EGL_NONE
+ <span class="token punctuation">}</span><span class="token punctuation">;</span>
+ <span class="token keyword">return</span> <span class="token function">eglCreateStreamKHR</span><span class="token punctuation">(</span>eglDisplay<span class="token punctuation">,</span> s_streamAttribs<span class="token punctuation">)</span><span class="token punctuation">;</span>
+<span class="token punctuation">}</span></code></pre>
+<p>The <code>EGL_STREAM_FIFO_LENGTH_KHR</code> parameter defines the length of the EGLStream
+queue. If set to zero, the stream will work in “mailbox” mode and each time the
+producer has a new frame it will empty the stream content and replace the frame
+by the new one. If non-zero, the stream works work in “<abbr title="First-In,
+First-Out">FIFO</abbr>” mode, which means that the stream queue can contain up
+to <code>EGL_STREAM_FIFO_LENGTH_KHR</code> frames.</p>
+<p>Here we configure a queue for one frame because in this case the specification
+of <code>EGL_KHR_stream_producer_eglsurface</code> guarantees that calling
+<code>eglSwapBuffers()</code> on the producer the call will block until the consumer
+retires the previous frame from queue. This is used as implicit synchronization
+between the UI process side and the web process side without needing to rely on
+custom IPC, which would add a small delay between frames.</p>
+<p>The <code>EGL_CONSUMER_ACQUIRE_TIMEOUT_USEC_KHR</code> parameter defines the maximum
+timeout in microseconds to wait on the consumer side to acquire a frame when
+calling <code>eglStreamConsumerAcquireKHR()</code>. It is only used with the
+<code>EGL_KHR_stream_consumer_gltexture</code> extension because the
+<code>EGL_NV_stream_consumer_eglimage</code> extension allows setting a timeout on each
+call to <code>eglQueryStreamConsumerEventNV()</code> function.</p>
+<p><strong>Second</strong>, to initialize the consumer using the <code>EGL_NV_stream_consumer_eglimage</code>
+extension it is enough to call the <code>eglStreamImageConsumerConnectNV()</code> function.</p>
+<p><strong>Once the consumer has been initialized</strong>, you need to send the EGLStream
+file descriptor to the producer process. The usual way of achieving this would
+be using IPC between the two processes, sending the file descriptor in a
+<code>SCM_RIGHTS</code> message through an Unix socket—although with recent kernels
+using <a href="https://lwn.net/Articles/808997/">pidfd_getfd()</a> may be an option if
+both processes are related.</p>
+<p>When the file descriptor is <strong>finally</strong> received, the producer endpoint can be
+created using the <code>EGL_KHR_stream_producer_eglsurface</code> extension:</p>
+<pre class="language-cpp"><code class="language-cpp"><span class="token keyword">const</span> EGLint surfaceAttribs<span class="token punctuation">[</span><span class="token punctuation">]</span> <span class="token operator">=</span> <span class="token punctuation">{</span>
+ EGL_WIDTH<span class="token punctuation">,</span> width<span class="token punctuation">,</span>
+ EGL_HEIGHT<span class="token punctuation">,</span> height<span class="token punctuation">,</span>
+ EGL_NONE
+<span class="token punctuation">}</span><span class="token punctuation">;</span>
+EGLStream eglStream <span class="token operator">=</span> <span class="token function">eglCreateStreamFromFileDescriptorKHR</span><span class="token punctuation">(</span>eglDisplay<span class="token punctuation">,</span> consumerFD<span class="token punctuation">)</span><span class="token punctuation">;</span>
+EGLSurface eglSurface <span class="token operator">=</span> <span class="token function">eglCreateStreamProducerSurfaceKHR</span><span class="token punctuation">(</span>eglDisplay<span class="token punctuation">,</span> config<span class="token punctuation">,</span> eglStream<span class="token punctuation">,</span> surfaceAttribs<span class="token punctuation">)</span><span class="token punctuation">;</span></code></pre>
+<p>As with <abbr title="Pixel Buffer">pbuffer</abbr> surfaces, the dimensions
+need to be specified as surface attributes. When picking a frame buffer
+configuration with <code>eglChooseConfig()</code> the <code>EGL_SURFACE_TYPE</code> attribute must
+be set to <code>EGL_STREAM_BIT_KHR</code>. From this point onwards, rendering proceeds as
+usual: the EGL surface and context are made active, and once the painting is
+done a call to <code>eglSwapBuffers()</code> will “present” the frame, which in this case
+means sending the buffer with the pixel data down the EGLStream to the
+consumer.</p>
+<figure>
+ <a href="https://wpewebkit.org/assets/svg/part2-eglstream.md-1.svg" target="_blank"><img src="https://wpewebkit.org/assets/svg/part2-eglstream.md-1.svg" />
+ </a>
+</figure>
+<h3 id="consuming-frames" tabindex="-1">Consuming Frames</h3>
+<p>While on the producer side rendering treats the EGLStream surface like any
+other, on the consumer some more work is needed to manager the lifetime of
+the data received: frames have to be manually acquired and released once
+they are not needed anymore.</p>
+<p>The producer calls <code>eglQueryStreamConsumerEventNV()</code> repeatedly to retire the
+next event from the stream:</p>
+<ul>
+<li><code>EGL_STREAM_IMAGE_ADD_NV</code> indicates that there is a buffer in the stream
+that has not yet been bound to an <code>EGLImage</code>, and the application needs to
+create a new one to which the actual data will be bound later.</li>
+<li><code>EGL_STREAM_IMAGE_AVAILABLE_NV</code> indicates that a new frame is available
+and that it can be bound to the previously created <code>EGLImage</code>.</li>
+<li><code>EGL_STREAM_IMAGE_REMOVE_NV</code> indicates that a buffer has been retired from
+the stream, and that its associated <code>EGLImage</code> may be released once the
+application has finished using it.</li>
+</ul>
+<p>This translates roughly to the following code:</p>
+<pre class="language-cpp"><code class="language-cpp"><span class="token keyword">static</span> <span class="token keyword">constexpr</span> EGLTime MAX_TIMEOUT_USEC <span class="token operator">=</span> <span class="token number">1000</span> <span class="token operator">*</span> <span class="token number">1000</span><span class="token punctuation">;</span>
+EGLImage eglImage <span class="token operator">=</span> EGL_NO_IMAGE<span class="token punctuation">;</span>
+
+<span class="token keyword">while</span> <span class="token punctuation">(</span><span class="token boolean">true</span><span class="token punctuation">)</span> <span class="token punctuation">{</span>
+ EGLenum event <span class="token operator">=</span> <span class="token number">0</span><span class="token punctuation">;</span>
+ EGLAttrib data <span class="token operator">=</span> <span class="token number">0</span><span class="token punctuation">;</span>
+
+ <span class="token comment">// WARNING: The specification states that the timeout is in nanoseconds</span>
+ <span class="token comment">// (see: https://registry.khronos.org/EGL/extensions/NV/EGL_NV_stream_consumer_eglimage.txt)</span>
+ <span class="token comment">// but in reality it is in microseconds, at least with the version 535.113.01 of the NVidia drivers.</span>
+ <span class="token keyword">if</span> <span class="token punctuation">(</span><span class="token operator">!</span><span class="token function">eglQueryStreamConsumerEventNV</span><span class="token punctuation">(</span>display<span class="token punctuation">,</span> eglStream<span class="token punctuation">,</span> MAX_TIMEOUT_USEC<span class="token punctuation">,</span> <span class="token operator">&</span>event<span class="token punctuation">,</span> <span class="token operator">&</span>data<span class="token punctuation">)</span><span class="token punctuation">)</span>
+ <span class="token keyword">break</span><span class="token punctuation">;</span>
+
+ <span class="token keyword">switch</span> <span class="token punctuation">(</span>event<span class="token punctuation">)</span> <span class="token punctuation">{</span>
+ <span class="token keyword">case</span> EGL_STREAM_IMAGE_ADD_NV<span class="token operator">:</span> <span class="token comment">// Bind an incoming buffer to an EGLImage.</span>
+ <span class="token keyword">if</span> <span class="token punctuation">(</span>eglImage<span class="token punctuation">)</span> <span class="token function">eglDestroyImage</span><span class="token punctuation">(</span>display<span class="token punctuation">,</span> eglImage<span class="token punctuation">)</span><span class="token punctuation">;</span>
+ eglImage <span class="token operator">=</span> <span class="token function">eglCreateImage</span><span class="token punctuation">(</span>display<span class="token punctuation">,</span> EGL_NO_CONTEXT<span class="token punctuation">,</span> EGL_STREAM_CONSUMER_IMAGE_NV<span class="token punctuation">,</span>
+ <span class="token generic-function"><span class="token function">static_cast</span><span class="token generic class-name"><span class="token operator"><</span>EGLClientBuffer<span class="token operator">></span></span></span><span class="token punctuation">(</span>eglStream<span class="token punctuation">)</span><span class="token punctuation">,</span> <span class="token keyword">nullptr</span><span class="token punctuation">)</span><span class="token punctuation">;</span>
+ <span class="token keyword">continue</span><span class="token punctuation">;</span> <span class="token comment">// Handle the next event.</span>
+
+ <span class="token keyword">case</span> EGL_STREAM_IMAGE_REMOVE_NV<span class="token operator">:</span> <span class="token comment">// Buffer removed, EGLImage may be disposed.</span>
+ <span class="token keyword">if</span> <span class="token punctuation">(</span>data<span class="token punctuation">)</span> <span class="token punctuation">{</span>
+ EGLImage image <span class="token operator">=</span> <span class="token generic-function"><span class="token function">reinterpret_cast</span><span class="token generic class-name"><span class="token operator"><</span>EGLImage<span class="token operator">></span></span></span><span class="token punctuation">(</span>data<span class="token punctuation">)</span><span class="token punctuation">;</span>
+ <span class="token function">eglDestroyImage</span><span class="token punctuation">(</span>display<span class="token punctuation">,</span> image<span class="token punctuation">)</span><span class="token punctuation">;</span>
+ <span class="token keyword">if</span> <span class="token punctuation">(</span>image <span class="token operator">==</span> eglImage<span class="token punctuation">)</span>
+ eglImage <span class="token operator">=</span> EGL_NO_IMAGE<span class="token punctuation">;</span>
+ <span class="token punctuation">}</span>
+ <span class="token keyword">continue</span><span class="token punctuation">;</span> <span class="token comment">// Handle the next event.</span>
+
+ <span class="token keyword">case</span> EGL_STREAM_IMAGE_AVAILABLE_NV<span class="token operator">:</span> <span class="token comment">// New frame available.</span>
+ <span class="token keyword">if</span> <span class="token punctuation">(</span><span class="token function">eglStreamAcquireImageNV</span><span class="token punctuation">(</span>display<span class="token punctuation">,</span> eglStream<span class="token punctuation">,</span> <span class="token operator">&</span>eglImage<span class="token punctuation">,</span> EGL_NO_SYNC<span class="token punctuation">)</span><span class="token punctuation">)</span>
+ <span class="token keyword">break</span><span class="token punctuation">;</span>
+
+ <span class="token keyword">default</span><span class="token operator">:</span>
+ <span class="token keyword">continue</span><span class="token punctuation">;</span> <span class="token comment">// Handle the next event.</span>
+ <span class="token punctuation">}</span>
+
+ <span class="token comment">/*** Use the EGLImage here ***/</span>
+
+ <span class="token function">eglStreamReleaseImageNV</span><span class="token punctuation">(</span>display<span class="token punctuation">,</span> eglStream<span class="token punctuation">,</span> eglImage<span class="token punctuation">,</span> EGL_NO_SYNC<span class="token punctuation">)</span><span class="token punctuation">;</span>
+<span class="token punctuation">}</span></code></pre>
+<p>The application is free to use each <code>EGLImage</code> as it sees fit. An obvious
+example would be to use it as the contents for a texture, which then gets
+painted in the “content” area of a web browser; or as the contents of the
+screen for an in-game computer that the player can interact with, enabling
+display of real, live web content as part of the gaming experience—now
+<em>that</em> would be a deeply embedded browser!</p>
+<h3 id="one-last-thing" tabindex="-1">One Last Thing</h3>
+<p>There is a small showstopper to have EGLStream support working:
+<a href="https://github.com/WebKit/WebKit/blob/cb07c70c253a35b0e09e46e6100e1cdcebab26e2/Source/WebCore/platform/graphics/egl/GLContextEGL.cpp#L135">currently</a>
+when WPE WebKit uses surfaceless EGL contexts it sets the surface type to
+<code>EGL_WINDOW_BIT</code> attribute, while <code>EGL_STREAM_BIT_KHR</code> would be needed
+instead. <a href="https://github.com/Igalia/WPEBackend-offscreen-nvidia/blob/main/wpewebkit-patches/005-fix-surfaceless-egl-context-creation.patch">A small
+patch</a>
+is enough to apply this tweak:</p>
+<pre class="language-diff"><code class="language-diff">diff --git a/Source/WebCore/platform/graphics/egl/GLContextEGL.cpp b/Source/WebCore/platform/graphics/egl/GLContextEGL.cpp
+index d5efa070..5f200edc 100644
+<span class="token coord">--- a/Source/WebCore/platform/graphics/egl/GLContextEGL.cpp</span>
+<span class="token coord">+++ b/Source/WebCore/platform/graphics/egl/GLContextEGL.cpp</span>
+@@ -122,9 +122,11 @@ bool GLContextEGL::getEGLConfig(EGLDisplay display, EGLConfig* config, EGLSurfac
+<span class="token unchanged"><span class="token prefix unchanged"> </span><span class="token line"> attributeList[13] = EGL_PIXMAP_BIT;
+</span><span class="token prefix unchanged"> </span><span class="token line"> break;
+</span><span class="token prefix unchanged"> </span><span class="token line"> case GLContextEGL::WindowSurface:
+</span></span><span class="token deleted-sign deleted"><span class="token prefix deleted">-</span><span class="token line"> case GLContextEGL::Surfaceless:
+</span></span><span class="token unchanged"><span class="token prefix unchanged"> </span><span class="token line"> attributeList[13] = EGL_WINDOW_BIT;
+</span><span class="token prefix unchanged"> </span><span class="token line"> break;
+</span></span><span class="token inserted-sign inserted"><span class="token prefix inserted">+</span><span class="token line"> case GLContextEGL::Surfaceless:
+</span><span class="token prefix inserted">+</span><span class="token line"> attributeList[13] = EGL_STREAM_BIT_KHR;
+</span><span class="token prefix inserted">+</span><span class="token line"> break;
+</span></span><span class="token unchanged"><span class="token prefix unchanged"> </span><span class="token line"> }
+</span></span>
+<span class="token unchanged"><span class="token prefix unchanged"> </span><span class="token line"> EGLint count;
+</span></span></code></pre>
+<!-- vim:set foldmethod=marker foldmarker=<<<,>>>: -->
+
+
+
+
+ libwpe 1.15.2 released
+
+ 2024-01-25T00:00:00Z
+ https://wpewebkit.org/wpewebkit.org/aperezdc/learn-discover-rework/release/libwpe-1.15.2.html
+ <p>This is a development release leading towards the 1.16 series.</p>
+<h3 id="what%E2%80%99s-new-in-libwpe-1.15.2%3F" tabindex="-1">What’s new in libwpe 1.15.2?</h3>
+<ul>
+<li>Allow resetting the fullscreen client to a null pointer.</li>
+<li>Fix usage of the <code>_wpe_loader_interface</code> with the static loader.</li>
+</ul>
+<h4 id="checksums" tabindex="-1">Checksums</h4>
+<pre>
+libwpe-1.15.2.tar.xz (62.0 KiB)
+ md5sum: af8b981f8c620eca9a5672cab0cdd9d4
+ sha1sum: 4a1712dbf331ecc70e6e82ebce2e4602fcef35c1
+ sha256sum: 6d769f64cee0fb1b5069c3b250b0f91e5cd90564cd2efdf633442bab96e5dbe8
+</pre>
+
+
+
+
+ libwpe 1.14.2 released
+
+ 2024-01-25T00:00:00Z
+ https://wpewebkit.org/wpewebkit.org/aperezdc/learn-discover-rework/release/libwpe-1.14.2.html
+ <p>This is a bug fix release in the stable 1.14 series.</p>
+<h3 id="what%E2%80%99s-new-in-libwpe-1.14.2%3F" tabindex="-1">What’s new in libwpe 1.14.2?</h3>
+<ul>
+<li>Allow resetting the fullscreen client to a null pointer.</li>
+<li>Fix usage of the <code>_wpe_loader_interface</code> with the static loader.</li>
+</ul>
+<h4 id="checksums" tabindex="-1">Checksums</h4>
+<pre>
+libwpe-1.14.2.tar.xz (61.6 KiB)
+ md5sum: 61840e24ba0a0f5828194dff28db92ee
+ sha1sum: 70a2b894af2b50d7082260158a89524974a480f3
+ sha256sum: 8ae38022c50cb340c96fdbee1217f1e46ab57fbc1c8ba98142565abbedbe22ef
+</pre>
+
+
+
+
+ WPE WebKit 2.42.4 released
+
+ 2023-12-14T00:00:00Z
+ https://wpewebkit.org/wpewebkit.org/aperezdc/learn-discover-rework/release/wpewebkit-2.42.4.html
+ <p>This is a bug fix release in the stable 2.42 series.</p>
+<h3 id="what%E2%80%99s-new-in-wpe-webkit-2.42.4%3F" tabindex="-1">What’s new in WPE WebKit 2.42.4?</h3>
+<ul>
+<li>Fix incorrect random images incorrectly displayed as backgrounds
+of <code><div></code> elements.</li>
+<li>Fix videos displayed aliased after being resized e.g. on YouTube.</li>
+<li>Fix several crashes and rendering issues.</li>
+</ul>
+<h4 id="checksums" tabindex="-1">Checksums</h4>
+<pre>
+wpewebkit-2.42.4.tar.xz (30.9 MiB)
+ md5sum: 154dd24d1811bd51d2dd6bb22120d283
+ sha1sum: 34da38e9554586154c83fdbb5c20e353b6d97277
+ sha256sum: 8836040a3687581970b47a232b713e7023c080d5613427f52db619c29fb253a4
+</pre>
+
+
+
+
+ Cog 0.18.2 released
+
+ 2023-12-13T00:00:00Z
+ https://wpewebkit.org/wpewebkit.org/aperezdc/learn-discover-rework/release/cog-0.18.2.html
+ <p>This is a bug fix release in the stable 0.18 series.</p>
+<h3 id="what%E2%80%99s-new-in-cog-0.18.2%3F" tabindex="-1">What’s new in Cog 0.18.2?</h3>
+<ul>
+<li>drm: Fix crash on iMX.6 (and possibly others) by improving how the CRTC
+and encoder combination is chosen.</li>
+<li>wl: Add support for Weston protocols version 13.</li>
+<li>launcher: Handle <code>GApplication</code> activation to avoid a warning.</li>
+</ul>
+<h4 id="checksums" tabindex="-1">Checksums</h4>
+<pre>
+cog-0.18.2.tar.xz (123.1 KiB)
+ md5sum: 7fbfc2e19304132be0d73f5e5512151c
+ sha1sum: 045294f7fa878db86e4b8a617ee4ac056a71cb75
+ sha256sum: 3c4237cff6323b8c3eaf52c6f3f6415b898a22c0127c6c396c1eaa6eef46c279
+</pre>
+
+
+
+
+ WPE WebKit 2.42.3 released
+
+ 2023-12-04T00:00:00Z
+ https://wpewebkit.org/wpewebkit.org/aperezdc/learn-discover-rework/release/wpewebkit-2.42.3.html
+ <p>This is a bug fix release in the stable 2.42 series.</p>
+<h3 id="what%E2%80%99s-new-in-wpe-webkit-2.42.3%3F" tabindex="-1">What’s new in WPE WebKit 2.42.3?</h3>
+<ul>
+<li>Fix flickering in videos when using VA-API with DMA-BUF for rendering.</li>
+<li>Fix color picker being triggered in the inspector when typing <code>tan</code>.</li>
+<li>Fix wrong choice of font fallback in some cases when using <code>sans</code> as
+the font family.</li>
+<li>Fix build failure with <code>libxml2</code> version 2.12.0 due to an API change.</li>
+<li>Fix several crashes and rendering issues.</li>
+</ul>
+<h4 id="checksums" tabindex="-1">Checksums</h4>
+<pre>
+wpewebkit-2.42.3.tar.xz (30.9 MiB)
+ md5sum: 44b7b60d439d917d8e9b97639e7d7509
+ sha1sum: 0523887944137206faca1080ab3f9e8b4cad6413
+ sha256sum: 499969acf25a56b4abd3f3e68324069f579ccb34e441259a5e04031b1f564daa
+</pre>
+
+
+
\ No newline at end of file
diff --git a/aperezdc/learn-discover-rework/index.html b/aperezdc/learn-discover-rework/index.html
new file mode 100644
index 000000000..ae580346a
--- /dev/null
+++ b/aperezdc/learn-discover-rework/index.html
@@ -0,0 +1,666 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ WPE
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Create simple and performant systems based on Web platform technologies.
+
+
+A WebKit port for Linux-based embedded devices designed with flexibility and hardware acceleration in mind, leveraging common 3D graphics APIs for best performance.
+
The Web Platform is a frequently chosen foundational technology for many reasons, including:
+
+
Web Platform technologies are built on standards, they have great longevity
+
The standards are open, embedded systems can incorporate them without licensing fees or other worries.
+Open standards with great longevity allows lots more things to benefit from the same investments
+
The number of people with the basic skills to build things with web technologies is massive
WPE WebKit is widely adopted by many industries, including digital signage, professional audio, home appliances, set-top-boxes, automotive, and inflight infotainment. Countless devices deployed around the globe are already using WPE WebKit as their web runtime platform, and use is growing rapidly.
+
+
+
+
+
+
+
+
+
+
+
Success Story
+
+
WPE WebKit brought RDK, a modern, performant web browser, to millions of screens. It enables operators to manage devices and easily customize their UIs and apps and provides analytics to improve the customer experience and drive business results.
Digital signage web rendering players have many advantages and are a trend nowadays. They feature use of HTML for composing the user interface, simple and effortless provisioning and scheduling new contents to the screen from the cloud, a robust environment with an automatic crash recovery system, and more.
WPE is the official WebKit port for embedded platforms. WPE is uniquely designed for embedded systems in that it doesn’t depend on any user-interface toolkits such as the traditional Cocoa, GTK, etc toolkits.
We’ve been collecting answers to lots of common questions we’ve been asked. If you have questions, you might find a ready answer in the FAQ.
+
+
+
+
+
+
+
+
+
Brought to you by
+
+
+
+
+
WPEWebKit is developed by Igalia, an open-source consultancy with a lot of experience working on the Web platform. As the maintainers of this official port of WebKit, Igalia has a great deal of experience with meeting hardware and software challenges in the embedded space and several others. Get in touch!
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Atomically decrements the reference count of info
+ by one. If the
+reference count drops to 0, all memory allocated by the WebKitApplicationInfo is
+released. This function is MT-safe and may be called from any
+thread.
Set the application version. If the application doesn't use the format
+major.minor.micro you can pass 0 as the micro to use major.minor, or pass
+0 as both micro and minor to use only major number. Any other format must
+be converted to major.minor.micro so that it can be used in version comparisons.
Whenever a client attempts to load a page protected by HTTP
+authentication, credentials will need to be provided to authorize access.
+To allow the client to decide how it wishes to handle authentication,
+WebKit will fire a “authenticate” signal with a
+WebKitAuthenticationRequest object to provide client side
+authentication support. Credentials are exposed through the
+WebKitCredential object.
+
In case the client application does not wish
+to handle this signal WebKit will provide a default handler. To handle
+authentication asynchronously, simply increase the reference count of the
+WebKitAuthenticationRequest object.
Determine whether the authentication method associated with this
+WebKitAuthenticationRequest should allow the storage of credentials.
+This will return FALSE if WebKit doesn't support credential storing
+or if private browsing is enabled.
Get the WebKitCredential of the proposed authentication challenge that was
+stored from a previous session. The client can use this directly for
+authentication or construct their own WebKitCredential.
This signal is emitted when the user authentication request is
+cancelled. It allows the application to dismiss its authentication
+dialog in case of page load failure for example.
WebKitAutomationSession represents an automation session of a WebKitWebContext.
+When a new session is requested, a WebKitAutomationSession is created and the signal
+WebKitWebContext::automation-started is emitted with the WebKitAutomationSession as
+argument. Then, the automation client can request the session to create a new
+WebKitWebView to interact with it. When this happens the signal “create-web-view”
+is emitted.
Set the application information to session
+. This information will be used by the driver service
+to match the requested capabilities with the actual application information. If this information
+is not provided to the session when a new automation session is requested, the creation might fail
+if the client requested a specific browser name or version. This will not have any effect when called
+after the automation session has been fully created, so this must be called in the callback of
+“automation-started” signal.
This signal is emitted when the automation client requests a new
+browsing context to interact with it. The callback handler should
+return a WebKitWebView created with “is-controlled-by-automation”
+construct property enabled. The returned WebKitWebView could be an existing
+web view or a new one created and added to a new tab or window.
WebKitBackForwardList maintains a list of visited pages used to
+navigate to recent pages. Items are inserted in the list in the
+order they are visited.
+
WebKitBackForwardList also maintains the notion of the current item
+(which is always at index 0), the preceding item (which is at index -1),
+and the following item (which is at index 1).
+Methods webkit_web_view_go_back() and webkit_web_view_go_forward() move
+the current item backward or forward by one. Method
+webkit_web_view_go_to_back_forward_list_item() sets the current item to the
+specified item. All other methods returning WebKitBackForwardListItems
+do not change the value of the current item, they just return the requested
+item or items.
This signal is emitted when back_forward_list
+ changes. This happens
+when the current item is updated, a new item is added or one or more
+items are removed. Note that both item_added
+ and items_removed
+ can
+NULL when only the current item is updated. Items are only removed
+when the list is cleared or the maximum items limit is reached.
Inserts item
+ into the menu
+ at the given position.
+If position
+ is negative, or is larger than the number of items
+in the WebKitContextMenu, the item is added on to the end of
+the menu
+. The first position is 0.
Moves item
+ to the given position in the menu
+.
+If position
+ is negative, or is larger than the number of items
+in the WebKitContextMenu, the item is added on to the end of
+the menu
+.
+The first position is 0.
Sets user data to menu
+.
+This function can be used from a Web Process extension to set user data
+that can be retrieved from the UI Process using webkit_context_menu_get_user_data().
+If the user_data
+ GVariant is floating, it is consumed.
Gets the user data of menu
+.
+This function can be used from the UI Process to get user data previously set
+from the Web Process with webkit_context_menu_set_user_data().
Creates a new WebKitContextMenuItem for the given stock action.
+Stock actions are handled automatically by WebKit so that, for example,
+when a menu item created with a WEBKIT_CONTEXT_MENU_ACTION_STOP is
+activated the action associated will be handled by WebKit and the current
+load operation will be stopped. You can get the GtkAction of a
+WebKitContextMenuItem created with a WebKitContextMenuAction with
+webkit_context_menu_item_get_action() and connect to “activate” signal
+to be notified when the item is activated. But you can't prevent the associated
+action from being performed.
Set the filename
+ where non-session cookies are stored persistently using
+storage
+ as the format to read/write the cookies.
+Cookies are initially read from filename
+ to create an initial set of cookies.
+Then, non-session cookies will be written to filename
+ when the WebKitCookieManager::changed
+signal is emitted.
+By default, cookie_manager
+ doesn't store the cookies persistently, so you need to call this
+method to keep cookies saved across sessions.
WebKitDownload carries information about a download request and
+response, including a WebKitURIRequest and a WebKitURIResponse
+objects. The application may use this object to control the
+download process, or to simply figure out what is to be downloaded,
+and handle the download process itself.
Obtains the URI to which the downloaded file will be written. You
+can connect to “created-destination” to make
+sure this method returns a valid destination.
Sets the URI to which the downloaded file will be written.
+This method should be called before the download transfer
+starts or it will not have any effect on the ongoing download
+operation. To set the destination using the filename suggested
+by the server connect to “decide-destination”
+signal and call webkit_download_set_destination(). If you want to
+set a fixed destination URI that doesn't depend on the suggested
+filename you can connect to notify::response signal and call
+webkit_download_set_destination().
+If “decide-destination” signal is not handled
+and destination URI is not set when the download transfer starts,
+the file will be saved with the filename suggested by the server in
+G_USER_DIRECTORY_DOWNLOAD directory.
Retrieves the WebKitURIResponse object that backs the download
+process. This method returns NULL if called before the response
+is received from the server. You can connect to notify::response
+signal to be notified when the response is received.
Gets the value of the “estimated-progress” property.
+You can monitor the estimated progress of the download operation by
+connecting to the notify::estimated-progress signal of download
+.
Gets the elapsed time in seconds, including any fractional part.
+If the download finished, had an error or was cancelled this is
+the time between its start and the event.
Returns the current value of the “allow-overwrite” property,
+which determines whether the download will overwrite an existing file on
+disk, or if it will fail if the destination already exists.
Sets the “allow-overwrite” property, which determines whether
+the download may overwrite an existing file on disk, or if it will fail if
+the destination already exists.
Whether or not the download is allowed to overwrite an existing file on
+disk. If this property is FALSE and the destination already exists,
+the download will fail.
An estimate of the percent completion for the download operation.
+This value will range from 0.0 to 1.0. The value is an estimate
+based on the total number of bytes expected to be received for
+a download.
+If you need a more accurate progress information you can connect to
+“received-data” signal to track the progress.
This signal is emitted after “decide-destination” and before
+“received-data” to notify that destination file has been
+created successfully at destination
+.
This signal is emitted after response is received to
+decide a destination URI for the download. If this signal is not
+handled the file will be downloaded to G_USER_DIRECTORY_DOWNLOAD
+directory using suggested_filename
+.
This signal is emitted when an error occurs during the download
+operation. The given error
+, of the domain WEBKIT_DOWNLOAD_ERROR,
+contains further details of the failure. If the download is cancelled
+with webkit_download_cancel(), this signal is emitted with error
+WEBKIT_DOWNLOAD_ERROR_CANCELLED_BY_USER. The download operation finishes
+after an error and “finished” signal is emitted after this one.
This signal is emitted after response is received,
+every time new data has been written to the destination. It's
+useful to know the progress of the download operation.
Gets the typing attributes at the current cursor position.
+If there is a selection, this returns the typing attributes
+of the selected text. Note that in case of a selection,
+typing attributes are considered active only when they are
+present throughout the selection.
WebKit will automatically look for available icons in <link>
+elements on opened pages as well as an existing favicon.ico and
+load the images found into a memory cache if possible. That cache
+is frozen to an on-disk database for persistence.
+
If “enable-private-browsing” is TRUE, new icons
+won't be added to the on-disk database and no existing icons will
+be deleted from it. Nevertheless, WebKit will still store them in
+the in-memory cache during the current execution.
This signal is emitted when the favicon URI of page_uri
+ has
+been changed to favicon_uri
+ in the database. You can connect
+to this signal and call webkit_favicon_database_get_favicon()
+to get the favicon. If you are interested in the favicon of a
+WebKitWebView it's easier to use the “favicon”
+property. See webkit_web_view_get_favicon() for more details.
+
+
Parameters
+
+
+
+
+
+
+
+
+
database
+
the object on which the signal is emitted
+
+
+
+
page_uri
+
the URI of the Web page containing the icon
+
+
+
+
favicon_uri
+
the URI of the favicon
+
+
+
+
user_data
+
user data set when the signal handler was connected.
Whenever the user interacts with an <input type='file' />
+HTML element, WebKit will need to show a dialog to choose one or
+more files to be uploaded to the server along with the rest of the
+form data. For that to happen in a general way, instead of just
+opening a GtkFileChooserDialog (which might be not desirable in
+some cases, which could prefer to use their own file chooser
+dialog), WebKit will fire the “run-file-chooser”
+signal with a WebKitFileChooserRequest object, which will allow
+the client application to specify the files to be selected, to
+inspect the details of the request (e.g. if multiple selection
+should be allowed) and to cancel the request, in case nothing was
+selected.
+
In case the client application does not wish to handle this signal,
+WebKit will provide a default handler which will asynchronously run
+a regular GtkFileChooserDialog for the user to interact with.
Get the list of MIME types the file chooser dialog should handle,
+in the format specified in RFC 2046 for "media types". Its contents
+depend on the value of the 'accept' attribute for HTML input
+elements. This function should normally be called before presenting
+the file chooser dialog to the user, to decide whether to allow the
+user to select multiple files at once or only one.
a
+NULL-terminated array of strings if a list of accepted MIME types
+is defined or NULL otherwise, meaning that any MIME type should be
+accepted. This array and its contents are owned by WebKit and
+should not be modified or freed.
Determine whether the file chooser associated to this
+WebKitFileChooserRequest should allow selecting multiple files,
+which depends on the HTML input element having a 'multiple'
+attribute defined.
Get the list of selected files currently associated to the
+request. Initially, the return value of this method contains any
+files selected in previous file chooser requests for this HTML
+input element. Once webkit_file_chooser_request_select_files, the
+value will reflect whatever files are given.
+
This function should normally be called only before presenting the
+file chooser dialog to the user, to decide whether to perform some
+extra action, like pre-selecting the files from a previous request.
a
+NULL-terminated array of strings if there are selected files
+associated with the request or NULL otherwise. This array and its
+contents are owned by WebKit and should not be modified or
+freed.
Ask WebKit to cancel the request. It's important to do this in case
+no selection has been made in the client, otherwise the request
+won't be properly completed and the browser will keep the request
+pending forever, which might cause the browser to hang.
Looks for search_text
+ in the WebKitWebView associated with
+find_controller
+ since the beginning of the document highlighting
+up to max_match_count
+ matches. The outcome of the search will be
+asynchronously provided by the “found-text”
+and “failed-to-find-text” signals.
Counts the number of matches for search_text
+ found in the
+WebKitWebView with the provided find_options
+. The number of
+matches will be provided by the
+“counted-matches” signal.
WebKitGeolocationPermissionRequest represents a request for
+permission to decide whether WebKit should provide the user's
+location to a website when requested through the Geolocation API.
+
When a WebKitGeolocationPermissionRequest is not handled by the user,
+it is denied by default.
+
When embedding web views in your application, you *must* configure an
+application identifier to allow web content to use geolocation services.
+The identifier *must* match the name of the .desktop file which describes
+the application, sans the suffix.
+
If your application uses GApplication (or any subclass like
+GtkApplication), WebKit will automatically use the identifier returned by
+g_application_get_application_id(). This is the recommended approach for
+enabling geolocation in applications.
+
If an identifier cannot be obtained through GApplication, the value
+returned by g_get_prgname() will be used instead as a fallback. For
+programs which cannot use GApplication, calling g_set_prgname() early
+during initialization is needed when the name of the executable on disk
+does not match the name of a valid .desktop file.
A Hit Test is an operation to get context information about a given
+point in a WebKitWebView. WebKitHitTestResult represents the
+result of a Hit Test. It provides context information about what is
+at the coordinates of the Hit Test, such as if there's a link,
+an image or a media.
the title of the link element in the coordinates of the Hit Test,
+or NULL if there isn't a link element in hit_test_result
+context or the
+link element doesn't have a title
the label of the link element in the coordinates of the Hit Test,
+or NULL if there isn't a link element in hit_test_result
+context or the
+link element doesn't have a label
WebKitInstallMissingMediaPluginsPermissionRequest represents a request for
+permission to decide whether WebKit should try to start a helper application to
+install missing media plugins when the media backend couldn't play a media because
+the required plugins were not available.
+
When a WebKitInstallMissingMediaPluginsPermissionRequest is not handled by the user,
+it is allowed by default.
Return the WebKitURIRequest associated with the navigation action.
+Modifications to the returned object are not taken
+into account when the request is sent over the network, and is intended
+only to aid in evaluating whether a navigation action should be taken or
+not. To modify requests before they are sent over the network the
+“send-request” signal can be used instead.
WebKitNavigationPolicyDecision represents a policy decision for events associated with
+navigations. If the value of “mouse-button” is not 0, then
+the navigation was triggered by a mouse event.
If this navigation request targets a new frame, this property contains
+the name of that frame. For example if the decision was triggered by clicking a
+link with a target attribute equal to "_blank", this property will contain the
+value of that attribute. In all other cases, this value will be NULL.
The default proxy URI will be used for any URI that doesn't match ignore_hosts
+, and doesn't match any
+of the schemes added with webkit_network_proxy_settings_add_proxy_for_scheme().
+If default_proxy_uri
+ starts with "socks://", it will be treated as referring to all three of the
+socks5, socks4a, and socks4 proxy types.
+
ignore_hosts
+ is a list of hostnames and IP addresses that the resolver should allow direct connections to.
+Entries can be in one of 4 formats:
+
+
+A hostname, such as "example.com", ".example.com", or "*.example.com", any of which match "example.com" or
+any subdomain of it.
+
+
+An IPv4 or IPv6 address, such as "192.168.1.1", which matches only that address.
+
+
+A hostname or IP address followed by a port, such as "example.com:80", which matches whatever the hostname or IP
+address would match, but only for URLs with the (explicitly) indicated port. In the case of an IPv6 address, the address
+part must appear in brackets: "[::1]:443"
+
+
+An IP address range, given by a base address and prefix length, such as "fe80::/10", which matches any address in that range.
+
+
+
Note that when dealing with Unicode hostnames, the matching is done against the ASCII form of the name.
+Also note that hostname exclusions apply only to connections made to hosts identified by name, and IP address exclusions apply only
+to connections made to hosts identified by address. That is, if example.com has an address of 192.168.1.1, and ignore_hosts
+
+contains only "192.168.1.1", then a connection to "example.com" will use the proxy, and a connection to 192.168.1.1" will not.
Adds a URI-scheme-specific proxy. URIs whose scheme matches uri_scheme
+ will be proxied via proxy_uri
+.
+As with the default proxy URI, if proxy_uri
+ starts with "socks://", it will be treated as referring to
+all three of the socks5, socks4a, and socks4 proxy types.
WebKitNotificationPermissionRequest represents a request for
+permission to decide whether WebKit should provide the user with
+notifications through the Web Notification API.
+
When a WebKitNotificationPermissionRequest is not handled by the user,
+it is denied by default.
There are situations where an embedder would need to ask the user
+for permission to do certain types of operations, such as switching
+to fullscreen mode or reporting the user's location through the
+standard Geolocation API. In those cases, WebKit will emit a
+“permission-request” signal with a
+WebKitPermissionRequest object attached to it.
This object represents a single plugin, found while scanning the
+various platform plugin directories. This object can be used to get
+more information about a plugin, and enable/disable it, allowing
+fine-grained control of plugins. The list of available plugins can
+be obtained from the WebKitWebContext, with
+webkit_web_context_get_plugins().
Atomically decrements the reference count of info
+ by one. If the
+reference count drops to 0, all memory allocated by the WebKitMimeInfo is
+released. This function is MT-safe and may be called from any
+thread.
Often WebKit allows the client to decide the policy for certain
+operations. For instance, a client may want to open a link in a new
+tab, block a navigation entirely, query the user or trigger a download
+instead of a navigation. In these cases WebKit will fire the
+“decide-policy” signal with a WebKitPolicyDecision
+object. If the signal handler does nothing, WebKit will act as if
+webkit_policy_decision_use() was called as soon as signal handling
+completes. To make a policy decision asynchronously, simply increment
+the reference count of the WebKitPolicyDecision object.
WebKitResponsePolicyDecision represents a policy decision for a
+resource response, whether from the network or the local system.
+A very common use case for these types of decision is deciding
+whether or not to download a particular resource or to load it
+normally.
Return the WebKitURIRequest associated with the response decision.
+Modifications to the returned object are not taken
+into account when the request is sent over the network, and is intended
+only to aid in evaluating whether a response decision should be taken or
+not. To modify requests before they are sent over the network the
+“send-request” signal can be used instead.
Register scheme
+ as a CORS (Cross-origin resource sharing) enabled scheme.
+This means that CORS requests are allowed. See W3C CORS specification
+http://www.w3.org/TR/cors/.
WebKitSecurityOrigin is a representation of a security domain
+defined by websites. A security origin normally consists of a
+protocol, a hostname, and a port number. It is also possible for a
+security origin to be opaque, as defined by the HTML standard, in
+which case it has no associated protocol, host, or port.
+
Websites with the same security origin can access each other's
+resources for client-side scripting or database access.
Create a new security origin from the provided URI. Components of
+uri
+ other than protocol, host, and port do not affect the created
+WebKitSecurityOrigin.
Atomically decrements the reference count of origin
+ by one.
+If the reference count drops to 0, all memory allocated by
+WebKitSecurityOrigin is released. This function is MT-safe and may be
+called from any thread.
Gets the port of origin
+. This function will always return 0 if the
+port is the default port for the given protocol. For example,
+http://example.com has the same security origin as
+http://example.com:80, and this function will return 0 for a
+WebKitSecurityOrigin constructed from either URI. It will also
+return 0 if origin
+ is opaque.
Gets a string representation of origin
+. The string representation
+is a valid URI with only protocol, host, and port components. It may
+be NULL, but usually only if origin
+ is opaque.
WebKitSettings can be applied to a WebKitWebView to control text charset,
+color, font sizes, printing mode, script support, loading of images and various
+other things on a WebKitWebView. After creation, a WebKitSettings object
+contains default settings.
Set the “user-agent” property by appending the application details to the default user
+agent. If no application name or version is given, the default user agent used will be used. If only
+the version is given, the default engine version is used with the given application name.
Whether file access is allowed from file URLs. By default, when
+something is loaded in a WebKitWebView using a file URI, cross
+origin requests to other file resources are not allowed. This
+setting allows you to change that behaviour, so that it would be
+possible to do a XMLHttpRequest of a local file, for example.
Determine whether it's allowed to create and run modal dialogs
+from a WebKitWebView through JavaScript with
+window.showModalDialog. If it's set to
+FALSE, the associated WebKitWebView won't be able to create
+new modal dialogs, so not even the “create”
+signal will be emitted.
+
Flags: Read / Write / Construct
+
Default value: FALSE
+
+
+
+
The “allow-universal-access-from-file-urls” property
Whether or not JavaScript running in the context of a file scheme URL
+should be allowed to access content from any origin. By default, when
+something is loaded in a WebKitWebView using a file scheme URL,
+access to the local file system and arbitrary local storage is not
+allowed. This setting allows you to change that behaviour, so that
+it would be possible to use local storage, for example.
Determines whether images should be automatically loaded or not.
+On devices where network bandwidth is of concern, it might be
+useful to turn this property off.
Whether to draw compositing borders and repaint counters on layers drawn
+with accelerated compositing. This is useful for debugging issues related
+to web content that is composited with the GPU.
Enable or disable accelerated 2D canvas. Accelerated 2D canvas is only available
+if WebKit was compiled with a version of Cairo including the unstable CairoGL API.
+When accelerated 2D canvas is enabled, WebKit may render some 2D canvas content
+using hardware accelerated drawing operations.
Enable or disable support for Encrypted Media API on pages.
+EncryptedMedia is an experimental JavaScript API for playing encrypted media in HTML.
+This property will only work as intended if the EncryptedMedia feature is enabled at build time
+with the ENABLE_ENCRYPTED_MEDIA flag.
Whether to enable the frame flattening. With this setting each subframe is expanded
+to its contents, which will flatten all the frames to become one scrollable page.
+On touch devices scrollable subframes on a page can result in a confusing user experience.
Whether to enable the Javascript Fullscreen API. The API
+allows any HTML element to request fullscreen display. See also
+the current draft of the spec:
+http://www.w3.org/TR/fullscreen/
Whether to enable HTML5 client-side SQL database support. Client-side
+SQL database allows web pages to store structured data and be able to
+use SQL to manipulate that data asynchronously.
+
HTML5 database specification is available at
+http://www.w3.org/TR/webdatabase/.
Determines whether or not JavaScript markup is allowed in document. When this setting is disabled,
+all JavaScript-related elements and attributes are removed from the document during parsing. Note that
+executing JavaScript is still allowed if “enable-javascript” is TRUE.
Enable or disable support for MediaCapabilities on pages. This
+specification intends to provide APIs to allow websites to make an optimal
+decision when picking media content for the user. The APIs will expose
+information about the decoding and encoding capabilities for a given format
+but also output capabilities to find the best match based on the device’s
+display.
+
See also https://wicg.github.io/media-capabilities/
Enable or disable support for MediaStream on pages. MediaStream
+is an experimental proposal for allowing web pages to access
+audio and video devices for capture.
+
See also http://dev.w3.org/2011/webrtc/editor/getusermedia.html
Whether to enable HTML5 offline web application cache support. Offline
+web application cache allows web applications to run even when
+the user is not connected to the network.
+
HTML5 offline web application specification is available at
+http://dev.w3.org/html5/spec/offline.html.
Enable or disable the page cache. Disabling the page cache is
+generally only useful for special circumstances like low-memory
+scenarios or special purpose applications like static HTML
+viewers. This setting only controls the Page Cache, this cache
+is different than the disk-based or memory-based traditional
+resource caches, its point is to make going back and forth
+between pages much faster. For details about the different types
+of caches and their purposes see:
+http://webkit.org/blog/427/webkit-page-cache-i-the-basics/
Whether to turn on site-specific quirks. Turning this on will
+tell WebKit to use some site-specific workarounds for
+better web compatibility. For example, older versions of
+MediaWiki will incorrectly send to WebKit a CSS file with KHTML
+workarounds. By turning on site-specific quirks, WebKit will
+special-case this and other cases to make some specific sites work.
Whether to enable Spatial Navigation. This feature consists in the ability
+to navigate between focusable elements in a Web page, such as hyperlinks
+and form controls, by using Left, Right, Up and Down arrow keys.
+For example, if an user presses the Right key, heuristics determine whether
+there is an element they might be trying to reach towards the right, and if
+there are multiple elements, which element they probably wants.
Determines whether the tab key cycles through the elements on the page.
+When this setting is enabled, users will be able to focus the next element
+in the page by pressing the tab key. If the selected element is editable,
+then pressing tab key will insert the tab character.
Enable or disable support for WebAudio on pages. WebAudio is an
+experimental proposal for allowing web pages to generate Audio
+WAVE data from JavaScript. The standard is currently a
+work-in-progress by the W3C Audio Working Group.
+
See also https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html
Enable or disable support for WebGL on pages. WebGL is an experimental
+proposal for allowing web pages to use OpenGL ES-like calls directly. The
+standard is currently a work-in-progress by the Khronos Group.
+
Flags: Read / Write / Construct
+
Default value: FALSE
+
+
+
+
The “enable-write-console-messages-to-stdout” property
Whether media playback is full-screen only or inline playback is allowed.
+This is TRUE by default, so media playback can be inline. Setting it to
+FALSE allows specifying that media playback should be always fullscreen.
+
Flags: Read / Write / Construct
+
Default value: TRUE
+
+
+
+
The “media-playback-requires-user-gesture” property
Whether a user gesture (such as clicking the play button)
+would be required to start media playback or load media. This is off
+by default, so media playback could start automatically.
+Setting it on requires a gesture by the user to start playback, or to
+load the media.
The minimum font size in pixels used to display text. This setting
+controls the absolute smallest size. Values other than 0 can
+potentially break page layouts.
The user-agent string used by WebKit. Unusual user-agent strings may cause web
+content to render incorrectly or fail to run, as many web pages are written to
+parse the user-agent strings of only the most popular browsers. Therefore, it's
+typically better to not completely override the standard user-agent, but to use
+webkit_settings_set_user_agent_with_application_details() instead.
+
If this property is set to the empty string or NULL, it will revert to the standard
+user-agent.
Whether “zoom-level” affects only the
+text of the page or all the contents. Other contents containing text
+like form controls will be also affected by zoom factor when
+this property is enabled.
+
Flags: Read / Write / Construct
+
Default value: FALSE
+
+
+
+
+
+
\ No newline at end of file
diff --git a/aperezdc/learn-discover-rework/reference/wpewebkit/2.23.90/WebKitURIRequest/index.html b/aperezdc/learn-discover-rework/reference/wpewebkit/2.23.90/WebKitURIRequest/index.html
new file mode 100644
index 000000000..2507de05c
--- /dev/null
+++ b/aperezdc/learn-discover-rework/reference/wpewebkit/2.23.90/WebKitURIRequest/index.html
@@ -0,0 +1,289 @@
+
+
+
+
+WebKitURIRequest: WPE Reference Manual
+
+
+
+
+
+
+
+
+
+
A WebKitURIResponse contains information such as the URI, the
+status code, the content length, the mime type, the HTTP status or
+the suggested filename.
Get the status code of the WebKitURIResponse as returned by
+the server. It will normally be a SoupKnownStatusCode, for
+example SOUP_STATUS_OK, though the server can respond with any
+unsigned integer.
Registers a new user script message handler. After it is registered,
+scripts can use window.webkit.messageHandlers.<name>.postMessage(value)
+to send messages. Those messages are received by connecting handlers
+to the “script-message-received” signal. The
+handler name is used as the detail of the signal. To avoid race
+conditions between registering the handler name, and starting to
+receive the signals, it is recommended to connect to the signal
+*before* registering the handler name:
Unregisters a previously registered message handler.
+
Note that this does *not* disconnect handlers for the
+“script-message-received” signal;
+they will be kept connected, but the signal will not be emitted
+unless the handler name is registered again.
Unregisters a previously registered message handler in script world with name world_name
+.
+
Note that this does *not* disconnect handlers for the
+“script-message-received” signal;
+they will be kept connected, but the signal will not be emitted
+unless the handler name is registered again.
WebKitUserMediaPermissionRequest represents a request for
+permission to decide whether WebKit should be allowed to access the user's
+audio and video source devices when requested through the getUserMedia API.
+
When a WebKitUserMediaPermissionRequest is not handled by the user,
+it is denied by default.
Create a new ephemeral WebKitWebContext. An ephemeral WebKitWebContext is a context
+created with an ephemeral WebKitWebsiteDataManager. This is just a convenient method
+to create ephemeral contexts without having to create your own WebKitWebsiteDataManager.
+All WebKitWebViews associated with this context will also be ephemeral. Websites will
+not store any data in the client storage.
+This is normally used to implement private instances.
Set whether automation is allowed in context
+. When automation is enabled the browser could
+be controlled by another process by requesting an automation session. When a new automation
+session is requested the signal “automation-started” is emitted.
+Automation is disabled by default, so you need to explicitly call this method passing TRUE
+to enable it.
+
Note that only one WebKitWebContext can have automation enabled, so this will do nothing
+if there's another WebKitWebContext with automation already enabled.
Specifies a usage model for WebViews, which WebKit will use to
+determine its caching behavior. All web views follow the cache
+model. This cache model determines the RAM and disk space to use
+for caching previously viewed content .
+
Research indicates that users tend to browse within clusters of
+documents that hold resources in common, and to revisit previously
+visited documents. WebKit and the frameworks below it include
+built-in caches that take advantage of these patterns,
+substantially improving document load speed in browsing
+situations. The WebKit cache model controls the behaviors of all of
+these caches, including various WebCore caches.
Sets the maximum number of web processes that can be created at the same time for the context
+.
+The default value is 0 and means no limit.
+
This method **must be called before any web process has been created**,
+as early as possible in your application. Calling it later will make
+your application crash.
Requests downloading of the specified URI string. The download operation
+will not be associated to any WebKitWebView, if you are interested in
+starting a download from a particular WebKitWebView use
+webkit_web_view_download_uri() instead.
Set the directory path to be used to store the favicons database
+for context
+ on disk. Passing NULL as path
+ means using the
+default directory for the platform (see g_get_user_cache_dir()).
+
Calling this method also means enabling the favicons database for
+its use from the applications, so that's why it's expected to be
+called only once. Further calls for the same instance of
+WebKitWebContext won't cause any effect.
Set the list of spell checking languages to be used for spell
+checking.
+
The locale string typically is in the form lang_COUNTRY, where lang
+is an ISO-639 language code, and COUNTRY is an ISO-3166 country code.
+For instance, sv_FI for Swedish as written in Finland or pt_BR
+for Portuguese as written in Brazil.
+
You need to call this function with a valid list of languages at
+least once in order to properly enable the spell checking feature
+in WebKit.
Set the list of preferred languages, sorted from most desirable
+to least desirable. The list will be used to build the "Accept-Language"
+header that will be included in the network requests started by
+the WebKitWebContext.
Set the directory where WebKit will look for Web Extensions.
+This method must be called before loading anything in this context,
+otherwise it will not have any effect. You can connect to
+“initialize-web-extensions” to call this method
+before anything is loaded.
Set user data to be passed to Web Extensions on initialization.
+The data will be passed to the
+WebKitWebExtensionInitializeWithUserDataFunction.
+This method must be called before loading anything in this context,
+otherwise it will not have any effect. You can connect to
+“initialize-web-extensions” to call this method
+before anything is loaded.
Specifies a process model for WebViews, which WebKit will use to
+determine how auxiliary processes are handled. The default setting
+(WEBKIT_PROCESS_MODEL_SHARED_SECONDARY_PROCESS) is suitable for most
+applications which embed a small amount of WebViews, or are used to
+display documents which are considered safe — like local files.
+
Applications which may potentially use a large amount of WebViews
+—for example a multi-tabbed web browser— may want to use
+WEBKIT_PROCESS_MODEL_MULTIPLE_SECONDARY_PROCESSES, which will use
+one process per view most of the time, while still allowing for web
+views to share a process when needed (for example when different
+views interact with each other). Using this model, when a process
+hangs or crashes, only the WebViews using it stop working, while
+the rest of the WebViews in the application will still function
+normally.
+
This method **must be called before any web process has been created**,
+as early as possible in your application. Calling it later will make
+your application crash.
Sets initial desktop notification permissions for the context
+.
+allowed_origins
+ and disallowed_origins
+ must each be GList of
+WebKitSecurityOrigin objects representing origins that will,
+respectively, either always or never have permission to show desktop
+notifications. No WebKitNotificationPermissionRequest will ever be
+generated for any of the security origins represented in
+allowed_origins
+ or disallowed_origins
+. This function is necessary
+because some webpages proactively check whether they have permission
+to display notifications without ever creating a permission request.
+
This function only affects web processes that have not already been
+created. The best time to call it is when handling
+“initialize-notification-permissions” so as to
+ensure that new web processes receive the most recent set of
+permissions.
staticvoid
+about_uri_scheme_request_cb(WebKitURISchemeRequest*request,
+gpointer user_data)
+{
+GInputStream*stream;
+gsize stream_length;
+constgchar*path;
+
+ path =webkit_uri_scheme_request_get_path(request);
+if(!g_strcmp0(path,"plugins")){
+/* Create a GInputStream with the contents of plugins about page, and set its length to stream_length */
+}elseif(!g_strcmp0(path,"memory")){
+/* Create a GInputStream with the contents of memory about page, and set its length to stream_length */
+}elseif(!g_strcmp0(path,"applications")){
+/* Create a GInputStream with the contents of applications about page, and set its length to stream_length */
+}elseif(!g_strcmp0(path,"example")){
+gchar*contents;
+
+ contents =g_strdup_printf("<html><body><p>Example about page</p></body></html>");
+ stream_length =strlen(contents);
+ stream =g_memory_input_stream_new_from_data(contents, stream_length,g_free);
+}else{
+GError*error;
+
+ error =g_error_new(ABOUT_HANDLER_ERROR, ABOUT_HANDLER_ERROR_INVALID,"Invalid about:%s page.", path);
+webkit_uri_scheme_request_finish_error(request, error);
+g_error_free(error);
+return;
+}
+webkit_uri_scheme_request_finish(request, stream, stream_length,"text/html");
+g_object_unref(stream);
+}
Enum values used for determining the WebKitWebContext cache model.
+
+
Members
+
+
+
+
+
+
+
+
+
WEBKIT_CACHE_MODEL_DOCUMENT_VIEWER
+
+
Disable the cache completely, which
+ substantially reduces memory usage. Useful for applications that only
+ access a single local file, with no navigation to other pages. No remote
+ resources will be cached.
+
+
+
+
+
WEBKIT_CACHE_MODEL_WEB_BROWSER
+
+
Improve document load speed substantially
+ by caching a very large number of resources and previously viewed content.
+
+
+
+
+
WEBKIT_CACHE_MODEL_DOCUMENT_BROWSER
+
+
A cache model optimized for viewing
+ a series of local files -- for example, a documentation viewer or a website
+ designer. WebKit will cache a moderate number of resources.
+
+
+
+
+
+
+
+
+
+
enum WebKitProcessModel
+
Enum values used for determining the WebKitWebContext process model.
+
+
Members
+
+
+
+
+
+
+
+
+
WEBKIT_PROCESS_MODEL_SHARED_SECONDARY_PROCESS
+
+
Use a single process to
+ perform content rendering. The process is shared among all the
+ WebKitWebView instances created by the application: if the process
+ hangs or crashes all the web views in the application will be affected.
+ This is the default process model, and it should suffice for most cases.
+
+
+
+
+
WEBKIT_PROCESS_MODEL_MULTIPLE_SECONDARY_PROCESSES
+
+
Use one process
+ for each WebKitWebView, while still allowing for some of them to
+ share a process in certain situations. The main advantage
+ of this process model is that the rendering process for a web view
+ can crash while the rest of the views keep working normally. This
+ process model is indicated for applications which may use a number
+ of web views and the content of in each must not interfere with the
+ rest — for example a full-fledged web browser with support for
+ multiple tabs.
+
+
+
+
+
+
+
Since: 2.4
+
+
+
+
enum WebKitTLSErrorsPolicy
+
Enum values used to denote the TLS errors policy.
+
+
Members
+
+
+
+
+
+
+
+
+
WEBKIT_TLS_ERRORS_POLICY_IGNORE
+
+
Ignore TLS errors.
+
+
+
+
+
WEBKIT_TLS_ERRORS_POLICY_FAIL
+
+
TLS errors will emit
+ “load-failed-with-tls-errors” and, if the signal is handled,
+ finish the load. In case the signal is not handled,
+ “load-failed” is emitted before the load finishes.
This signal is emitted when a new automation request is made.
+Note that it will never be emitted if automation is not enabled in context
+,
+see webkit_web_context_set_automation_allowed() for more details.
A WebKitWebResource encapsulates content for each resource at the
+end of a particular URI. For example, one WebKitWebResource will
+be created for each separate image and stylesheet when a page is
+loaded.
Returns the current active URI of resource
+. The active URI might change during
+a load operation:
+
+
+ When the resource load starts, the active URI is the requested URI
+
+
+ When the initial request is sent to the server, “sent-request”
+ signal is emitted without a redirected response, the active URI is the URI of
+ the request sent to the server.
+
+
+ In case of a server redirection, “sent-request” signal
+ is emitted again with a redirected response, the active URI is the URI the request
+ was redirected to.
+
+
+ When the response is received from the server, the active URI is the final
+ one and it will not change again.
+
+
+
You can monitor the active URI by connecting to the notify::uri
+signal of resource
+.
Retrieves the WebKitURIResponse of the resource load operation.
+This method returns NULL if called before the response
+is received from the server. You can connect to notify::response
+signal to be notified when the response is received.
When the operation is finished, callback
+ will be called. You can then call
+webkit_web_resource_get_data_finish() to get the result of the operation.
This signal is emitted when the resource load finishes successfully
+or due to an error. In case of errors “failed” signal
+is emitted before this one.
This signal is emitted after response is received,
+every time new data has been received. It's
+useful to know the progress of the resource load operation.
This signal is emitted when request
+ has been sent to the
+server. In case of a server redirection this signal is
+emitted again with the request
+ argument containing the new
+request sent to the server due to the redirection and the
+redirected_response
+ parameter containing the response
+received by the server for the initial request.
WebKitWebView is the central class of the WPE WebKit and WebKitGTK
+APIs. It is responsible for managing the drawing of the content and
+forwarding of events. You can load any URI into the WebKitWebView or
+a data string. With WebKitSettings you can control various aspects
+of the rendering and loading of the content.
Tries to close the web_view
+. This will fire the onbeforeunload event
+to ask the user for confirmation to close the page. If there isn't an
+onbeforeunload event handler or the user confirms to close the page,
+the “close” signal is emitted, otherwise nothing happens.
Load the given content
+ string with the specified base_uri
+.
+If base_uri
+ is not NULL, relative URLs in the content
+ will be
+resolved against base_uri
+ and absolute local paths must be children of the base_uri
+.
+For security reasons absolute local paths that are not children of base_uri
+
+will cause the web process to terminate.
+If you need to include URLs in content
+ that are local paths in a different
+directory than base_uri
+ you can build a data URI for them. When base_uri
+ is NULL,
+it defaults to "about:blank". The mime type of the document will be "text/html".
+You can monitor the load operation by connecting to “load-changed” signal.
Load the given content
+ string for the URI content_uri
+.
+This allows clients to display page-loading errors in the WebKitWebView itself.
+When this method is called from “load-failed” signal to show an
+error page, then the back-forward list is maintained appropriately.
+For everything else this method works the same way as webkit_web_view_load_html().
Load the specified plain_text
+ string into web_view
+. The mime type of
+document will be "text/plain". You can monitor the load
+operation by connecting to “load-changed” signal.
Load the specified bytes
+ into web_view
+ using the given mime_type
+ and encoding
+.
+When mime_type
+ is NULL, it defaults to "text/html".
+When encoding
+ is NULL, it defaults to "UTF-8".
+When base_uri
+ is NULL, it defaults to "about:blank".
+You can monitor the load operation by connecting to “load-changed” signal.
Stops any ongoing loading operation in web_view
+.
+This method does nothing if no content is being loaded.
+If there is a loading operation in progress, it will be cancelled and
+“load-failed” signal will be emitted with
+WEBKIT_NETWORK_ERROR_CANCELLED error.
Gets the value of the “is-loading” property.
+You can monitor when a WebKitWebView is loading a page by connecting to
+notify::is-loading signal of web_view
+. This is useful when you are
+interesting in knowing when the view is loading something but not in the
+details about the status of the load operation, for example to start a spinner
+when the view is loading a page and stop it when it finishes.
Gets the value of the “is-playing-audio” property.
+You can monitor when a page in a WebKitWebView is playing audio by
+connecting to the notify::is-playing-audio signal of web_view
+. This
+is useful when the application wants to provide visual feedback when a
+page is producing sound.
Gets the value of the “estimated-load-progress” property.
+You can monitor the estimated progress of a load operation by
+connecting to the notify::estimated-load-progress signal of web_view
+.
Sets the current custom character encoding override of web_view
+. The custom
+character encoding will override any text encoding detected via HTTP headers or
+META tags. Calling this method will stop any current load operation and reload the
+current page. Setting the custom character encoding to NULL removes the character
+encoding override.
+ If there is a server redirection during the load operation,
+ the active URI is the redirected URI. When the signal
+ “load-changed” is emitted with WEBKIT_LOAD_REDIRECTED
+ event, the active URI is already updated to the redirected URI.
+
+
+ When the signal “load-changed” is emitted
+ with WEBKIT_LOAD_COMMITTED event, the active URI is the final
+ one and it will not change unless a new load operation is started
+ or a navigation action within the same page is performed.
+
+
+
You can monitor the active URI by connecting to the notify::uri
+signal of web_view
+.
Sets the WebKitSettings to be applied to web_view
+. The
+existing WebKitSettings of web_view
+ will be replaced by
+settings
+. New settings are applied immediately on web_view
+.
+The same WebKitSettings object can be shared
+by multiple WebKitWebViews.
Request to execute the given command
+ with argument
+ for web_view
+. You can use
+webkit_web_view_can_execute_editing_command() to check whether
+it's possible to execute the command.
Asynchronously run script
+ in the context of the current page in web_view
+. If
+WebKitSettings:enable-javascript is FALSE, this method will do nothing.
Asynchronously run script
+ in the script world with name world_name
+ of the current page context in web_view
+.
+If WebKitSettings:enable-javascript is FALSE, this method will do nothing.
Asynchronously save the current web page associated to the
+WebKitWebView into a self-contained format using the mode
+specified in save_mode
+ and writing it to file
+.
+
When the operation is finished, callback
+ will be called. You can
+then call webkit_web_view_save_to_file_finish() to get the result of the
+operation.
Retrieves the GTlsCertificate associated with the main resource of web_view
+,
+and the GTlsCertificateFlags showing what problems, if any, have been found
+with that certificate.
+If the connection is not HTTPS, this function returns FALSE.
+This function should be called after a response has been received from the
+server, so you can connect to “load-changed” and call this function
+when it's emitted with WEBKIT_LOAD_COMMITTED event.
+
Note that this function provides no information about the security of the web
+page if the current WebKitTLSErrorsPolicy is WEBKIT_TLS_ERRORS_POLICY_IGNORE
+,
+as subresources of the page may be controlled by an attacker. This function
+may safely be used to determine the security status of the current page only
+if the current WebKitTLSErrorsPolicy is WEBKIT_TLS_ERRORS_POLICY_FAIL
+, in
+which case subresources that fail certificate verification will be blocked.
Sets whether the user is allowed to edit the HTML document.
+
If editable
+ is TRUE, web_view
+ allows the user to edit the HTML document. If
+editable
+ is FALSE, an element in web_view
+'s document can only be edited if the
+CONTENTEDITABLE attribute has been set on the element or one of its parent
+elements. By default a WebKitWebView is not editable.
+
Normally, a HTML document is not editable unless the elements within the
+document are editable. This function provides a way to make the contents
+of a WebKitWebView editable without altering the document or DOM structure.
Atomically decrements the reference count of js_result
+ by one. If the
+reference count drops to 0, all memory allocated by the WebKitJavascriptResult is
+released. This function is MT-safe and may be called from any
+thread.
Atomically decrements the reference count of dialog
+ by one. If the
+reference count drops to 0, all memory allocated by the WebKitScriptdialog is
+released. This function is MT-safe and may be called from any
+thread.
Close dialog
+. When handling a WebKitScriptDialog asynchronously (webkit_script_dialog_ref()
+was called in “script-dialog” callback), this function needs to be called to notify
+that we are done with the script dialog. The dialog will be closed on destruction if this function
+hasn't been called before.
Atomically decrements the reference count of state
+ by one. If the
+reference count drops to 0, all memory allocated by the WebKitWebViewSessionState is
+released. This function is MT-safe and may be called from any thread.
Enum values used to denote the different events that happen during a
+WebKitWebView load operation.
+
+
Members
+
+
+
+
+
+
+
+
+
WEBKIT_LOAD_STARTED
+
+
A new load request has been made.
+No data has been received yet, empty structures have
+been allocated to perform the load; the load may still
+fail due to transport issues such as not being able to
+resolve a name, or connect to a port.
+
+
+
+
+
WEBKIT_LOAD_REDIRECTED
+
+
A provisional data source received
+a server redirect.
+
+
+
+
+
WEBKIT_LOAD_COMMITTED
+
+
The content started arriving for a page load.
+The necessary transport requirements are established, and the
+load is being performed.
+
+
+
+
+
WEBKIT_LOAD_FINISHED
+
+
Load completed. All resources are done loading
+or there was an error during the load operation.
+
+
+
+
+
+
+
+
+
+
enum WebKitPolicyDecisionType
+
Enum values used for determining the type of a policy decision during
+“decide-policy”.
This type of policy decision
+ is requested when WebKit is about to create a new window. Acceptable policy
+ decisions are either webkit_policy_decision_use() or
+ webkit_policy_decision_ignore(). This type of policy decision is always
+ a WebKitNavigationPolicyDecision. These decisions are useful for implementing
+ special actions for new windows, such as forcing the new window to open
+ in a tab when a keyboard modifier is active or handling a special
+ target attribute on <a> elements.
+
+
+
+
+
WEBKIT_POLICY_DECISION_TYPE_RESPONSE
+
+
This type of decision is used when WebKit has
+ received a response for a network resource and is about to start the load.
+ Note that these resources include all subresources of a page such as images
+ and stylesheets as well as main documents. Appropriate policy responses to
+ this decision are webkit_policy_decision_use(), webkit_policy_decision_ignore(),
+ or webkit_policy_decision_download(). This type of policy decision is always
+ a WebKitResponsePolicyDecision. This decision is useful for forcing
+ some types of resources to be downloaded rather than rendered in the WebView
+ or to block the transfer of resources entirely.
+
+
+
+
+
+
+
+
+
+
enum WebKitSaveMode
+
Enum values to specify the different ways in which a WebKitWebView
+can save its current web page into a self-contained file.
+
+
Members
+
+
+
+
+
+
+
+
WEBKIT_SAVE_MODE_MHTML
+
+
Save the current page using the MHTML format.
+
+
+
+
+
+
+
+
+
enum WebKitInsecureContentEvent
+
Enum values used to denote the different events which can trigger
+the detection of insecure content.
+
+
Members
+
+
+
+
+
+
+
+
+
WEBKIT_INSECURE_CONTENT_RUN
+
+
Insecure content has been detected by
+trying to execute any kind of logic (e.g. a script) from an
+untrusted source.
+
+
+
+
+
WEBKIT_INSECURE_CONTENT_DISPLAYED
+
+
Insecure content has been
+detected by trying to display any kind of resource (e.g. an image)
+from an untrusted source.
+
+
+
+
+
+
+
+
+
+
enum WebKitWebProcessTerminationReason
+
Enum values used to specify the reason why the web process terminated abnormally.
The cut clipboard command. Copies the current selection inside
+a WebKitWebView to the clipboard and deletes the selected content.
+You can check whether it's possible to execute the command with
+webkit_web_view_can_execute_editing_command(). In general it's
+possible to cut to the clipboard when the WebKitWebView content is
+editable and there is an active selection.
+
+
+
+
WEBKIT_EDITING_COMMAND_COPY
+
#define WEBKIT_EDITING_COMMAND_COPY "Copy"
+
+
The copy clipboard command. Copies the current selection inside
+a WebKitWebView to the clipboard.
+You can check whether it's possible to execute the command with
+webkit_web_view_can_execute_editing_command(). In general it's
+possible to copy to the clipboard when there is an active selection
+inside the WebKitWebView.
+
+
+
+
WEBKIT_EDITING_COMMAND_PASTE
+
#define WEBKIT_EDITING_COMMAND_PASTE "Paste"
+
+
The paste clipboard command. Pastes the contents of the clipboard to
+a WebKitWebView.
+You can check whether it's possible to execute the command with
+webkit_web_view_can_execute_editing_command(). In general it's possible
+to paste from the clipboard when the WebKitWebView content is editable
+and clipboard is not empty.
The undo command. Undoes the last editing command in a WebKitWebView.
+You can check whether it's possible to execute the command with
+webkit_web_view_can_execute_editing_command(). It's only possible
+to undo a command after a previously executed editing operation.
+
+
+
+
WEBKIT_EDITING_COMMAND_REDO
+
#define WEBKIT_EDITING_COMMAND_REDO "Redo"
+
+
The redo command. Redoes a previously undone editing command in
+a WebKitWebView.
+You can check whether it's possible to execute the command with
+webkit_web_view_can_execute_editing_command(). It's only possible
+to redo a command when it has been previously undone.
The insert image command. Creates an image element that is inserted at
+the current cursor position. It receives an URI as argument,
+that is used as the image source. This command should be executed with
+webkit_web_view_execute_editing_command_with_argument().
The create link command. Creates a link element that is inserted at
+the current cursor position. If there's a selection, the selected text
+will be used as the link text, otherwise the URL itself will be used.
+It receives the link URL as argument. This command should be executed
+with webkit_web_view_execute_editing_command_with_argument()
An estimate of the percent completion for the current loading operation.
+This value will range from 0.0 to 1.0 and, once a load completes,
+will remain at 1.0 until a new load starts, at which point it
+will be reset to 0.0.
+The value is an estimate based on the total number of bytes expected
+to be received for a document, including all its possible subresources
+and child documents.
Whether the WebKitWebView is currently loading a page. This property becomes
+TRUE as soon as a new load operation is requested and before the
+“load-changed” signal is emitted with WEBKIT_LOAD_STARTED and
+at that point the active URI is the requested one.
+When the load operation finishes the property is set to FALSE before
+“load-changed” is emitted with WEBKIT_LOAD_FINISHED.
Whether the WebKitWebView is currently playing audio from a page.
+This property becomes TRUE as soon as web content starts playing any
+kind of audio. When a page is no longer playing any kind of sound,
+the property is set back to FALSE.
The related WebKitWebView used when creating the view to share the
+same web process. This property is not readable because the related
+web view is only valid during the object construction.
This signal is emitted when the user is challenged with HTTP
+authentication. To let the application access or supply
+the credentials as well as to allow the client application
+to either cancel the request or perform the authentication,
+the signal will pass an instance of the
+WebKitAuthenticationRequest in the request
+ argument.
+To handle this signal asynchronously you should keep a ref
+of the request and return TRUE. To disable HTTP authentication
+entirely, connect to this signal and simply return TRUE.
+
The default signal handler will run a default authentication
+dialog asynchronously for the user to interact with.
Emitted when closing a WebKitWebView is requested. This occurs when a
+call is made from JavaScript's window.close function or
+after trying to close the web_view
+ with webkit_web_view_try_close().
+It is the owner's responsibility to handle this signal to hide or
+destroy the WebKitWebView, if necessary.
Emitted when a context menu is about to be displayed to give the application
+a chance to customize the proposed menu, prevent the menu from being displayed,
+or build its own context menu.
+ To prevent the menu from being displayed you can just connect to this signal
+ and return TRUE so that the proposed menu will not be shown.
+
+
+ To build your own menu, you can remove all items from the proposed menu with
+ webkit_context_menu_remove_all(), add your own items and return FALSE so
+ that the menu will be shown. You can also ignore the proposed WebKitContextMenu,
+ build your own GtkMenu and return TRUE to prevent the proposed menu from being shown.
+
+
+ If you just want the default menu to be shown always, simply don't connect to this
+ signal because showing the proposed context menu is the default behaviour.
+
+
+
The event
+ is expected to be one of the following types:
If the signal handler returns FALSE the context menu represented by context_menu
+
+will be shown, if it return TRUE the context menu will not be shown.
+
The proposed WebKitContextMenu passed in context_menu
+ argument is only valid
+during the signal emission.
Emitted when the creation of a new WebKitWebView is requested.
+If this signal is handled the signal handler should return the
+newly created WebKitWebView.
+
The WebKitNavigationAction parameter contains information about the
+navigation action that triggered this signal.
This signal is emitted when WebKit is requesting the client to decide a policy
+decision, such as whether to navigate to a page, open a new window or whether or
+not to download a resource. The WebKitNavigationPolicyDecision passed in the
+decision
+ argument is a generic type, but should be casted to a more
+specific type when making the decision. For example:
staticgboolean
+decide_policy_cb(WebKitWebView*web_view,
+WebKitPolicyDecision*decision,
+WebKitPolicyDecisionType type)
+{
+switch(type){
+caseWEBKIT_POLICY_DECISION_TYPE_NAVIGATION_ACTION:{
+WebKitNavigationPolicyDecision*navigation_decision =WEBKIT_NAVIGATION_POLICY_DECISION(decision);
+/* Make a policy decision here. */
+break;
+}
+caseWEBKIT_POLICY_DECISION_TYPE_NEW_WINDOW_ACTION:{
+WebKitNavigationPolicyDecision*navigation_decision =WEBKIT_NAVIGATION_POLICY_DECISION(decision);
+/* Make a policy decision here. */
+break;
+}
+caseWEBKIT_POLICY_DECISION_TYPE_RESPONSE:
+WebKitResponsePolicyDecision*response =WEBKIT_RESPONSE_POLICY_DECISION(decision);
+/* Make a policy decision here. */
+break;
+ default:
+/* Making no decision results in webkit_policy_decision_use(). */
+returnFALSE;
+}
+returnTRUE;
+}
+
+
+
+
+
+
It is possible to make policy decision asynchronously, by simply calling g_object_ref()
+on the decision
+ argument and returning TRUE to block the default signal handler.
+If the last reference is removed on a WebKitPolicyDecision and no decision has been
+made explicitly, webkit_policy_decision_use() will be the default policy decision. The
+default signal handler will simply call webkit_policy_decision_use(). Only the first
+policy decision chosen for a given WebKitPolicyDecision will have any affect.
Emitted when JavaScript code calls
+element.webkitRequestFullScreen. If the
+signal is not handled the WebKitWebView will proceed to full screen
+its top level window. This signal can be used by client code to
+request permission to the user prior doing the full screen
+transition and eventually prepare the top-level window
+(e.g. hide some widgets that would otherwise be part of the
+full screen window).
This signal is emitted when insecure content has been detected
+in a page loaded through a secure connection. This typically
+means that a external resource from an unstrusted source has
+been run or displayed, resulting in a mix of HTTPS and
+non-HTTPS content.
+
You can check the event
+ parameter to know exactly which kind
+of event has been detected (see WebKitInsecureContentEvent).
Emitted when the WebKitWebView is about to restore its top level
+window out of its full screen state. This signal can be used by
+client code to restore widgets hidden during the
+“enter-fullscreen” stage for instance.
staticvoidweb_view_load_changed(WebKitWebView*web_view,
+WebKitLoadEvent load_event,
+gpointer user_data)
+{
+switch(load_event){
+caseWEBKIT_LOAD_STARTED:
+/* New load, we have now a provisional URI */
+ provisional_uri =webkit_web_view_get_uri(web_view);
+/* Here we could start a spinner or update the
+ * location bar with the provisional URI */
+break;
+caseWEBKIT_LOAD_REDIRECTED:
+ redirected_uri =webkit_web_view_get_uri(web_view);
+break;
+caseWEBKIT_LOAD_COMMITTED:
+/* The load is being performed. Current URI is
+ * the final one and it won't change unless a new
+ * load is requested or a navigation within the
+ * same page is performed */
+ uri =webkit_web_view_get_uri(web_view);
+break;
+caseWEBKIT_LOAD_FINISHED:
+/* Load finished, we can now stop the spinner */
+break;
+}
+}
Emitted when an error occurs during a load operation.
+If the error happened when starting to load data for a page
+load_event
+ will be WEBKIT_LOAD_STARTED. If it happened while
+loading a committed data source load_event
+ will be WEBKIT_LOAD_COMMITTED.
+Since a load error causes the load operation to finish, the signal
+WebKitWebView::load-changed will always be emitted with
+WEBKIT_LOAD_FINISHED event right after this one.
+
By default, if the signal is not handled, a stock error page will be displayed.
+You need to handle the signal if you want to provide your own error page.
This signal is emitted when the mouse cursor moves over an
+element such as a link, image or a media element. To determine
+what type of element the mouse cursor is over, a Hit Test is performed
+on the current mouse coordinates and the result is passed in the
+hit_test_result
+ argument. The modifiers
+ argument is a bitmask of
+GdkModifierType flags indicating the state of modifier keys.
+The signal is emitted again when the mouse is moved out of the
+current element with a new hit_test_result
+.
This signal is emitted when WebKit is requesting the client to
+decide about a permission request, such as allowing the browser
+to switch to fullscreen mode, sharing its location or similar
+operations.
+
A possible way to use this signal could be through a dialog
+allowing the user decide what to do with the request:
It is possible to handle permission requests asynchronously, by
+simply calling g_object_ref() on the request
+ argument and
+returning TRUE to block the default signal handler. If the
+last reference is removed on a WebKitPermissionRequest and the
+request has not been handled, webkit_permission_request_deny()
+will be the default action.
+
If the signal is not handled, the request
+ will be completed automatically
+by the specific WebKitPermissionRequest that could allow or deny it. Check the
+documentation of classes implementing WebKitPermissionRequest interface to know
+their default action.
Emitted after “create” on the newly created WebKitWebView
+when it should be displayed to the user. When this signal is emitted
+all the information about how the window should look, including
+size, position, whether the location, status and scrollbars
+should be displayed, is already set on the WebKitWindowProperties
+of web_view
+. See also webkit_web_view_get_window_properties().
Emitted when a new resource is going to be loaded. The request
+ parameter
+contains the WebKitURIRequest that will be sent to the server.
+You can monitor the load operation by connecting to the different signals
+of resource
+.
Emitted after “ready-to-show” on the newly
+created WebKitWebView when JavaScript code calls
+window.showModalDialog. The purpose of
+this signal is to allow the client application to prepare the
+new view to behave as modal. Once the signal is emitted a new
+main loop will be run to block user interaction in the parent
+WebKitWebView until the new dialog is closed.
This signal is emitted when the user interacts with a <input
+type='file' /> HTML element, requesting from WebKit to show
+a dialog to select one or more files to be uploaded. To let the
+application know the details of the file chooser, as well as to
+allow the client application to either cancel the request or
+perform an actual selection of files, the signal will pass an
+instance of the WebKitFileChooserRequest in the request
+
+argument.
+
The default signal handler will asynchronously run a regular
+GtkFileChooserDialog for the user to interact with.
Emitted when JavaScript code calls window.alert,
+window.confirm or window.prompt,
+or when onbeforeunload event is fired.
+The dialog
+ parameter should be used to build the dialog.
+If the signal is not handled a different dialog will be built and shown depending
+on the dialog type:
This signal is emitted when a notification should be presented to the
+user. The notification
+ is kept alive until either: 1) the web page cancels it
+or 2) a navigation happens.
+
The default handler will emit a notification using libnotify, if built with
+support for it.
This signal is emitted when a form is about to be submitted. The request
+
+argument passed contains information about the text fields of the form. This
+is typically used to store login information that can be used later to
+pre-fill the form.
+The form will not be submitted until webkit_form_submission_request_submit() is called.
A WebKitWebViewBackend is a boxed type wrapping a WPE backend used to create a
+WebKitWebView. A WebKitWebViewBackend is created with webkit_web_view_backend_new()
+and it should be passed to a WebKitWebView constructor that will take the ownership.
Create a new WebKitWebViewBackend for the given WPE backend
+. You can pass a GDestroyNotify
+that will be called when the object is destroyed passing user_data
+ as the argument. If notify
+
+is NULL, wpe_view_backend_destroy() will be used with backend
+ as argument.
+The returned WebKitWebViewBackend should never be freed by the user; it must be passed to a
+WebKitWebView constructor that will take the ownership.
WebKitWebsiteData represents data stored in the client by a particular website.
+A website is normally a set of URLs grouped by domain name. You can get the website name,
+which is usually the domain, with webkit_website_data_get_name().
+Documents loaded from the file system, like file:// URIs, are all grouped in the same WebKitWebsiteData
+with the name "Local files".
Atomically decrements the reference count of website_data
+ by one.
+If the reference count drops to 0, all memory allocated by
+WebKitWebsiteData is released. This function is MT-safe and may be
+called from any thread.
Gets the name of WebKitWebsiteData. This is the website name, normally represented by
+a domain or host name. All local documents are grouped in the same WebKitWebsiteData using
+the name "Local files".
Gets the size of the data of types types
+ in a WebKitWebsiteData.
+Note that currently the data size is only known for WEBKIT_WEBSITE_DATA_DISK_CACHE data type
+so for all other types 0 will be returned.
WebKitWebsiteDataManager allows you to manage the data that websites
+can store in the client file system like databases or caches.
+You can use WebKitWebsiteDataManager to configure the local directories
+where the Website data will be stored, by creating a new manager with
+webkit_website_data_manager_new() passing the values you want to set.
+You can set all the possible configuration values or only some of them,
+a default value will be used automatically for the configuration options
+not provided. “base-data-directory” and
+“base-cache-directory” are two special properties
+that can be used to set a common base directory for all Website data and
+caches. It's possible to provide both, a base directory and a specific value,
+but in that case, the specific value takes precedence over the base directory.
+The newly created WebKitWebsiteDataManager must be passed as a construct property
+to a WebKitWebContext, you can use webkit_web_context_new_with_website_data_manager()
+to create a new WebKitWebContext with a WebKitWebsiteDataManager.
+In case you don't want to set any specific configuration, you don't need to create
+a WebKitWebsiteDataManager, the WebKitWebContext will create a WebKitWebsiteDataManager
+with the default configuration. To get the WebKitWebsiteDataManager of a WebKitWebContext
+you can use webkit_web_context_get_website_data_manager().
+
A WebKitWebsiteDataManager can also be ephemeral and then all the directories configuration
+is not needed because website data will never persist. You can create an ephemeral WebKitWebsiteDataManager
+with webkit_website_data_manager_new_ephemeral(). Then you can pass an ephemeral WebKitWebsiteDataManager to
+a WebKitWebContext to make it ephemeral or use webkit_web_context_new_ephemeral() and the WebKitWebsiteDataManager
+will be automatically created by the WebKitWebContext.
+
WebKitWebsiteDataManager can also be used to fetch websites data, remove data
+stored by particular websites, or clear data for all websites modified since a given
+period of time.
Asynchronously removes the website data of the for the given types
+ for websites in the given website_data
+ list.
+Use webkit_website_data_manager_clear() if you want to remove the website data for all sites.
Due to implementation limitations, this function does not currently delete
+any stored cookies if timespan
+ is nonzero. This behavior may change in the
+future.
Whether the WebKitWebsiteDataManager is ephemeral. An ephemeral WebKitWebsiteDataManager
+handles all websites data as non-persistent, and nothing will be written to the client
+storage. Note that if you create an ephemeral WebKitWebsiteDataManager all other construction
+parameters to configure data directories will be ignored.
The content of a WebKitWebView can request to change certain
+properties of the window containing the view. This can include the x, y position
+of the window, the width and height but also if a toolbar,
+scrollbar, statusbar, locationbar should be visible to the user,
+and the request to show the WebKitWebView fullscreen.
+
The “ready-to-show” signal handler is the proper place
+to apply the initial window properties. Then you can monitor the
+WebKitWindowProperties by connecting to ::notify signal.
Use this function to format a URI for display. The URIs used internally by
+WebKit may contain percent-encoded characters or Punycode, which are not
+generally suitable to display to users. This function provides protection
+against IDN homograph attacks, so in some cases the host part of the returned
+URI may be in Punycode if the safety check fails.
+
+
Parameters
+
+
+
+
+
+
+
+
uri
+
the URI to be converted
+
+
+
+
+
+
Returns
+
uri
+suitable for display, or NULL in
+case of error.
+
[nullable][transfer full]
+
+
Since: 2.24
+
+
+
+
Types and Values
+
+
+
+
+
\ No newline at end of file
diff --git a/aperezdc/learn-discover-rework/reference/wpewebkit/2.23.90/wpe-0.1-WebKitUserContent/index.html b/aperezdc/learn-discover-rework/reference/wpewebkit/2.23.90/wpe-0.1-WebKitUserContent/index.html
new file mode 100644
index 000000000..52d259d99
--- /dev/null
+++ b/aperezdc/learn-discover-rework/reference/wpewebkit/2.23.90/wpe-0.1-WebKitUserContent/index.html
@@ -0,0 +1,747 @@
+
+
+
+
+User content: WPE Reference Manual
+
+
+
+
+
+
+
+
+
+
Atomically decrements the reference count of user_style_sheet
+ by one.
+If the reference count drops to 0, all memory allocated by
+WebKitUserStyleSheet is released. This function is MT-safe and may be
+called from any thread.
Creates a new user style sheet. Style sheets can be applied to some URIs
+only by passing non-null values for whitelist
+ or blacklist
+. Passing a
+NULL whitelist implies that all URIs are on the whitelist. The style
+sheet is applied if an URI matches the whitelist and not the blacklist.
+URI patterns must be of the form [protocol]://[host]/[path], where the
+*host* and *path* components can contain the wildcard character (*) to
+represent zero or more other characters.
Atomically decrements the reference count of user_script
+ by one.
+If the reference count drops to 0, all memory allocated by
+WebKitUserScript is released. This function is MT-safe and may be called
+from any thread.
Creates a new user script. Scripts can be applied to some URIs
+only by passing non-null values for whitelist
+ or blacklist
+. Passing a
+NULL whitelist implies that all URIs are on the whitelist. The script
+is applied if an URI matches the whitelist and not the blacklist.
+URI patterns must be of the form [protocol]://[host]/[path], where the
+*host* and *path* components can contain the wildcard character (*) to
+represent zero or more other characters.
Atomically decrements the reference count of user_content_filter
+ by one.
+If the reference count drops to 0, all the memory allocated by the
+WebKitUserContentFilter is released. This function is MT-safe and may
+be called from any thread.
Atomically decrements the reference count of info
+ by one. If the
+reference count drops to 0, all memory allocated by the WebKitApplicationInfo is
+released. This function is MT-safe and may be called from any
+thread.
Set the application version. If the application doesn't use the format
+major.minor.micro you can pass 0 as the micro to use major.minor, or pass
+0 as both micro and minor to use only major number. Any other format must
+be converted to major.minor.micro so that it can be used in version comparisons.
Whenever a client attempts to load a page protected by HTTP
+authentication, credentials will need to be provided to authorize access.
+To allow the client to decide how it wishes to handle authentication,
+WebKit will fire a “authenticate” signal with a
+WebKitAuthenticationRequest object to provide client side
+authentication support. Credentials are exposed through the
+WebKitCredential object.
+
In case the client application does not wish
+to handle this signal WebKit will provide a default handler. To handle
+authentication asynchronously, simply increase the reference count of the
+WebKitAuthenticationRequest object.
Determine whether the authentication method associated with this
+WebKitAuthenticationRequest should allow the storage of credentials.
+This will return FALSE if WebKit doesn't support credential storing
+or if private browsing is enabled.
Get the WebKitCredential of the proposed authentication challenge that was
+stored from a previous session. The client can use this directly for
+authentication or construct their own WebKitCredential.
This signal is emitted when the user authentication request is
+cancelled. It allows the application to dismiss its authentication
+dialog in case of page load failure for example.
WebKitAutomationSession represents an automation session of a WebKitWebContext.
+When a new session is requested, a WebKitAutomationSession is created and the signal
+WebKitWebContext::automation-started is emitted with the WebKitAutomationSession as
+argument. Then, the automation client can request the session to create a new
+WebKitWebView to interact with it. When this happens the signal “create-web-view”
+is emitted.
Set the application information to session
+. This information will be used by the driver service
+to match the requested capabilities with the actual application information. If this information
+is not provided to the session when a new automation session is requested, the creation might fail
+if the client requested a specific browser name or version. This will not have any effect when called
+after the automation session has been fully created, so this must be called in the callback of
+“automation-started” signal.
This signal is emitted when the automation client requests a new
+browsing context to interact with it. The callback handler should
+return a WebKitWebView created with “is-controlled-by-automation”
+construct property enabled. The returned WebKitWebView could be an existing
+web view or a new one created and added to a new tab or window.
WebKitBackForwardList maintains a list of visited pages used to
+navigate to recent pages. Items are inserted in the list in the
+order they are visited.
+
WebKitBackForwardList also maintains the notion of the current item
+(which is always at index 0), the preceding item (which is at index -1),
+and the following item (which is at index 1).
+Methods webkit_web_view_go_back() and webkit_web_view_go_forward() move
+the current item backward or forward by one. Method
+webkit_web_view_go_to_back_forward_list_item() sets the current item to the
+specified item. All other methods returning WebKitBackForwardListItems
+do not change the value of the current item, they just return the requested
+item or items.
This signal is emitted when back_forward_list
+ changes. This happens
+when the current item is updated, a new item is added or one or more
+items are removed. Note that both item_added
+ and items_removed
+ can
+NULL when only the current item is updated. Items are only removed
+when the list is cleared or the maximum items limit is reached.
Inserts item
+ into the menu
+ at the given position.
+If position
+ is negative, or is larger than the number of items
+in the WebKitContextMenu, the item is added on to the end of
+the menu
+. The first position is 0.
Moves item
+ to the given position in the menu
+.
+If position
+ is negative, or is larger than the number of items
+in the WebKitContextMenu, the item is added on to the end of
+the menu
+.
+The first position is 0.
Sets user data to menu
+.
+This function can be used from a Web Process extension to set user data
+that can be retrieved from the UI Process using webkit_context_menu_get_user_data().
+If the user_data
+ GVariant is floating, it is consumed.
Gets the user data of menu
+.
+This function can be used from the UI Process to get user data previously set
+from the Web Process with webkit_context_menu_set_user_data().
Creates a new WebKitContextMenuItem for the given stock action.
+Stock actions are handled automatically by WebKit so that, for example,
+when a menu item created with a WEBKIT_CONTEXT_MENU_ACTION_STOP is
+activated the action associated will be handled by WebKit and the current
+load operation will be stopped. You can get the GtkAction of a
+WebKitContextMenuItem created with a WebKitContextMenuAction with
+webkit_context_menu_item_get_action() and connect to “activate” signal
+to be notified when the item is activated. But you can't prevent the associated
+action from being performed.
Set the filename
+ where non-session cookies are stored persistently using
+storage
+ as the format to read/write the cookies.
+Cookies are initially read from filename
+ to create an initial set of cookies.
+Then, non-session cookies will be written to filename
+ when the WebKitCookieManager::changed
+signal is emitted.
+By default, cookie_manager
+ doesn't store the cookies persistently, so you need to call this
+method to keep cookies saved across sessions.
WebKitDownload carries information about a download request and
+response, including a WebKitURIRequest and a WebKitURIResponse
+objects. The application may use this object to control the
+download process, or to simply figure out what is to be downloaded,
+and handle the download process itself.
Obtains the URI to which the downloaded file will be written. You
+can connect to “created-destination” to make
+sure this method returns a valid destination.
Sets the URI to which the downloaded file will be written.
+This method should be called before the download transfer
+starts or it will not have any effect on the ongoing download
+operation. To set the destination using the filename suggested
+by the server connect to “decide-destination”
+signal and call webkit_download_set_destination(). If you want to
+set a fixed destination URI that doesn't depend on the suggested
+filename you can connect to notify::response signal and call
+webkit_download_set_destination().
+If “decide-destination” signal is not handled
+and destination URI is not set when the download transfer starts,
+the file will be saved with the filename suggested by the server in
+G_USER_DIRECTORY_DOWNLOAD directory.
Retrieves the WebKitURIResponse object that backs the download
+process. This method returns NULL if called before the response
+is received from the server. You can connect to notify::response
+signal to be notified when the response is received.
Gets the value of the “estimated-progress” property.
+You can monitor the estimated progress of the download operation by
+connecting to the notify::estimated-progress signal of download
+.
Gets the elapsed time in seconds, including any fractional part.
+If the download finished, had an error or was cancelled this is
+the time between its start and the event.
Returns the current value of the “allow-overwrite” property,
+which determines whether the download will overwrite an existing file on
+disk, or if it will fail if the destination already exists.
Sets the “allow-overwrite” property, which determines whether
+the download may overwrite an existing file on disk, or if it will fail if
+the destination already exists.
Whether or not the download is allowed to overwrite an existing file on
+disk. If this property is FALSE and the destination already exists,
+the download will fail.
An estimate of the percent completion for the download operation.
+This value will range from 0.0 to 1.0. The value is an estimate
+based on the total number of bytes expected to be received for
+a download.
+If you need a more accurate progress information you can connect to
+“received-data” signal to track the progress.
This signal is emitted after “decide-destination” and before
+“received-data” to notify that destination file has been
+created successfully at destination
+.
This signal is emitted after response is received to
+decide a destination URI for the download. If this signal is not
+handled the file will be downloaded to G_USER_DIRECTORY_DOWNLOAD
+directory using suggested_filename
+.
This signal is emitted when an error occurs during the download
+operation. The given error
+, of the domain WEBKIT_DOWNLOAD_ERROR,
+contains further details of the failure. If the download is cancelled
+with webkit_download_cancel(), this signal is emitted with error
+WEBKIT_DOWNLOAD_ERROR_CANCELLED_BY_USER. The download operation finishes
+after an error and “finished” signal is emitted after this one.
This signal is emitted after response is received,
+every time new data has been written to the destination. It's
+useful to know the progress of the download operation.
Gets the typing attributes at the current cursor position.
+If there is a selection, this returns the typing attributes
+of the selected text. Note that in case of a selection,
+typing attributes are considered active only when they are
+present throughout the selection.
WebKit will automatically look for available icons in <link>
+elements on opened pages as well as an existing favicon.ico and
+load the images found into a memory cache if possible. That cache
+is frozen to an on-disk database for persistence.
+
If “enable-private-browsing” is TRUE, new icons
+won't be added to the on-disk database and no existing icons will
+be deleted from it. Nevertheless, WebKit will still store them in
+the in-memory cache during the current execution.
This signal is emitted when the favicon URI of page_uri
+ has
+been changed to favicon_uri
+ in the database. You can connect
+to this signal and call webkit_favicon_database_get_favicon()
+to get the favicon. If you are interested in the favicon of a
+WebKitWebView it's easier to use the “favicon”
+property. See webkit_web_view_get_favicon() for more details.
+
+
Parameters
+
+
+
+
+
+
+
+
+
database
+
the object on which the signal is emitted
+
+
+
+
page_uri
+
the URI of the Web page containing the icon
+
+
+
+
favicon_uri
+
the URI of the favicon
+
+
+
+
user_data
+
user data set when the signal handler was connected.
Whenever the user interacts with an <input type='file' />
+HTML element, WebKit will need to show a dialog to choose one or
+more files to be uploaded to the server along with the rest of the
+form data. For that to happen in a general way, instead of just
+opening a GtkFileChooserDialog (which might be not desirable in
+some cases, which could prefer to use their own file chooser
+dialog), WebKit will fire the “run-file-chooser”
+signal with a WebKitFileChooserRequest object, which will allow
+the client application to specify the files to be selected, to
+inspect the details of the request (e.g. if multiple selection
+should be allowed) and to cancel the request, in case nothing was
+selected.
+
In case the client application does not wish to handle this signal,
+WebKit will provide a default handler which will asynchronously run
+a regular GtkFileChooserDialog for the user to interact with.
Get the list of MIME types the file chooser dialog should handle,
+in the format specified in RFC 2046 for "media types". Its contents
+depend on the value of the 'accept' attribute for HTML input
+elements. This function should normally be called before presenting
+the file chooser dialog to the user, to decide whether to allow the
+user to select multiple files at once or only one.
a
+NULL-terminated array of strings if a list of accepted MIME types
+is defined or NULL otherwise, meaning that any MIME type should be
+accepted. This array and its contents are owned by WebKit and
+should not be modified or freed.
Determine whether the file chooser associated to this
+WebKitFileChooserRequest should allow selecting multiple files,
+which depends on the HTML input element having a 'multiple'
+attribute defined.
Get the list of selected files currently associated to the
+request. Initially, the return value of this method contains any
+files selected in previous file chooser requests for this HTML
+input element. Once webkit_file_chooser_request_select_files, the
+value will reflect whatever files are given.
+
This function should normally be called only before presenting the
+file chooser dialog to the user, to decide whether to perform some
+extra action, like pre-selecting the files from a previous request.
a
+NULL-terminated array of strings if there are selected files
+associated with the request or NULL otherwise. This array and its
+contents are owned by WebKit and should not be modified or
+freed.
Ask WebKit to cancel the request. It's important to do this in case
+no selection has been made in the client, otherwise the request
+won't be properly completed and the browser will keep the request
+pending forever, which might cause the browser to hang.
Looks for search_text
+ in the WebKitWebView associated with
+find_controller
+ since the beginning of the document highlighting
+up to max_match_count
+ matches. The outcome of the search will be
+asynchronously provided by the “found-text”
+and “failed-to-find-text” signals.
Counts the number of matches for search_text
+ found in the
+WebKitWebView with the provided find_options
+. The number of
+matches will be provided by the
+“counted-matches” signal.
WebKitGeolocationPermissionRequest represents a request for
+permission to decide whether WebKit should provide the user's
+location to a website when requested through the Geolocation API.
+
When a WebKitGeolocationPermissionRequest is not handled by the user,
+it is denied by default.
+
When embedding web views in your application, you *must* configure an
+application identifier to allow web content to use geolocation services.
+The identifier *must* match the name of the .desktop file which describes
+the application, sans the suffix.
+
If your application uses GApplication (or any subclass like
+GtkApplication), WebKit will automatically use the identifier returned by
+g_application_get_application_id(). This is the recommended approach for
+enabling geolocation in applications.
+
If an identifier cannot be obtained through GApplication, the value
+returned by g_get_prgname() will be used instead as a fallback. For
+programs which cannot use GApplication, calling g_set_prgname() early
+during initialization is needed when the name of the executable on disk
+does not match the name of a valid .desktop file.
A Hit Test is an operation to get context information about a given
+point in a WebKitWebView. WebKitHitTestResult represents the
+result of a Hit Test. It provides context information about what is
+at the coordinates of the Hit Test, such as if there's a link,
+an image or a media.
the title of the link element in the coordinates of the Hit Test,
+or NULL if there isn't a link element in hit_test_result
+context or the
+link element doesn't have a title
the label of the link element in the coordinates of the Hit Test,
+or NULL if there isn't a link element in hit_test_result
+context or the
+link element doesn't have a label
WebKitInstallMissingMediaPluginsPermissionRequest represents a request for
+permission to decide whether WebKit should try to start a helper application to
+install missing media plugins when the media backend couldn't play a media because
+the required plugins were not available.
+
When a WebKitInstallMissingMediaPluginsPermissionRequest is not handled by the user,
+it is allowed by default.
Return the WebKitURIRequest associated with the navigation action.
+Modifications to the returned object are not taken
+into account when the request is sent over the network, and is intended
+only to aid in evaluating whether a navigation action should be taken or
+not. To modify requests before they are sent over the network the
+“send-request” signal can be used instead.
WebKitNavigationPolicyDecision represents a policy decision for events associated with
+navigations. If the value of “mouse-button” is not 0, then
+the navigation was triggered by a mouse event.
If this navigation request targets a new frame, this property contains
+the name of that frame. For example if the decision was triggered by clicking a
+link with a target attribute equal to "_blank", this property will contain the
+value of that attribute. In all other cases, this value will be NULL.
The default proxy URI will be used for any URI that doesn't match ignore_hosts
+, and doesn't match any
+of the schemes added with webkit_network_proxy_settings_add_proxy_for_scheme().
+If default_proxy_uri
+ starts with "socks://", it will be treated as referring to all three of the
+socks5, socks4a, and socks4 proxy types.
+
ignore_hosts
+ is a list of hostnames and IP addresses that the resolver should allow direct connections to.
+Entries can be in one of 4 formats:
+
+
+A hostname, such as "example.com", ".example.com", or "*.example.com", any of which match "example.com" or
+any subdomain of it.
+
+
+An IPv4 or IPv6 address, such as "192.168.1.1", which matches only that address.
+
+
+A hostname or IP address followed by a port, such as "example.com:80", which matches whatever the hostname or IP
+address would match, but only for URLs with the (explicitly) indicated port. In the case of an IPv6 address, the address
+part must appear in brackets: "[::1]:443"
+
+
+An IP address range, given by a base address and prefix length, such as "fe80::/10", which matches any address in that range.
+
+
+
Note that when dealing with Unicode hostnames, the matching is done against the ASCII form of the name.
+Also note that hostname exclusions apply only to connections made to hosts identified by name, and IP address exclusions apply only
+to connections made to hosts identified by address. That is, if example.com has an address of 192.168.1.1, and ignore_hosts
+
+contains only "192.168.1.1", then a connection to "example.com" will use the proxy, and a connection to 192.168.1.1" will not.
Adds a URI-scheme-specific proxy. URIs whose scheme matches uri_scheme
+ will be proxied via proxy_uri
+.
+As with the default proxy URI, if proxy_uri
+ starts with "socks://", it will be treated as referring to
+all three of the socks5, socks4a, and socks4 proxy types.
WebKitNotificationPermissionRequest represents a request for
+permission to decide whether WebKit should provide the user with
+notifications through the Web Notification API.
+
When a WebKitNotificationPermissionRequest is not handled by the user,
+it is denied by default.
There are situations where an embedder would need to ask the user
+for permission to do certain types of operations, such as switching
+to fullscreen mode or reporting the user's location through the
+standard Geolocation API. In those cases, WebKit will emit a
+“permission-request” signal with a
+WebKitPermissionRequest object attached to it.
This object represents a single plugin, found while scanning the
+various platform plugin directories. This object can be used to get
+more information about a plugin, and enable/disable it, allowing
+fine-grained control of plugins. The list of available plugins can
+be obtained from the WebKitWebContext, with
+webkit_web_context_get_plugins().
Atomically decrements the reference count of info
+ by one. If the
+reference count drops to 0, all memory allocated by the WebKitMimeInfo is
+released. This function is MT-safe and may be called from any
+thread.
Often WebKit allows the client to decide the policy for certain
+operations. For instance, a client may want to open a link in a new
+tab, block a navigation entirely, query the user or trigger a download
+instead of a navigation. In these cases WebKit will fire the
+“decide-policy” signal with a WebKitPolicyDecision
+object. If the signal handler does nothing, WebKit will act as if
+webkit_policy_decision_use() was called as soon as signal handling
+completes. To make a policy decision asynchronously, simply increment
+the reference count of the WebKitPolicyDecision object.
WebKitResponsePolicyDecision represents a policy decision for a
+resource response, whether from the network or the local system.
+A very common use case for these types of decision is deciding
+whether or not to download a particular resource or to load it
+normally.
Return the WebKitURIRequest associated with the response decision.
+Modifications to the returned object are not taken
+into account when the request is sent over the network, and is intended
+only to aid in evaluating whether a response decision should be taken or
+not. To modify requests before they are sent over the network the
+“send-request” signal can be used instead.
Register scheme
+ as a CORS (Cross-origin resource sharing) enabled scheme.
+This means that CORS requests are allowed. See W3C CORS specification
+http://www.w3.org/TR/cors/.
WebKitSecurityOrigin is a representation of a security domain
+defined by websites. A security origin normally consists of a
+protocol, a hostname, and a port number. It is also possible for a
+security origin to be opaque, as defined by the HTML standard, in
+which case it has no associated protocol, host, or port.
+
Websites with the same security origin can access each other's
+resources for client-side scripting or database access.
Create a new security origin from the provided URI. Components of
+uri
+ other than protocol, host, and port do not affect the created
+WebKitSecurityOrigin.
Atomically decrements the reference count of origin
+ by one.
+If the reference count drops to 0, all memory allocated by
+WebKitSecurityOrigin is released. This function is MT-safe and may be
+called from any thread.
Gets the port of origin
+. This function will always return 0 if the
+port is the default port for the given protocol. For example,
+http://example.com has the same security origin as
+http://example.com:80, and this function will return 0 for a
+WebKitSecurityOrigin constructed from either URI. It will also
+return 0 if origin
+ is opaque.
Gets a string representation of origin
+. The string representation
+is a valid URI with only protocol, host, and port components. It may
+be NULL, but usually only if origin
+ is opaque.
WebKitSettings can be applied to a WebKitWebView to control text charset,
+color, font sizes, printing mode, script support, loading of images and various
+other things on a WebKitWebView. After creation, a WebKitSettings object
+contains default settings.
Set the “user-agent” property by appending the application details to the default user
+agent. If no application name or version is given, the default user agent used will be used. If only
+the version is given, the default engine version is used with the given application name.
Whether file access is allowed from file URLs. By default, when
+something is loaded in a WebKitWebView using a file URI, cross
+origin requests to other file resources are not allowed. This
+setting allows you to change that behaviour, so that it would be
+possible to do a XMLHttpRequest of a local file, for example.
Determine whether it's allowed to create and run modal dialogs
+from a WebKitWebView through JavaScript with
+window.showModalDialog. If it's set to
+FALSE, the associated WebKitWebView won't be able to create
+new modal dialogs, so not even the “create”
+signal will be emitted.
+
Flags: Read / Write / Construct
+
Default value: FALSE
+
+
+
+
The “allow-universal-access-from-file-urls” property
Whether or not JavaScript running in the context of a file scheme URL
+should be allowed to access content from any origin. By default, when
+something is loaded in a WebKitWebView using a file scheme URL,
+access to the local file system and arbitrary local storage is not
+allowed. This setting allows you to change that behaviour, so that
+it would be possible to use local storage, for example.
Determines whether images should be automatically loaded or not.
+On devices where network bandwidth is of concern, it might be
+useful to turn this property off.
Whether to draw compositing borders and repaint counters on layers drawn
+with accelerated compositing. This is useful for debugging issues related
+to web content that is composited with the GPU.
Enable or disable accelerated 2D canvas. Accelerated 2D canvas is only available
+if WebKit was compiled with a version of Cairo including the unstable CairoGL API.
+When accelerated 2D canvas is enabled, WebKit may render some 2D canvas content
+using hardware accelerated drawing operations.
Enable or disable support for Encrypted Media API on pages.
+EncryptedMedia is an experimental JavaScript API for playing encrypted media in HTML.
+This property will only work as intended if the EncryptedMedia feature is enabled at build time
+with the ENABLE_ENCRYPTED_MEDIA flag.
Whether to enable the frame flattening. With this setting each subframe is expanded
+to its contents, which will flatten all the frames to become one scrollable page.
+On touch devices scrollable subframes on a page can result in a confusing user experience.
Whether to enable the Javascript Fullscreen API. The API
+allows any HTML element to request fullscreen display. See also
+the current draft of the spec:
+http://www.w3.org/TR/fullscreen/
Whether to enable HTML5 client-side SQL database support. Client-side
+SQL database allows web pages to store structured data and be able to
+use SQL to manipulate that data asynchronously.
+
HTML5 database specification is available at
+http://www.w3.org/TR/webdatabase/.
Determines whether or not JavaScript markup is allowed in document. When this setting is disabled,
+all JavaScript-related elements and attributes are removed from the document during parsing. Note that
+executing JavaScript is still allowed if “enable-javascript” is TRUE.
Enable or disable support for MediaCapabilities on pages. This
+specification intends to provide APIs to allow websites to make an optimal
+decision when picking media content for the user. The APIs will expose
+information about the decoding and encoding capabilities for a given format
+but also output capabilities to find the best match based on the device’s
+display.
+
See also https://wicg.github.io/media-capabilities/
Enable or disable support for MediaStream on pages. MediaStream
+is an experimental proposal for allowing web pages to access
+audio and video devices for capture.
+
See also http://dev.w3.org/2011/webrtc/editor/getusermedia.html
Whether to enable HTML5 offline web application cache support. Offline
+web application cache allows web applications to run even when
+the user is not connected to the network.
+
HTML5 offline web application specification is available at
+http://dev.w3.org/html5/spec/offline.html.
Enable or disable the page cache. Disabling the page cache is
+generally only useful for special circumstances like low-memory
+scenarios or special purpose applications like static HTML
+viewers. This setting only controls the Page Cache, this cache
+is different than the disk-based or memory-based traditional
+resource caches, its point is to make going back and forth
+between pages much faster. For details about the different types
+of caches and their purposes see:
+http://webkit.org/blog/427/webkit-page-cache-i-the-basics/
Whether to turn on site-specific quirks. Turning this on will
+tell WebKit to use some site-specific workarounds for
+better web compatibility. For example, older versions of
+MediaWiki will incorrectly send to WebKit a CSS file with KHTML
+workarounds. By turning on site-specific quirks, WebKit will
+special-case this and other cases to make some specific sites work.
Whether to enable Spatial Navigation. This feature consists in the ability
+to navigate between focusable elements in a Web page, such as hyperlinks
+and form controls, by using Left, Right, Up and Down arrow keys.
+For example, if an user presses the Right key, heuristics determine whether
+there is an element they might be trying to reach towards the right, and if
+there are multiple elements, which element they probably wants.
Determines whether the tab key cycles through the elements on the page.
+When this setting is enabled, users will be able to focus the next element
+in the page by pressing the tab key. If the selected element is editable,
+then pressing tab key will insert the tab character.
Enable or disable support for WebAudio on pages. WebAudio is an
+experimental proposal for allowing web pages to generate Audio
+WAVE data from JavaScript. The standard is currently a
+work-in-progress by the W3C Audio Working Group.
+
See also https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html
Enable or disable support for WebGL on pages. WebGL is an experimental
+proposal for allowing web pages to use OpenGL ES-like calls directly. The
+standard is currently a work-in-progress by the Khronos Group.
+
Flags: Read / Write / Construct
+
Default value: FALSE
+
+
+
+
The “enable-write-console-messages-to-stdout” property
Whether media playback is full-screen only or inline playback is allowed.
+This is TRUE by default, so media playback can be inline. Setting it to
+FALSE allows specifying that media playback should be always fullscreen.
+
Flags: Read / Write / Construct
+
Default value: TRUE
+
+
+
+
The “media-playback-requires-user-gesture” property
Whether a user gesture (such as clicking the play button)
+would be required to start media playback or load media. This is off
+by default, so media playback could start automatically.
+Setting it on requires a gesture by the user to start playback, or to
+load the media.
The minimum font size in pixels used to display text. This setting
+controls the absolute smallest size. Values other than 0 can
+potentially break page layouts.
The user-agent string used by WebKit. Unusual user-agent strings may cause web
+content to render incorrectly or fail to run, as many web pages are written to
+parse the user-agent strings of only the most popular browsers. Therefore, it's
+typically better to not completely override the standard user-agent, but to use
+webkit_settings_set_user_agent_with_application_details() instead.
+
If this property is set to the empty string or NULL, it will revert to the standard
+user-agent.
Whether “zoom-level” affects only the
+text of the page or all the contents. Other contents containing text
+like form controls will be also affected by zoom factor when
+this property is enabled.
+
Flags: Read / Write / Construct
+
Default value: FALSE
+
+
+
+
+
+
\ No newline at end of file
diff --git a/aperezdc/learn-discover-rework/reference/wpewebkit/unstable/WebKitURIRequest/index.html b/aperezdc/learn-discover-rework/reference/wpewebkit/unstable/WebKitURIRequest/index.html
new file mode 100644
index 000000000..2507de05c
--- /dev/null
+++ b/aperezdc/learn-discover-rework/reference/wpewebkit/unstable/WebKitURIRequest/index.html
@@ -0,0 +1,289 @@
+
+
+
+
+WebKitURIRequest: WPE Reference Manual
+
+
+
+
+
+
+
+
+
+
A WebKitURIResponse contains information such as the URI, the
+status code, the content length, the mime type, the HTTP status or
+the suggested filename.
Get the status code of the WebKitURIResponse as returned by
+the server. It will normally be a SoupKnownStatusCode, for
+example SOUP_STATUS_OK, though the server can respond with any
+unsigned integer.
Registers a new user script message handler. After it is registered,
+scripts can use window.webkit.messageHandlers.<name>.postMessage(value)
+to send messages. Those messages are received by connecting handlers
+to the “script-message-received” signal. The
+handler name is used as the detail of the signal. To avoid race
+conditions between registering the handler name, and starting to
+receive the signals, it is recommended to connect to the signal
+*before* registering the handler name:
Unregisters a previously registered message handler.
+
Note that this does *not* disconnect handlers for the
+“script-message-received” signal;
+they will be kept connected, but the signal will not be emitted
+unless the handler name is registered again.
Unregisters a previously registered message handler in script world with name world_name
+.
+
Note that this does *not* disconnect handlers for the
+“script-message-received” signal;
+they will be kept connected, but the signal will not be emitted
+unless the handler name is registered again.
WebKitUserMediaPermissionRequest represents a request for
+permission to decide whether WebKit should be allowed to access the user's
+audio and video source devices when requested through the getUserMedia API.
+
When a WebKitUserMediaPermissionRequest is not handled by the user,
+it is denied by default.
Create a new ephemeral WebKitWebContext. An ephemeral WebKitWebContext is a context
+created with an ephemeral WebKitWebsiteDataManager. This is just a convenient method
+to create ephemeral contexts without having to create your own WebKitWebsiteDataManager.
+All WebKitWebViews associated with this context will also be ephemeral. Websites will
+not store any data in the client storage.
+This is normally used to implement private instances.
Set whether automation is allowed in context
+. When automation is enabled the browser could
+be controlled by another process by requesting an automation session. When a new automation
+session is requested the signal “automation-started” is emitted.
+Automation is disabled by default, so you need to explicitly call this method passing TRUE
+to enable it.
+
Note that only one WebKitWebContext can have automation enabled, so this will do nothing
+if there's another WebKitWebContext with automation already enabled.
Specifies a usage model for WebViews, which WebKit will use to
+determine its caching behavior. All web views follow the cache
+model. This cache model determines the RAM and disk space to use
+for caching previously viewed content .
+
Research indicates that users tend to browse within clusters of
+documents that hold resources in common, and to revisit previously
+visited documents. WebKit and the frameworks below it include
+built-in caches that take advantage of these patterns,
+substantially improving document load speed in browsing
+situations. The WebKit cache model controls the behaviors of all of
+these caches, including various WebCore caches.
Sets the maximum number of web processes that can be created at the same time for the context
+.
+The default value is 0 and means no limit.
+
This method **must be called before any web process has been created**,
+as early as possible in your application. Calling it later will make
+your application crash.
Requests downloading of the specified URI string. The download operation
+will not be associated to any WebKitWebView, if you are interested in
+starting a download from a particular WebKitWebView use
+webkit_web_view_download_uri() instead.
Set the directory path to be used to store the favicons database
+for context
+ on disk. Passing NULL as path
+ means using the
+default directory for the platform (see g_get_user_cache_dir()).
+
Calling this method also means enabling the favicons database for
+its use from the applications, so that's why it's expected to be
+called only once. Further calls for the same instance of
+WebKitWebContext won't cause any effect.
Set the list of spell checking languages to be used for spell
+checking.
+
The locale string typically is in the form lang_COUNTRY, where lang
+is an ISO-639 language code, and COUNTRY is an ISO-3166 country code.
+For instance, sv_FI for Swedish as written in Finland or pt_BR
+for Portuguese as written in Brazil.
+
You need to call this function with a valid list of languages at
+least once in order to properly enable the spell checking feature
+in WebKit.
Set the list of preferred languages, sorted from most desirable
+to least desirable. The list will be used to build the "Accept-Language"
+header that will be included in the network requests started by
+the WebKitWebContext.
Set the directory where WebKit will look for Web Extensions.
+This method must be called before loading anything in this context,
+otherwise it will not have any effect. You can connect to
+“initialize-web-extensions” to call this method
+before anything is loaded.
Set user data to be passed to Web Extensions on initialization.
+The data will be passed to the
+WebKitWebExtensionInitializeWithUserDataFunction.
+This method must be called before loading anything in this context,
+otherwise it will not have any effect. You can connect to
+“initialize-web-extensions” to call this method
+before anything is loaded.
Specifies a process model for WebViews, which WebKit will use to
+determine how auxiliary processes are handled. The default setting
+(WEBKIT_PROCESS_MODEL_SHARED_SECONDARY_PROCESS) is suitable for most
+applications which embed a small amount of WebViews, or are used to
+display documents which are considered safe — like local files.
+
Applications which may potentially use a large amount of WebViews
+—for example a multi-tabbed web browser— may want to use
+WEBKIT_PROCESS_MODEL_MULTIPLE_SECONDARY_PROCESSES, which will use
+one process per view most of the time, while still allowing for web
+views to share a process when needed (for example when different
+views interact with each other). Using this model, when a process
+hangs or crashes, only the WebViews using it stop working, while
+the rest of the WebViews in the application will still function
+normally.
+
This method **must be called before any web process has been created**,
+as early as possible in your application. Calling it later will make
+your application crash.
Sets initial desktop notification permissions for the context
+.
+allowed_origins
+ and disallowed_origins
+ must each be GList of
+WebKitSecurityOrigin objects representing origins that will,
+respectively, either always or never have permission to show desktop
+notifications. No WebKitNotificationPermissionRequest will ever be
+generated for any of the security origins represented in
+allowed_origins
+ or disallowed_origins
+. This function is necessary
+because some webpages proactively check whether they have permission
+to display notifications without ever creating a permission request.
+
This function only affects web processes that have not already been
+created. The best time to call it is when handling
+“initialize-notification-permissions” so as to
+ensure that new web processes receive the most recent set of
+permissions.
staticvoid
+about_uri_scheme_request_cb(WebKitURISchemeRequest*request,
+gpointer user_data)
+{
+GInputStream*stream;
+gsize stream_length;
+constgchar*path;
+
+ path =webkit_uri_scheme_request_get_path(request);
+if(!g_strcmp0(path,"plugins")){
+/* Create a GInputStream with the contents of plugins about page, and set its length to stream_length */
+}elseif(!g_strcmp0(path,"memory")){
+/* Create a GInputStream with the contents of memory about page, and set its length to stream_length */
+}elseif(!g_strcmp0(path,"applications")){
+/* Create a GInputStream with the contents of applications about page, and set its length to stream_length */
+}elseif(!g_strcmp0(path,"example")){
+gchar*contents;
+
+ contents =g_strdup_printf("<html><body><p>Example about page</p></body></html>");
+ stream_length =strlen(contents);
+ stream =g_memory_input_stream_new_from_data(contents, stream_length,g_free);
+}else{
+GError*error;
+
+ error =g_error_new(ABOUT_HANDLER_ERROR, ABOUT_HANDLER_ERROR_INVALID,"Invalid about:%s page.", path);
+webkit_uri_scheme_request_finish_error(request, error);
+g_error_free(error);
+return;
+}
+webkit_uri_scheme_request_finish(request, stream, stream_length,"text/html");
+g_object_unref(stream);
+}
Enum values used for determining the WebKitWebContext cache model.
+
+
Members
+
+
+
+
+
+
+
+
+
WEBKIT_CACHE_MODEL_DOCUMENT_VIEWER
+
+
Disable the cache completely, which
+ substantially reduces memory usage. Useful for applications that only
+ access a single local file, with no navigation to other pages. No remote
+ resources will be cached.
+
+
+
+
+
WEBKIT_CACHE_MODEL_WEB_BROWSER
+
+
Improve document load speed substantially
+ by caching a very large number of resources and previously viewed content.
+
+
+
+
+
WEBKIT_CACHE_MODEL_DOCUMENT_BROWSER
+
+
A cache model optimized for viewing
+ a series of local files -- for example, a documentation viewer or a website
+ designer. WebKit will cache a moderate number of resources.
+
+
+
+
+
+
+
+
+
+
enum WebKitProcessModel
+
Enum values used for determining the WebKitWebContext process model.
+
+
Members
+
+
+
+
+
+
+
+
+
WEBKIT_PROCESS_MODEL_SHARED_SECONDARY_PROCESS
+
+
Use a single process to
+ perform content rendering. The process is shared among all the
+ WebKitWebView instances created by the application: if the process
+ hangs or crashes all the web views in the application will be affected.
+ This is the default process model, and it should suffice for most cases.
+
+
+
+
+
WEBKIT_PROCESS_MODEL_MULTIPLE_SECONDARY_PROCESSES
+
+
Use one process
+ for each WebKitWebView, while still allowing for some of them to
+ share a process in certain situations. The main advantage
+ of this process model is that the rendering process for a web view
+ can crash while the rest of the views keep working normally. This
+ process model is indicated for applications which may use a number
+ of web views and the content of in each must not interfere with the
+ rest — for example a full-fledged web browser with support for
+ multiple tabs.
+
+
+
+
+
+
+
Since: 2.4
+
+
+
+
enum WebKitTLSErrorsPolicy
+
Enum values used to denote the TLS errors policy.
+
+
Members
+
+
+
+
+
+
+
+
+
WEBKIT_TLS_ERRORS_POLICY_IGNORE
+
+
Ignore TLS errors.
+
+
+
+
+
WEBKIT_TLS_ERRORS_POLICY_FAIL
+
+
TLS errors will emit
+ “load-failed-with-tls-errors” and, if the signal is handled,
+ finish the load. In case the signal is not handled,
+ “load-failed” is emitted before the load finishes.
This signal is emitted when a new automation request is made.
+Note that it will never be emitted if automation is not enabled in context
+,
+see webkit_web_context_set_automation_allowed() for more details.
A WebKitWebResource encapsulates content for each resource at the
+end of a particular URI. For example, one WebKitWebResource will
+be created for each separate image and stylesheet when a page is
+loaded.
Returns the current active URI of resource
+. The active URI might change during
+a load operation:
+
+
+ When the resource load starts, the active URI is the requested URI
+
+
+ When the initial request is sent to the server, “sent-request”
+ signal is emitted without a redirected response, the active URI is the URI of
+ the request sent to the server.
+
+
+ In case of a server redirection, “sent-request” signal
+ is emitted again with a redirected response, the active URI is the URI the request
+ was redirected to.
+
+
+ When the response is received from the server, the active URI is the final
+ one and it will not change again.
+
+
+
You can monitor the active URI by connecting to the notify::uri
+signal of resource
+.
Retrieves the WebKitURIResponse of the resource load operation.
+This method returns NULL if called before the response
+is received from the server. You can connect to notify::response
+signal to be notified when the response is received.
When the operation is finished, callback
+ will be called. You can then call
+webkit_web_resource_get_data_finish() to get the result of the operation.
This signal is emitted when the resource load finishes successfully
+or due to an error. In case of errors “failed” signal
+is emitted before this one.
This signal is emitted after response is received,
+every time new data has been received. It's
+useful to know the progress of the resource load operation.
This signal is emitted when request
+ has been sent to the
+server. In case of a server redirection this signal is
+emitted again with the request
+ argument containing the new
+request sent to the server due to the redirection and the
+redirected_response
+ parameter containing the response
+received by the server for the initial request.
WebKitWebView is the central class of the WPE WebKit and WebKitGTK
+APIs. It is responsible for managing the drawing of the content and
+forwarding of events. You can load any URI into the WebKitWebView or
+a data string. With WebKitSettings you can control various aspects
+of the rendering and loading of the content.
Tries to close the web_view
+. This will fire the onbeforeunload event
+to ask the user for confirmation to close the page. If there isn't an
+onbeforeunload event handler or the user confirms to close the page,
+the “close” signal is emitted, otherwise nothing happens.
Load the given content
+ string with the specified base_uri
+.
+If base_uri
+ is not NULL, relative URLs in the content
+ will be
+resolved against base_uri
+ and absolute local paths must be children of the base_uri
+.
+For security reasons absolute local paths that are not children of base_uri
+
+will cause the web process to terminate.
+If you need to include URLs in content
+ that are local paths in a different
+directory than base_uri
+ you can build a data URI for them. When base_uri
+ is NULL,
+it defaults to "about:blank". The mime type of the document will be "text/html".
+You can monitor the load operation by connecting to “load-changed” signal.
Load the given content
+ string for the URI content_uri
+.
+This allows clients to display page-loading errors in the WebKitWebView itself.
+When this method is called from “load-failed” signal to show an
+error page, then the back-forward list is maintained appropriately.
+For everything else this method works the same way as webkit_web_view_load_html().
Load the specified plain_text
+ string into web_view
+. The mime type of
+document will be "text/plain". You can monitor the load
+operation by connecting to “load-changed” signal.
Load the specified bytes
+ into web_view
+ using the given mime_type
+ and encoding
+.
+When mime_type
+ is NULL, it defaults to "text/html".
+When encoding
+ is NULL, it defaults to "UTF-8".
+When base_uri
+ is NULL, it defaults to "about:blank".
+You can monitor the load operation by connecting to “load-changed” signal.
Stops any ongoing loading operation in web_view
+.
+This method does nothing if no content is being loaded.
+If there is a loading operation in progress, it will be cancelled and
+“load-failed” signal will be emitted with
+WEBKIT_NETWORK_ERROR_CANCELLED error.
Gets the value of the “is-loading” property.
+You can monitor when a WebKitWebView is loading a page by connecting to
+notify::is-loading signal of web_view
+. This is useful when you are
+interesting in knowing when the view is loading something but not in the
+details about the status of the load operation, for example to start a spinner
+when the view is loading a page and stop it when it finishes.
Gets the value of the “is-playing-audio” property.
+You can monitor when a page in a WebKitWebView is playing audio by
+connecting to the notify::is-playing-audio signal of web_view
+. This
+is useful when the application wants to provide visual feedback when a
+page is producing sound.
Gets the value of the “estimated-load-progress” property.
+You can monitor the estimated progress of a load operation by
+connecting to the notify::estimated-load-progress signal of web_view
+.
Sets the current custom character encoding override of web_view
+. The custom
+character encoding will override any text encoding detected via HTTP headers or
+META tags. Calling this method will stop any current load operation and reload the
+current page. Setting the custom character encoding to NULL removes the character
+encoding override.
+ If there is a server redirection during the load operation,
+ the active URI is the redirected URI. When the signal
+ “load-changed” is emitted with WEBKIT_LOAD_REDIRECTED
+ event, the active URI is already updated to the redirected URI.
+
+
+ When the signal “load-changed” is emitted
+ with WEBKIT_LOAD_COMMITTED event, the active URI is the final
+ one and it will not change unless a new load operation is started
+ or a navigation action within the same page is performed.
+
+
+
You can monitor the active URI by connecting to the notify::uri
+signal of web_view
+.
Sets the WebKitSettings to be applied to web_view
+. The
+existing WebKitSettings of web_view
+ will be replaced by
+settings
+. New settings are applied immediately on web_view
+.
+The same WebKitSettings object can be shared
+by multiple WebKitWebViews.
Request to execute the given command
+ with argument
+ for web_view
+. You can use
+webkit_web_view_can_execute_editing_command() to check whether
+it's possible to execute the command.
Asynchronously run script
+ in the context of the current page in web_view
+. If
+WebKitSettings:enable-javascript is FALSE, this method will do nothing.
Asynchronously run script
+ in the script world with name world_name
+ of the current page context in web_view
+.
+If WebKitSettings:enable-javascript is FALSE, this method will do nothing.
Asynchronously save the current web page associated to the
+WebKitWebView into a self-contained format using the mode
+specified in save_mode
+ and writing it to file
+.
+
When the operation is finished, callback
+ will be called. You can
+then call webkit_web_view_save_to_file_finish() to get the result of the
+operation.
Retrieves the GTlsCertificate associated with the main resource of web_view
+,
+and the GTlsCertificateFlags showing what problems, if any, have been found
+with that certificate.
+If the connection is not HTTPS, this function returns FALSE.
+This function should be called after a response has been received from the
+server, so you can connect to “load-changed” and call this function
+when it's emitted with WEBKIT_LOAD_COMMITTED event.
+
Note that this function provides no information about the security of the web
+page if the current WebKitTLSErrorsPolicy is WEBKIT_TLS_ERRORS_POLICY_IGNORE
+,
+as subresources of the page may be controlled by an attacker. This function
+may safely be used to determine the security status of the current page only
+if the current WebKitTLSErrorsPolicy is WEBKIT_TLS_ERRORS_POLICY_FAIL
+, in
+which case subresources that fail certificate verification will be blocked.
Sets whether the user is allowed to edit the HTML document.
+
If editable
+ is TRUE, web_view
+ allows the user to edit the HTML document. If
+editable
+ is FALSE, an element in web_view
+'s document can only be edited if the
+CONTENTEDITABLE attribute has been set on the element or one of its parent
+elements. By default a WebKitWebView is not editable.
+
Normally, a HTML document is not editable unless the elements within the
+document are editable. This function provides a way to make the contents
+of a WebKitWebView editable without altering the document or DOM structure.
Atomically decrements the reference count of js_result
+ by one. If the
+reference count drops to 0, all memory allocated by the WebKitJavascriptResult is
+released. This function is MT-safe and may be called from any
+thread.
Atomically decrements the reference count of dialog
+ by one. If the
+reference count drops to 0, all memory allocated by the WebKitScriptdialog is
+released. This function is MT-safe and may be called from any
+thread.
Close dialog
+. When handling a WebKitScriptDialog asynchronously (webkit_script_dialog_ref()
+was called in “script-dialog” callback), this function needs to be called to notify
+that we are done with the script dialog. The dialog will be closed on destruction if this function
+hasn't been called before.
Atomically decrements the reference count of state
+ by one. If the
+reference count drops to 0, all memory allocated by the WebKitWebViewSessionState is
+released. This function is MT-safe and may be called from any thread.
Enum values used to denote the different events that happen during a
+WebKitWebView load operation.
+
+
Members
+
+
+
+
+
+
+
+
+
WEBKIT_LOAD_STARTED
+
+
A new load request has been made.
+No data has been received yet, empty structures have
+been allocated to perform the load; the load may still
+fail due to transport issues such as not being able to
+resolve a name, or connect to a port.
+
+
+
+
+
WEBKIT_LOAD_REDIRECTED
+
+
A provisional data source received
+a server redirect.
+
+
+
+
+
WEBKIT_LOAD_COMMITTED
+
+
The content started arriving for a page load.
+The necessary transport requirements are established, and the
+load is being performed.
+
+
+
+
+
WEBKIT_LOAD_FINISHED
+
+
Load completed. All resources are done loading
+or there was an error during the load operation.
+
+
+
+
+
+
+
+
+
+
enum WebKitPolicyDecisionType
+
Enum values used for determining the type of a policy decision during
+“decide-policy”.
This type of policy decision
+ is requested when WebKit is about to create a new window. Acceptable policy
+ decisions are either webkit_policy_decision_use() or
+ webkit_policy_decision_ignore(). This type of policy decision is always
+ a WebKitNavigationPolicyDecision. These decisions are useful for implementing
+ special actions for new windows, such as forcing the new window to open
+ in a tab when a keyboard modifier is active or handling a special
+ target attribute on <a> elements.
+
+
+
+
+
WEBKIT_POLICY_DECISION_TYPE_RESPONSE
+
+
This type of decision is used when WebKit has
+ received a response for a network resource and is about to start the load.
+ Note that these resources include all subresources of a page such as images
+ and stylesheets as well as main documents. Appropriate policy responses to
+ this decision are webkit_policy_decision_use(), webkit_policy_decision_ignore(),
+ or webkit_policy_decision_download(). This type of policy decision is always
+ a WebKitResponsePolicyDecision. This decision is useful for forcing
+ some types of resources to be downloaded rather than rendered in the WebView
+ or to block the transfer of resources entirely.
+
+
+
+
+
+
+
+
+
+
enum WebKitSaveMode
+
Enum values to specify the different ways in which a WebKitWebView
+can save its current web page into a self-contained file.
+
+
Members
+
+
+
+
+
+
+
+
WEBKIT_SAVE_MODE_MHTML
+
+
Save the current page using the MHTML format.
+
+
+
+
+
+
+
+
+
enum WebKitInsecureContentEvent
+
Enum values used to denote the different events which can trigger
+the detection of insecure content.
+
+
Members
+
+
+
+
+
+
+
+
+
WEBKIT_INSECURE_CONTENT_RUN
+
+
Insecure content has been detected by
+trying to execute any kind of logic (e.g. a script) from an
+untrusted source.
+
+
+
+
+
WEBKIT_INSECURE_CONTENT_DISPLAYED
+
+
Insecure content has been
+detected by trying to display any kind of resource (e.g. an image)
+from an untrusted source.
+
+
+
+
+
+
+
+
+
+
enum WebKitWebProcessTerminationReason
+
Enum values used to specify the reason why the web process terminated abnormally.
The cut clipboard command. Copies the current selection inside
+a WebKitWebView to the clipboard and deletes the selected content.
+You can check whether it's possible to execute the command with
+webkit_web_view_can_execute_editing_command(). In general it's
+possible to cut to the clipboard when the WebKitWebView content is
+editable and there is an active selection.
+
+
+
+
WEBKIT_EDITING_COMMAND_COPY
+
#define WEBKIT_EDITING_COMMAND_COPY "Copy"
+
+
The copy clipboard command. Copies the current selection inside
+a WebKitWebView to the clipboard.
+You can check whether it's possible to execute the command with
+webkit_web_view_can_execute_editing_command(). In general it's
+possible to copy to the clipboard when there is an active selection
+inside the WebKitWebView.
+
+
+
+
WEBKIT_EDITING_COMMAND_PASTE
+
#define WEBKIT_EDITING_COMMAND_PASTE "Paste"
+
+
The paste clipboard command. Pastes the contents of the clipboard to
+a WebKitWebView.
+You can check whether it's possible to execute the command with
+webkit_web_view_can_execute_editing_command(). In general it's possible
+to paste from the clipboard when the WebKitWebView content is editable
+and clipboard is not empty.
The undo command. Undoes the last editing command in a WebKitWebView.
+You can check whether it's possible to execute the command with
+webkit_web_view_can_execute_editing_command(). It's only possible
+to undo a command after a previously executed editing operation.
+
+
+
+
WEBKIT_EDITING_COMMAND_REDO
+
#define WEBKIT_EDITING_COMMAND_REDO "Redo"
+
+
The redo command. Redoes a previously undone editing command in
+a WebKitWebView.
+You can check whether it's possible to execute the command with
+webkit_web_view_can_execute_editing_command(). It's only possible
+to redo a command when it has been previously undone.
The insert image command. Creates an image element that is inserted at
+the current cursor position. It receives an URI as argument,
+that is used as the image source. This command should be executed with
+webkit_web_view_execute_editing_command_with_argument().
The create link command. Creates a link element that is inserted at
+the current cursor position. If there's a selection, the selected text
+will be used as the link text, otherwise the URL itself will be used.
+It receives the link URL as argument. This command should be executed
+with webkit_web_view_execute_editing_command_with_argument()
An estimate of the percent completion for the current loading operation.
+This value will range from 0.0 to 1.0 and, once a load completes,
+will remain at 1.0 until a new load starts, at which point it
+will be reset to 0.0.
+The value is an estimate based on the total number of bytes expected
+to be received for a document, including all its possible subresources
+and child documents.
Whether the WebKitWebView is currently loading a page. This property becomes
+TRUE as soon as a new load operation is requested and before the
+“load-changed” signal is emitted with WEBKIT_LOAD_STARTED and
+at that point the active URI is the requested one.
+When the load operation finishes the property is set to FALSE before
+“load-changed” is emitted with WEBKIT_LOAD_FINISHED.
Whether the WebKitWebView is currently playing audio from a page.
+This property becomes TRUE as soon as web content starts playing any
+kind of audio. When a page is no longer playing any kind of sound,
+the property is set back to FALSE.
The related WebKitWebView used when creating the view to share the
+same web process. This property is not readable because the related
+web view is only valid during the object construction.
This signal is emitted when the user is challenged with HTTP
+authentication. To let the application access or supply
+the credentials as well as to allow the client application
+to either cancel the request or perform the authentication,
+the signal will pass an instance of the
+WebKitAuthenticationRequest in the request
+ argument.
+To handle this signal asynchronously you should keep a ref
+of the request and return TRUE. To disable HTTP authentication
+entirely, connect to this signal and simply return TRUE.
+
The default signal handler will run a default authentication
+dialog asynchronously for the user to interact with.
Emitted when closing a WebKitWebView is requested. This occurs when a
+call is made from JavaScript's window.close function or
+after trying to close the web_view
+ with webkit_web_view_try_close().
+It is the owner's responsibility to handle this signal to hide or
+destroy the WebKitWebView, if necessary.
Emitted when a context menu is about to be displayed to give the application
+a chance to customize the proposed menu, prevent the menu from being displayed,
+or build its own context menu.
+ To prevent the menu from being displayed you can just connect to this signal
+ and return TRUE so that the proposed menu will not be shown.
+
+
+ To build your own menu, you can remove all items from the proposed menu with
+ webkit_context_menu_remove_all(), add your own items and return FALSE so
+ that the menu will be shown. You can also ignore the proposed WebKitContextMenu,
+ build your own GtkMenu and return TRUE to prevent the proposed menu from being shown.
+
+
+ If you just want the default menu to be shown always, simply don't connect to this
+ signal because showing the proposed context menu is the default behaviour.
+
+
+
The event
+ is expected to be one of the following types:
If the signal handler returns FALSE the context menu represented by context_menu
+
+will be shown, if it return TRUE the context menu will not be shown.
+
The proposed WebKitContextMenu passed in context_menu
+ argument is only valid
+during the signal emission.
Emitted when the creation of a new WebKitWebView is requested.
+If this signal is handled the signal handler should return the
+newly created WebKitWebView.
+
The WebKitNavigationAction parameter contains information about the
+navigation action that triggered this signal.
This signal is emitted when WebKit is requesting the client to decide a policy
+decision, such as whether to navigate to a page, open a new window or whether or
+not to download a resource. The WebKitNavigationPolicyDecision passed in the
+decision
+ argument is a generic type, but should be casted to a more
+specific type when making the decision. For example:
staticgboolean
+decide_policy_cb(WebKitWebView*web_view,
+WebKitPolicyDecision*decision,
+WebKitPolicyDecisionType type)
+{
+switch(type){
+caseWEBKIT_POLICY_DECISION_TYPE_NAVIGATION_ACTION:{
+WebKitNavigationPolicyDecision*navigation_decision =WEBKIT_NAVIGATION_POLICY_DECISION(decision);
+/* Make a policy decision here. */
+break;
+}
+caseWEBKIT_POLICY_DECISION_TYPE_NEW_WINDOW_ACTION:{
+WebKitNavigationPolicyDecision*navigation_decision =WEBKIT_NAVIGATION_POLICY_DECISION(decision);
+/* Make a policy decision here. */
+break;
+}
+caseWEBKIT_POLICY_DECISION_TYPE_RESPONSE:
+WebKitResponsePolicyDecision*response =WEBKIT_RESPONSE_POLICY_DECISION(decision);
+/* Make a policy decision here. */
+break;
+ default:
+/* Making no decision results in webkit_policy_decision_use(). */
+returnFALSE;
+}
+returnTRUE;
+}
+
+
+
+
+
+
It is possible to make policy decision asynchronously, by simply calling g_object_ref()
+on the decision
+ argument and returning TRUE to block the default signal handler.
+If the last reference is removed on a WebKitPolicyDecision and no decision has been
+made explicitly, webkit_policy_decision_use() will be the default policy decision. The
+default signal handler will simply call webkit_policy_decision_use(). Only the first
+policy decision chosen for a given WebKitPolicyDecision will have any affect.
Emitted when JavaScript code calls
+element.webkitRequestFullScreen. If the
+signal is not handled the WebKitWebView will proceed to full screen
+its top level window. This signal can be used by client code to
+request permission to the user prior doing the full screen
+transition and eventually prepare the top-level window
+(e.g. hide some widgets that would otherwise be part of the
+full screen window).
This signal is emitted when insecure content has been detected
+in a page loaded through a secure connection. This typically
+means that a external resource from an unstrusted source has
+been run or displayed, resulting in a mix of HTTPS and
+non-HTTPS content.
+
You can check the event
+ parameter to know exactly which kind
+of event has been detected (see WebKitInsecureContentEvent).
Emitted when the WebKitWebView is about to restore its top level
+window out of its full screen state. This signal can be used by
+client code to restore widgets hidden during the
+“enter-fullscreen” stage for instance.
staticvoidweb_view_load_changed(WebKitWebView*web_view,
+WebKitLoadEvent load_event,
+gpointer user_data)
+{
+switch(load_event){
+caseWEBKIT_LOAD_STARTED:
+/* New load, we have now a provisional URI */
+ provisional_uri =webkit_web_view_get_uri(web_view);
+/* Here we could start a spinner or update the
+ * location bar with the provisional URI */
+break;
+caseWEBKIT_LOAD_REDIRECTED:
+ redirected_uri =webkit_web_view_get_uri(web_view);
+break;
+caseWEBKIT_LOAD_COMMITTED:
+/* The load is being performed. Current URI is
+ * the final one and it won't change unless a new
+ * load is requested or a navigation within the
+ * same page is performed */
+ uri =webkit_web_view_get_uri(web_view);
+break;
+caseWEBKIT_LOAD_FINISHED:
+/* Load finished, we can now stop the spinner */
+break;
+}
+}
Emitted when an error occurs during a load operation.
+If the error happened when starting to load data for a page
+load_event
+ will be WEBKIT_LOAD_STARTED. If it happened while
+loading a committed data source load_event
+ will be WEBKIT_LOAD_COMMITTED.
+Since a load error causes the load operation to finish, the signal
+WebKitWebView::load-changed will always be emitted with
+WEBKIT_LOAD_FINISHED event right after this one.
+
By default, if the signal is not handled, a stock error page will be displayed.
+You need to handle the signal if you want to provide your own error page.
This signal is emitted when the mouse cursor moves over an
+element such as a link, image or a media element. To determine
+what type of element the mouse cursor is over, a Hit Test is performed
+on the current mouse coordinates and the result is passed in the
+hit_test_result
+ argument. The modifiers
+ argument is a bitmask of
+GdkModifierType flags indicating the state of modifier keys.
+The signal is emitted again when the mouse is moved out of the
+current element with a new hit_test_result
+.
This signal is emitted when WebKit is requesting the client to
+decide about a permission request, such as allowing the browser
+to switch to fullscreen mode, sharing its location or similar
+operations.
+
A possible way to use this signal could be through a dialog
+allowing the user decide what to do with the request:
It is possible to handle permission requests asynchronously, by
+simply calling g_object_ref() on the request
+ argument and
+returning TRUE to block the default signal handler. If the
+last reference is removed on a WebKitPermissionRequest and the
+request has not been handled, webkit_permission_request_deny()
+will be the default action.
+
If the signal is not handled, the request
+ will be completed automatically
+by the specific WebKitPermissionRequest that could allow or deny it. Check the
+documentation of classes implementing WebKitPermissionRequest interface to know
+their default action.
Emitted after “create” on the newly created WebKitWebView
+when it should be displayed to the user. When this signal is emitted
+all the information about how the window should look, including
+size, position, whether the location, status and scrollbars
+should be displayed, is already set on the WebKitWindowProperties
+of web_view
+. See also webkit_web_view_get_window_properties().
Emitted when a new resource is going to be loaded. The request
+ parameter
+contains the WebKitURIRequest that will be sent to the server.
+You can monitor the load operation by connecting to the different signals
+of resource
+.
Emitted after “ready-to-show” on the newly
+created WebKitWebView when JavaScript code calls
+window.showModalDialog. The purpose of
+this signal is to allow the client application to prepare the
+new view to behave as modal. Once the signal is emitted a new
+main loop will be run to block user interaction in the parent
+WebKitWebView until the new dialog is closed.
This signal is emitted when the user interacts with a <input
+type='file' /> HTML element, requesting from WebKit to show
+a dialog to select one or more files to be uploaded. To let the
+application know the details of the file chooser, as well as to
+allow the client application to either cancel the request or
+perform an actual selection of files, the signal will pass an
+instance of the WebKitFileChooserRequest in the request
+
+argument.
+
The default signal handler will asynchronously run a regular
+GtkFileChooserDialog for the user to interact with.
Emitted when JavaScript code calls window.alert,
+window.confirm or window.prompt,
+or when onbeforeunload event is fired.
+The dialog
+ parameter should be used to build the dialog.
+If the signal is not handled a different dialog will be built and shown depending
+on the dialog type:
This signal is emitted when a notification should be presented to the
+user. The notification
+ is kept alive until either: 1) the web page cancels it
+or 2) a navigation happens.
+
The default handler will emit a notification using libnotify, if built with
+support for it.
This signal is emitted when a form is about to be submitted. The request
+
+argument passed contains information about the text fields of the form. This
+is typically used to store login information that can be used later to
+pre-fill the form.
+The form will not be submitted until webkit_form_submission_request_submit() is called.
A WebKitWebViewBackend is a boxed type wrapping a WPE backend used to create a
+WebKitWebView. A WebKitWebViewBackend is created with webkit_web_view_backend_new()
+and it should be passed to a WebKitWebView constructor that will take the ownership.
Create a new WebKitWebViewBackend for the given WPE backend
+. You can pass a GDestroyNotify
+that will be called when the object is destroyed passing user_data
+ as the argument. If notify
+
+is NULL, wpe_view_backend_destroy() will be used with backend
+ as argument.
+The returned WebKitWebViewBackend should never be freed by the user; it must be passed to a
+WebKitWebView constructor that will take the ownership.
WebKitWebsiteData represents data stored in the client by a particular website.
+A website is normally a set of URLs grouped by domain name. You can get the website name,
+which is usually the domain, with webkit_website_data_get_name().
+Documents loaded from the file system, like file:// URIs, are all grouped in the same WebKitWebsiteData
+with the name "Local files".
Atomically decrements the reference count of website_data
+ by one.
+If the reference count drops to 0, all memory allocated by
+WebKitWebsiteData is released. This function is MT-safe and may be
+called from any thread.
Gets the name of WebKitWebsiteData. This is the website name, normally represented by
+a domain or host name. All local documents are grouped in the same WebKitWebsiteData using
+the name "Local files".
Gets the size of the data of types types
+ in a WebKitWebsiteData.
+Note that currently the data size is only known for WEBKIT_WEBSITE_DATA_DISK_CACHE data type
+so for all other types 0 will be returned.
WebKitWebsiteDataManager allows you to manage the data that websites
+can store in the client file system like databases or caches.
+You can use WebKitWebsiteDataManager to configure the local directories
+where the Website data will be stored, by creating a new manager with
+webkit_website_data_manager_new() passing the values you want to set.
+You can set all the possible configuration values or only some of them,
+a default value will be used automatically for the configuration options
+not provided. “base-data-directory” and
+“base-cache-directory” are two special properties
+that can be used to set a common base directory for all Website data and
+caches. It's possible to provide both, a base directory and a specific value,
+but in that case, the specific value takes precedence over the base directory.
+The newly created WebKitWebsiteDataManager must be passed as a construct property
+to a WebKitWebContext, you can use webkit_web_context_new_with_website_data_manager()
+to create a new WebKitWebContext with a WebKitWebsiteDataManager.
+In case you don't want to set any specific configuration, you don't need to create
+a WebKitWebsiteDataManager, the WebKitWebContext will create a WebKitWebsiteDataManager
+with the default configuration. To get the WebKitWebsiteDataManager of a WebKitWebContext
+you can use webkit_web_context_get_website_data_manager().
+
A WebKitWebsiteDataManager can also be ephemeral and then all the directories configuration
+is not needed because website data will never persist. You can create an ephemeral WebKitWebsiteDataManager
+with webkit_website_data_manager_new_ephemeral(). Then you can pass an ephemeral WebKitWebsiteDataManager to
+a WebKitWebContext to make it ephemeral or use webkit_web_context_new_ephemeral() and the WebKitWebsiteDataManager
+will be automatically created by the WebKitWebContext.
+
WebKitWebsiteDataManager can also be used to fetch websites data, remove data
+stored by particular websites, or clear data for all websites modified since a given
+period of time.
Asynchronously removes the website data of the for the given types
+ for websites in the given website_data
+ list.
+Use webkit_website_data_manager_clear() if you want to remove the website data for all sites.
Due to implementation limitations, this function does not currently delete
+any stored cookies if timespan
+ is nonzero. This behavior may change in the
+future.
Whether the WebKitWebsiteDataManager is ephemeral. An ephemeral WebKitWebsiteDataManager
+handles all websites data as non-persistent, and nothing will be written to the client
+storage. Note that if you create an ephemeral WebKitWebsiteDataManager all other construction
+parameters to configure data directories will be ignored.
The content of a WebKitWebView can request to change certain
+properties of the window containing the view. This can include the x, y position
+of the window, the width and height but also if a toolbar,
+scrollbar, statusbar, locationbar should be visible to the user,
+and the request to show the WebKitWebView fullscreen.
+
The “ready-to-show” signal handler is the proper place
+to apply the initial window properties. Then you can monitor the
+WebKitWindowProperties by connecting to ::notify signal.
Use this function to format a URI for display. The URIs used internally by
+WebKit may contain percent-encoded characters or Punycode, which are not
+generally suitable to display to users. This function provides protection
+against IDN homograph attacks, so in some cases the host part of the returned
+URI may be in Punycode if the safety check fails.
+
+
Parameters
+
+
+
+
+
+
+
+
uri
+
the URI to be converted
+
+
+
+
+
+
Returns
+
uri
+suitable for display, or NULL in
+case of error.
+
[nullable][transfer full]
+
+
Since: 2.24
+
+
+
+
Types and Values
+
+
+
+
+
\ No newline at end of file
diff --git a/aperezdc/learn-discover-rework/reference/wpewebkit/unstable/wpe-0.1-WebKitUserContent/index.html b/aperezdc/learn-discover-rework/reference/wpewebkit/unstable/wpe-0.1-WebKitUserContent/index.html
new file mode 100644
index 000000000..52d259d99
--- /dev/null
+++ b/aperezdc/learn-discover-rework/reference/wpewebkit/unstable/wpe-0.1-WebKitUserContent/index.html
@@ -0,0 +1,747 @@
+
+
+
+
+User content: WPE Reference Manual
+
+
+
+
+
+
+
+
+
+
Atomically decrements the reference count of user_style_sheet
+ by one.
+If the reference count drops to 0, all memory allocated by
+WebKitUserStyleSheet is released. This function is MT-safe and may be
+called from any thread.
Creates a new user style sheet. Style sheets can be applied to some URIs
+only by passing non-null values for whitelist
+ or blacklist
+. Passing a
+NULL whitelist implies that all URIs are on the whitelist. The style
+sheet is applied if an URI matches the whitelist and not the blacklist.
+URI patterns must be of the form [protocol]://[host]/[path], where the
+*host* and *path* components can contain the wildcard character (*) to
+represent zero or more other characters.
Atomically decrements the reference count of user_script
+ by one.
+If the reference count drops to 0, all memory allocated by
+WebKitUserScript is released. This function is MT-safe and may be called
+from any thread.
Creates a new user script. Scripts can be applied to some URIs
+only by passing non-null values for whitelist
+ or blacklist
+. Passing a
+NULL whitelist implies that all URIs are on the whitelist. The script
+is applied if an URI matches the whitelist and not the blacklist.
+URI patterns must be of the form [protocol]://[host]/[path], where the
+*host* and *path* components can contain the wildcard character (*) to
+represent zero or more other characters.
Atomically decrements the reference count of user_content_filter
+ by one.
+If the reference count drops to 0, all the memory allocated by the
+WebKitUserContentFilter is released. This function is MT-safe and may
+be called from any thread.
Set whether the element is an HTML input element that has been filled automatically.
+If element
+ is not an HTML input element this function does nothing.
Get the default WebKitScriptWorld. This is the normal script world
+where all scripts are executed by default.
+You can get the JavaScript execution context of a WebKitScriptWorld
+for a given WebKitFrame with webkit_frame_get_javascript_context_for_script_world().
Creates a new isolated WebKitScriptWorld. Scripts executed in
+isolated worlds have access to the DOM but not to other variable
+or functions created by the page.
+The WebKitScriptWorld is created with a generated unique name. Use
+webkit_script_world_new_with_name() if you want to create it with a
+custom name.
+You can get the JavaScript execution context of a WebKitScriptWorld
+for a given WebKitFrame with webkit_frame_get_javascript_context_for_script_world().
Creates a new isolated WebKitScriptWorld with a name. Scripts executed in
+isolated worlds have access to the DOM but not to other variable
+or functions created by the page.
+You can get the JavaScript execution context of a WebKitScriptWorld
+for a given WebKitFrame with webkit_frame_get_javascript_context_for_script_world().
Emitted when the JavaScript window object in a WebKitScriptWorld has been
+cleared. This is the preferred place to set custom properties on the window
+object using the JavaScriptCore API. You can get the window object of frame
+
+from the JavaScript execution context of world
+ that is returned by
+webkit_frame_get_javascript_context_for_script_world().
The WebKitWebEditor provides access to various editing capabilities of
+a WebKitWebPage such as a possibility to react to the current selection in
+WebKitWebPage.
This signal is emitted for every selection change inside a WebKitWebPage
+as well as for every caret position change as the caret is a collapsed
+selection.
WebKitWebExtension is a loadable module for the WebProcess. It allows you to execute code in the
+WebProcess and being able to use the DOM API, to change any request or to inject custom
+JavaScript code, for example.
+
To create a WebKitWebExtension you should write a module with an initialization function that could
+be either webkit_web_extension_initialize() with prototype WebKitWebExtensionInitializeFunction or
+webkit_web_extension_initialize_with_user_data() with prototype WebKitWebExtensionInitializeWithUserDataFunction.
+This function has to be public and it has to use the G_MODULE_EXPORT macro. It is called when the
+web process is initialized.
The previous piece of code shows a trivial example of an extension that notifies when
+a WebKitWebPage is created.
+
WebKit has to know where it can find the created WebKitWebExtension. To do so you
+should use the webkit_web_context_set_web_extensions_directory() function. The signal
+“initialize-web-extensions” is the recommended place to call it.
+
To provide the initialization data used by the webkit_web_extension_initialize_with_user_data()
+function, you have to call webkit_web_context_set_web_extensions_initialization_user_data() with
+the desired data as parameter. You can see an example of this in the following piece of code:
Type definition for a function that will be called to initialize
+the web extensions when the web process starts, and which receives
+as additional argument the user data set with
+webkit_web_context_set_web_extensions_initialization_user_data().
Emitted when a message is sent to the console. This can be a message
+produced by the use of JavaScript console API, a JavaScript exception,
+a security error or other errors, warnings, debug or log messages.
+The console_message
+ contains information of the message.
Emitted before a context menu is displayed in the UI Process to
+give the application a chance to customize the proposed menu,
+build its own context menu or pass user data to the UI Process.
+This signal is useful when the information available in the UI Process
+is not enough to build or customize the context menu, for example, to
+add menu entries depending on the WebKitDOMNode at the coordinates of the
+hit_test_result
+. Otherwise, it's recommended to use “context-menu”
+signal instead.
Emitted after form elements (or form associated elements) are associated to a particular web
+page. This is useful to implement form auto filling for web pages where form fields are added
+dynamically. This signal might be emitted multiple times for the same web page.
+
Note that this signal could be also emitted when form controls are moved between forms. In
+that case, the elements
+ array carries the list of those elements which have moved.
+
Clients should take a reference to the members of the elements
+ array if it is desired to
+keep them alive after the signal handler returns.
This signal is emitted when request
+ is about to be sent to
+the server. This signal can be used to modify the WebKitURIRequest
+that will be sent to the server. You can also cancel the resource load
+operation by connecting to this signal and returning TRUE.
+
In case of a server redirection this signal is
+emitted again with the request
+ argument containing the new
+request to be sent to the server due to the redirection and the
+redirected_response
+ parameter containing the response
+received by the server for the initial request.
+
Modifications to the WebKitURIRequest and its associated
+SoupMessageHeaders will be taken into account when the request
+is sent over the network.
This signal is emitted to indicate various points during form
+submission. step
+ indicates the current stage of form submission.
+
If this signal is emitted with WEBKIT_FORM_SUBMISSION_WILL_SEND_DOM_EVENT,
+then the DOM submit event is about to be emitted. JavaScript code
+may rely on the submit event to detect that the user has clicked
+on a submit button, and to possibly cancel the form submission
+before WEBKIT_FORM_SUBMISSION_WILL_COMPLETE. However, beware
+that, for historical reasons, the submit event is not emitted at
+all if the form submission is triggered by JavaScript. For these
+reasons, WEBKIT_FORM_SUBMISSION_WILL_SEND_DOM_EVENT may not
+be used to reliably detect whether a form will be submitted.
+Instead, use it to detect if a user has clicked on a form's
+submit button even if JavaScript later cancels the form
+submission, or to read the values of the form's fields even if
+JavaScript later clears certain fields before submitting. This
+may be needed, for example, to implement a robust browser
+password manager, as some misguided websites may use such
+techniques to attempt to thwart password managers.
+
If this signal is emitted with WEBKIT_FORM_SUBMISSION_WILL_COMPLETE,
+the form will imminently be submitted. It can no longer be
+cancelled. This event always occurs immediately before a form is
+submitted to its target, so use this event to reliably detect
+when a form is submitted. This event occurs after
+WEBKIT_FORM_SUBMISSION_WILL_SEND_DOM_EVENT if that event is
+emitted.
Set whether the element is an HTML input element that has been filled automatically.
+If element
+ is not an HTML input element this function does nothing.
Get the default WebKitScriptWorld. This is the normal script world
+where all scripts are executed by default.
+You can get the JavaScript execution context of a WebKitScriptWorld
+for a given WebKitFrame with webkit_frame_get_javascript_context_for_script_world().
Creates a new isolated WebKitScriptWorld. Scripts executed in
+isolated worlds have access to the DOM but not to other variable
+or functions created by the page.
+The WebKitScriptWorld is created with a generated unique name. Use
+webkit_script_world_new_with_name() if you want to create it with a
+custom name.
+You can get the JavaScript execution context of a WebKitScriptWorld
+for a given WebKitFrame with webkit_frame_get_javascript_context_for_script_world().
Creates a new isolated WebKitScriptWorld with a name. Scripts executed in
+isolated worlds have access to the DOM but not to other variable
+or functions created by the page.
+You can get the JavaScript execution context of a WebKitScriptWorld
+for a given WebKitFrame with webkit_frame_get_javascript_context_for_script_world().
Emitted when the JavaScript window object in a WebKitScriptWorld has been
+cleared. This is the preferred place to set custom properties on the window
+object using the JavaScriptCore API. You can get the window object of frame
+
+from the JavaScript execution context of world
+ that is returned by
+webkit_frame_get_javascript_context_for_script_world().
The WebKitWebEditor provides access to various editing capabilities of
+a WebKitWebPage such as a possibility to react to the current selection in
+WebKitWebPage.
This signal is emitted for every selection change inside a WebKitWebPage
+as well as for every caret position change as the caret is a collapsed
+selection.
WebKitWebExtension is a loadable module for the WebProcess. It allows you to execute code in the
+WebProcess and being able to use the DOM API, to change any request or to inject custom
+JavaScript code, for example.
+
To create a WebKitWebExtension you should write a module with an initialization function that could
+be either webkit_web_extension_initialize() with prototype WebKitWebExtensionInitializeFunction or
+webkit_web_extension_initialize_with_user_data() with prototype WebKitWebExtensionInitializeWithUserDataFunction.
+This function has to be public and it has to use the G_MODULE_EXPORT macro. It is called when the
+web process is initialized.
The previous piece of code shows a trivial example of an extension that notifies when
+a WebKitWebPage is created.
+
WebKit has to know where it can find the created WebKitWebExtension. To do so you
+should use the webkit_web_context_set_web_extensions_directory() function. The signal
+“initialize-web-extensions” is the recommended place to call it.
+
To provide the initialization data used by the webkit_web_extension_initialize_with_user_data()
+function, you have to call webkit_web_context_set_web_extensions_initialization_user_data() with
+the desired data as parameter. You can see an example of this in the following piece of code:
Type definition for a function that will be called to initialize
+the web extensions when the web process starts, and which receives
+as additional argument the user data set with
+webkit_web_context_set_web_extensions_initialization_user_data().
Emitted when a message is sent to the console. This can be a message
+produced by the use of JavaScript console API, a JavaScript exception,
+a security error or other errors, warnings, debug or log messages.
+The console_message
+ contains information of the message.
Emitted before a context menu is displayed in the UI Process to
+give the application a chance to customize the proposed menu,
+build its own context menu or pass user data to the UI Process.
+This signal is useful when the information available in the UI Process
+is not enough to build or customize the context menu, for example, to
+add menu entries depending on the WebKitDOMNode at the coordinates of the
+hit_test_result
+. Otherwise, it's recommended to use “context-menu”
+signal instead.
Emitted after form elements (or form associated elements) are associated to a particular web
+page. This is useful to implement form auto filling for web pages where form fields are added
+dynamically. This signal might be emitted multiple times for the same web page.
+
Note that this signal could be also emitted when form controls are moved between forms. In
+that case, the elements
+ array carries the list of those elements which have moved.
+
Clients should take a reference to the members of the elements
+ array if it is desired to
+keep them alive after the signal handler returns.
This signal is emitted when request
+ is about to be sent to
+the server. This signal can be used to modify the WebKitURIRequest
+that will be sent to the server. You can also cancel the resource load
+operation by connecting to this signal and returning TRUE.
+
In case of a server redirection this signal is
+emitted again with the request
+ argument containing the new
+request to be sent to the server due to the redirection and the
+redirected_response
+ parameter containing the response
+received by the server for the initial request.
+
Modifications to the WebKitURIRequest and its associated
+SoupMessageHeaders will be taken into account when the request
+is sent over the network.
This signal is emitted to indicate various points during form
+submission. step
+ indicates the current stage of form submission.
+
If this signal is emitted with WEBKIT_FORM_SUBMISSION_WILL_SEND_DOM_EVENT,
+then the DOM submit event is about to be emitted. JavaScript code
+may rely on the submit event to detect that the user has clicked
+on a submit button, and to possibly cancel the form submission
+before WEBKIT_FORM_SUBMISSION_WILL_COMPLETE. However, beware
+that, for historical reasons, the submit event is not emitted at
+all if the form submission is triggered by JavaScript. For these
+reasons, WEBKIT_FORM_SUBMISSION_WILL_SEND_DOM_EVENT may not
+be used to reliably detect whether a form will be submitted.
+Instead, use it to detect if a user has clicked on a form's
+submit button even if JavaScript later cancels the form
+submission, or to read the values of the form's fields even if
+JavaScript later clears certain fields before submitting. This
+may be needed, for example, to implement a robust browser
+password manager, as some misguided websites may use such
+techniques to attempt to thwart password managers.
+
If this signal is emitted with WEBKIT_FORM_SUBMISSION_WILL_COMPLETE,
+the form will imminently be submitted. It can no longer be
+cancelled. This event always occurs immediately before a form is
+submitted to its target, so use this event to reliably detect
+when a form is submitted. This event occurs after
+WEBKIT_FORM_SUBMISSION_WILL_SEND_DOM_EVENT if that event is
+emitted.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
This is the first development release leading towards the 0.12 series.
+
What’s new in Cog 0.11.1?
+
+
core: Changed platform plug-ins to be able to automatically detect which
+one should be used. Passing the --platform= command line option to the
+launcher is now optional.
+
core: Added support for building against libsoup3.
+
core: Added CogHostRoutesHandler, which can route URI scheme requests
+with different host parts to other handlers.
+
core, cog: Added support for running in WebDriver automation mode.
+
cog: New --enable-sandbox command line option, which allows isolating
+rendering processes from the rest of the system.
+
cog: New --content-filter= command line option, which allows loading
+a content blocker (WebKitUserContentFilter) JSON rule set.
wl: Renamed fdo platform module to wl (Wayland) as it better reflects
+its usage; the old name still works e.g. when using cog --platform=fdo
+but it is considered deprecated and will cause a warning.
+
wl, gtk4: Added support for fullscreening web views.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
This is the first stable release in the 0.12 series.
+
Highlights of the 0.12.0 release
+
+
cog: New --enable-sandbox command line option, which allows isolating
+rendering processes from the rest of the system.
+
cog: New --content-filter= command line option, which allows loading
+a content blocker (WebKitUserContentFilter) JSON rule set.
+
core, cog: Added support for running in WebDriver automation mode.
+
core: Changed platform plug-ins to be able to automatically detect which
+one should be used. Passing the --platform= command line option to the
+launcher is now optional.
+
core: Added support for building against libsoup3.
+
core: Added CogHostRoutesHandler, which can route URI scheme requests
+with different host parts to other handlers.
+
core: Removed cog_platform_teardown(), deinitilization of platform
+plug-in implementations is now done automatically as part of object
+finalization.
+
wl: Renamed fdo platform module to wl (Wayland) as it better reflects
+its usage; the old name still works e.g. when using cog --platform=fdo
+but it is considered deprecated and will cause a warning.
+
wl, gtk4: Added support for fullscreening web views.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
This is the first bug fix release in the stable 0.12 series.
+
What’s new in Cog 0.12.1?
+
+
wl: Fixed handling of supported Wayland protocol versions, preventing a
+crash with certain compositors which advertise support for newer versions
+than actually supported by the client.
+
Fixed the location used by CMake to install platform plug-ins.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
This is the first development release leading towards the 0.20 series.
+
What’s new in Cog 0.19.1?
+
+
Support multiple web views, using the new
+CogView and
+CogViewport APIs.
+Each viewport may display one from a set of web views, and using many
+viewports is supported as well. Typically platform plug-ins map a
+viewport to some kind of “window” that can be displayed on screen.
+Most of the changes in this release are related to this new feature.
+
launcher:
+
+
Add command line flag to disable the built-in key bindings.
+
Add command line flag to control media auto-play behaviour.
+
Handle GApplication activation to avoid a warning.
+
+
+
core:
+
+
Moved most of the key binding handling from the Wayland platform
+into CogView, making it common code for all platforms.
+
Moved platform plug-in selection logic into the library, along
+with an always-built “fallback” implementation, which simplifies API
+usage.
+
Avoid leaking web views due to CogShell holding one reference
+too much on them.
+
The library now takes advantage of symbol visibility, and only
+the public symbols marked with the COG_API macro will be available for
+linking from the shared library.
+
Avoid loading the same platform plug-in more than once.
+
Automatically scan the default module path without needing
+programs to call
+cog_modules_add_directory()
+by themselves.
+
Remove the cog_platform_configure() function, in favor of
+a new cog_init() function
+which is optional to call, and reorganized setup code to make API
+usage simpler.
+
+
+
meson:
+
+
Fix configuration error when only the Wayland platform plug-in
+is selected.
+
+
+
drm:
+
+
Fix touch region dimensions when the output is rotated by 90
+or 270 degrees.
+
Fix crash on iMX.6 (and possibly others) by improving how the
+CRTC and encoder combination is chosen.
+
+
+
x11:
+
+
Add support for using the xcb-keysyms library for handling key
+input events when the XKB extension is unavailable, either because
+its usage was disabled at build time, or the extension is missing at
+runtime.
+
+
+
wl:
+
+
Add support for Weston protocols version 13.
+
Fix blurry rendering in some compositors.
+
Add a check for memfd_create() to avoid the need to have write
+permission in XDG_RUNTIME_DIR, which is the case in some systems.
+
Set the opaque region also for non-fullscreen surfaces, resulting
+in a small performance improvement in some cases.
+
Add support for multiple seats.
+
Remove limit of 16 maximum outputs.
+
+
+
gtk4, x11, wl:
+
+
Add support for file choosers using the XDG Desktop
+Portal through libportal.
+
Add support for changing mouse cursors when hovering
+links (hand) and text (I-beam).
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
This is a development release leading towards the 0.4 series.
+
What’s new in the cog 0.3.91 release?
+
+
HiDPI support. The “cog --device-scale” option can be used to set the
+initial scale factor.
+
Using “cog --version” now also prints the WebKit version and (if available
+at build time), Git repository information.
+
The libcogcore library now has proper libtool versioning.
+
fdo: Fix axis scrolling.
+
New “experimental-drm” platform plug-in which uses KMS+DRM (Kernel Mode
+Setting, Direct Rendering Manager) for direct display on framebuffers,
+and libinput for input event processing.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Adopted the same release schedule and versioning scheme as the rest of
+the WPE WebKit components.
+
New experimental-drm platform plug-in which uses KMS+DRM (Kernel Mode
+Setting, Direct Rendering Manager) for direct display on framebuffers,
+and libinput for input event processing.
+
+
For more details about all the changes included in Cog 0.4 see the NEWS
+file included in the release tarball.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
This is the first development release leading towards the 0.10 series.
+
What’s new in Cog 0.9.1?
+
+
core: Added CogPrefixRoutesHandler, which can route URI scheme requests
+with different path prefixes to other handlers.
+
core: Added new CogShell.device-scale-factor property.
+
core: Added support in CogDirectoryFilesHandler to use the URI host part
+as a path component, to ignore a certain amount of path components, and
+expose the base path as a property.
+
core: Removed support for building using WebKitGTK, only the WPE port is
+supported now.
+
drm: The DRM/KMS platform module is now built by default.
+
drm: Added support for key press event repeat.
+
drm: Added support for mouse cursor.
+
drm: Added support for atomic modesetting, which is automatically used
+by default when support is detected in the video driver.
+
drm: Added support for limiting the maximum used video mode width and
+height, settable using the COG_PLATFORM_DRM_MODE_MAX environment variable.
+
drm: Fixed usage of the specified output device scaling factor.
+
drm: Improve logging output.
+
drm, fdo: Added support for SHM buffer exports, which for example allows
+using Mesa’s software rasterization.
+
fdo: Try using the largest available output video mode when using the
+zwp_fullscreen_shell_v1 protocol.
+
headless: Added new headless platform module, which does not produce
+output and can be used without any graphics hardware e.g. in combination
+with Mesa’s software rasterization.
+
x11: Added new x11 platform module, which uses an X11 window to paint
+rendered web content using XCB and OpenGL.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
This is a development release leading towards the 0.10 series.
+
What’s new in Cog 0.9.90?
+
+
Support building documentation for the Cog core library using gi-docgen.
+
gtk4: Added new gtk4 platform module, which works on Wayland and uses
+GTK4 to render web content into a GtkGLArea and provides a minimal yet
+usable user interface
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
This release changes the API version to 0.2, and introduces the following
+changes and features:
+
What’s new in the libwpe 1.0.0 release?
+
+
+
The library is now called libwpe to avoid confusion. The WPEBackend name
+used previously seemed to indicate that the library implemented a WPE
+backend. The new libwpe name better reflects that it contains code needed
+by the WPE WebKit port (#27).
Handle conversion of keysyms to Unicode inside libwpe. This allowed to
+remove the unicode member from keyboard event structs, and removing
+wpe_input_key_mapper/wpe_input_key_mapper_interface
+(#23).
+
+
+
New field in event structs to specify keyboard modifiers
+(#22).
+
+
+
New API for keymap and composition handling based on libxkbcommon
+(#24).
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
This is a development release of libwpe, which introduces the following
+changes and features:
+
What’s new in the libwpe 1.1.0 release?
+
+
+
Support building libwpe on Windows (#32, #31, #33).
+
+
+
New API for observing and setting the view backend state (#36).
+
+
+
Added a new wpe_renderer_backend_egl_get_platform() function which can
+be used to obtain a value which can be passed to eglGetPlatformDisplay()
+and eglGetPlatformDisplayEXT() (#39, #40).
+
+
+
Marked old function names containing the “backend” word as deprecated.
+The symbols are still available, but it is encouraged to use the new
+versions, e.g. prefer wpe_get_major_version() instead of
+wpe_backend_get_major_version() (#38).
+
+
+
Marked function table struct parameters passed to some API functions
+as const (#29).
+
+
+
Fixed headers so including <wpe-egl.h> results in <wpe.h> being included
+automatically in the correct order (#34).
+
+
+
Make instantiation of backends more robust by checking the validity of
+interface pointers obtained from the backend (#30).
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
This is the first stable release in the 1.10 series.
+
Highlights of the libwpe 1.10.0 release
+
+
New API to explicitly deinitialize an EGL renderer target, which allows
+implementors of the wpe_renderer_backend_egl_target_interface to
+differentiate between destruction and deinitialization.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
This is the first development release leading towards the 1.14 series.
+
What’s new in libwpe 1.13.1?
+
+
New API to provide input events to be treated by WebKit as gamepad inputs.
+
New WPE_ENABLE_XKB build option, enabled by default, which can be used
+to completely avoid usage of libxkbcommon.
+
Allow libwpe to be built as a static library. The rest of the code
+linked with the static library must provide the _wpe_loader_interface
+symbol, as dlopen() will not be used.
+
Allow building libwpe within a larger CMake project.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
This is a development release leading towards the 1.14 series.
+
What’s new in libwpe 1.13.3?
+
+
Modify the gamepad API to pass the wpe_gamepad_provider when creating
+new gamepad instances, and the associated wpe_gamepad_provider_get_backend()
+accessor.
+
Restrict the range of values allowed for the device scaling factor, which
+prevents both divisions by zero and impossibly big graphics buffers.
+
Fix pasteboard to use the generic interface by default.
+
Fix memory allocation to always abort execution on failure.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
This is a development release leading towards the 1.10 series.
+
What’s new in libwpe 1.9.91?
+
+
New API to explicitly deinitialize an EGL renderer target, which allows
+implementors of the wpe_renderer_backend_egl_target_interface to
+differentiate between destruction and deinitialization.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
There are two feature releases are done every year, typically in March
+and September.
+
Within feature releases, there may be any number of bug-fix releases.
+
Development releases are the base for the feature releases that follow
+them. They do not follow a fixed schedule in the release cycle.
+
+
WPE WebKit and WebKitGTK share a fair amount of code.
+Therefore, both projects produce their feature releases simultaneously,
+and share the same release branches. For bug-fix releases, the release
+teams for both projects try to sync their version numbers as well as they
+can.
+
Versioning Scheme
+
Version numbers follow the major.minor.patch numbering scheme. Changes to
+the major version signify considerable architectural or API changes; the
+minor version number changes throughout the development cycle. Even numbers
+indicate stable releases and odd ones development releases. Lastly, the
+patch number is incremented for each release, and for stable release
+candidates it is bumped to 90.
+
+
+
+
Kind
+
Minor
+
Patch
+
+
+
+
+
Stable
+
even
+
any
+
+
+
Development
+
odd
+
< 90
+
+
+
Release Candidate
+
odd
+
≥ 90
+
+
+
+
For stable releases the following is always true, as long as the major
+version number stays the same:
+
+
New patch releases are guaranteed to be backward-compatible both
+at the API and ABI level.
+
New minor releases may contain new features and backward-compatible
+changes in the public API. In general, the ABI will remain compatible as
+well, because we actively avoid breaking it unless strictly needed.
+
+
Compatible Components
+
The following table summarizes which stable releases of libwpe, WPE WebKit,
+WPEBackend-fdo, and Cog are compatible and tested with each other (updated
+April 2023). Distributors and packagers are strongly advised to use the
+versions listed below.
+
+
+
+
WPE WebKit
+
libwpe
+
WPEBackend-fdo
+
Cog
+
+
+
+
+
2.42.x
+
1.14.x
+
1.14.x
+
0.18.x
+
+
+
2.40.x
+
1.14.x, 1.12.x
+
1.14.x, 1.12.x
+
0.16.x
+
+
+
2.38.x
+
1.14.x, 1.12.x
+
1.14.x, 1.12.x, 1.10.x
+
0.16.x, 0.14.x, 0.12.x
+
+
+
2.36.x
+
1.12.x, 1.10.x
+
1.12.x, 1.10.x
+
0.14.x, 0.12.x, 0.10.x
+
+
+
2.34.x
+
1.12.x, 1.10.x, 1.8.x
+
1.12.x, 1.10.x
+
0.12.x, 0.10.x, 0.8.x
+
+
+
2.32.x
+
1.10.x, 1.8.x, 1.6.x
+
1.10.x, 1.8.x
+
0.10.x, 0.8.x
+
+
+
2.30.x
+
1.8.x, 1.6.x
+
1.10.x, 1.8.x
+
0.8.x, 0.6.x
+
+
+
2.28.x
+
1.6.x
+
1.6.x
+
0.8.x, 0.6.x
+
+
+
2.26.x
+
1.4.x
+
1.4.x
+
0.4.x
+
+
+
2.24.x
+
1.2.x
+
1.2.x
+
0.3.x
+
+
+
2.22.x
+
1.0.x
+
1.0.x
+
0.2.x
+
+
+
2.20.x
+
< 1.0.0
+
< 1.0.0
+
≤ 0.1.x
+
+
+
+
Notes:
+
+
libwpe used to be called wpebackend before version 1.0.x — it was renamed to
+avoid confusion.
+
Cog adopted the same versioning scheme as the rest of the components
+starting with the 0.6 series.
+
+
+
+
+
+
+
+
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
WPE release tarballs are cryptographically signed and can be verified
+using PGP signatures (in an .asc file) and their
+checksums (in a .sums file). Everybody is encouraged to verify
+the integrity of downloaded files using them.
+
PGP Signatures
+
Every release is accompanied by a cryptographic signature produced by the
+person in charge of publishing the release. This signature allows anyone to
+check whether the files have been tampered with after they have been signed.
+Forging a signature is practically impossible without gaining access to the
+private key used. If that were to happen, the compromised key would be revoked
+and all files re-signed with new keys.
+
Keys
+
The following PGP keys are currently in use for signing releases:
Once downloaded, keys need to be imported in the PGP keyring, for example with
+GnuPG:
+
% gpg --import aperez.key
+gpg: key 91C559DBE4C9123B: 1 signature not checked due to a missing key
+gpg: key 91C559DBE4C9123B: public key "Adrián Pérez de Castro <aperez@igalia.com>" imported
+gpg: key 56736249E4C9123B: 11 signatures not checked due to missing keys
+gpg: key 56736249E4C9123B: public key "Adrián Pérez de Castro <aperez@igalia.com>" imported
+gpg: Total number processed: 2
+gpg: imported: 2
+gpg: no ultimately trusted keys found
+
+
Checking
+
The signature file for each release has the same name plus the .asc suffix.
+Given a download URL, the following illustrates the process:
Now it is possible to verify the .tar.xz file against its signature:
+
% gpg --verify wpewebkit-2.34.3.tar.xz.asc
+gpg: assuming signed data in 'wpewebkit-2.34.3.tar.xz'
+gpg: Signature made lun 20 dic 2021 00:05:24 EET
+gpg: using DSA key 5AA3BC334FD7E3369E7C77B291C559DBE4C9123B
+gpg: Good signature from "Adrián Pérez de Castro <aperez@igalia.com>" [ultimate]
+gpg: aka "Adrián Pérez de Castro (personal) <adrian@perezdecastro.org>" [ultimate]
+Primary key fingerprint: 5AA3 BC33 4FD7 E336 9E7C 77B2 91C5 59DB E4C9 123B
+
+
Checksums
+
Checksums for release tarballs are also published along releases. While
+suitable to check file integrity, using PGP signatures
+provide a stronger guarantee.
+
Checking
+
The checksums file for each release has the same name plus the .sums suffix.
+Given a download URL, the following illustrates how to calculate the SHA-256
+checksum on your end:
% expected=$(tail -1 wpewebkit-2.34.3.tar.xz.sums | cut -f5 -d' ')
+% calculated=$(sha256sum wpewebkit-2.34.3.tar.xz | cut -f1 -d' ')
+% if [ "$expected" = "$calculated" ]; then echo ok ; else echo failed ; fi
+ok
+
+
+
+
+
+
+
+
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
This is the first development release leading toward 2.22 series.
+
What’s new in the WPE WebKit 2.21.1 release?
+
+
Everything. This is the first release. Enjoy.
+
+
Thanks to all the contributors who made possible this release, they
+are far too many to list!
+
+
+
+
+
+
+
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
This is the last development release leading toward the 2.20 series.
+
What’s new in the WPE WebKit 2.19.93 release?
+
+
Remove unusable JavaScript APIs
+
Fix missing WebKitHitTestResult.h
+
+
Thanks to all the contributors who made possible this release, they
+are far too many to list!
+
+
+
+
+
+
+
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
This is the first stable release in the 2.20 series.
+
What’s new in the WPE WebKit 2.20.0 release?
+
+
Add support for the fullscreen API.
+
Fix build in architectures which need linking with libatomic to support atomic operations on 64-bit values.
+
Fix build failure when using the RaspberryPi userland GPU drivers in combination with GStreamer-GL.
+
+
Thanks to all the contributors who made possible this release, they
+are far too many to list!
+
+
+
+
+
+
+
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Thanks to all the contributors who made possible this release, they
+are far too many to list!
+
+
+
+
+
+
+
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
This is a development release leading toward 2.22 series.
+
What’ new in WPE WebKit 2.21.2?
+
+
Add initial support for the fullscreen Web API.
+
Add initial implementation of WebDriver advance user interaction commands.
+
Add introspectable alternatives for functions using vargars to JavaScriptCore GLib API.
+
Fix memory pressure monitor to reliably notify all subprocesses.
+
Fix building with the Raspberry Pi userland GPU driver and certain versions of GStreamer-GL.
+
Fix building with the ICU headers in a non-default directory.
+
Fix several crashes and rendering issues.
+
+
Thanks to all the contributors who made possible this release, they
+are far too many to list!
+
+
+
+
+
+
+
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
This is a development release leading towards the 2.22 series.
+
What’s new in the WPE WebKit 2.21.92 release?
+
+
New MiniBrowser for WPE, which can be enabled at build time.
+
Add warn_unused_result attribute to some JavaScriptCore GLib APIs.
+
Fix the build in MIPS64.
+
Add new API to inject/register user content in isolated worlds.
+
Add more API to JSCException to handle column number, convert exception
+to string, get the exception backtrace, create exceptions with a custom
+error name and report exception message with full details.
+
Fix excessive CPU usage when getting the process memory footprint.
+
Fix several crashes and rendering issues.
+
+
Thanks to all the contributors who made possible this release, they
+are far too many to list!
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
This is the first stable release in the 2.22 series.
+
What’s new in the WPE WebKit 2.22.0 release?
+
+
Several fixes for video playback with media source extensions (MSE).
+This allows using WebM support for YouTube, which no longer works through
+regular video source. Note that MSE is still disabled by default and
+webkit_settings_set_enable_mediasource() has to be used to enable the
+feature.
+
Add warn_unused_result attribute to some JavaScriptCore GLib APIs.
+
Fix the build in several platforms: s390x, ppc64le, armv7hl, mips64.
+
Fix the build with video disabled.
+
Fix symbols with jsc_ prefix not being exported.
+
Fix a memory leak during media playback when using playbin3.
+
Fix several crashes and rendering issues.
+
+
Thanks to all the contributors who made possible this release, they
+are far too many to list!
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
This is the first bug fix release in the stable 2.22 series.
+
What’s new in the WPE WebKit 2.22.1 release?
+
+
Many improvements and fixes for video playback with media source
+extensions (MSE), which improve the user experience across the board,
+and in particular for playback of WebM videos.
+
Expose ENABLE_MEDIA_SOURCE as a public build option.
+
Fix Resource Timing reporting for <iframe> elements.
+
Fix the build with ENABLE_VIDEO=OFF and ENABLE_WEB_AUDIO=OFF.
+
Fix the build with the remote Web Inspector disabled.
+
Fix several crashes and rendering issues.
+
+
Thanks to all the contributors who made possible this release, they
+are far too many to list!
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
This is a backwards-compatible, stable release of the WPE backend loader
+library.
+
What’s new in the WPBackend 0.2.0 release?
+
+
+
New API to set and query the backend implementation library being used
+(#19).
+
+
+
New API to query the version library, both with macros at build time,
+and functions at runtime
+(#18).
+
+
+
Trying to use a backend implementation library which does not provide
+a load_object callback will produce a meaningful error instead of
+silently failing.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
New API which supports exporting frames as EGL images. This provides
+applications with a ready to to render EGLImage, and has the advantage
+that the library hides the actual protocol used by the backend’s nested
+compositor from the application
+(#16).
+
+
+
Improved dispatching of Wayland events
+(#11,
+#15).
+
+
+
Support using DMA-BUF Wayland surfaces
+(#18,
+#17,
+#13).
+
+
+
Support using Wayland versions older than 1.10
+(#19).
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
This is a bugfix release in the stable 1.0 series.
+
What’s new in the WPEBackend-fdo 1.0.1 release?
+
+
Allow wpe_fdo_initialize_for_egl_display() to be called multiple times;
+it will emit a warning when trying to switch to a different EGL display,
+which is unsupported (#26).
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Thiss is the first development release leading towards the 1.2 series.
+
What’s new in the WPEBackend-fdo 1.1.0 release?
+
+
+
Use the new libwpe API to notify when frames have been displayed
+(#28).
+
+
+
Allow calling wpe_fdo_initialize_for_egl_display() multiple times, with a
+warning printed to the standard error output when trying to switch displays
+(which is unsupported)
+(#26).
+
+
+
Provide a dummy implementation of the EGL offscreen target interface, to let
+WebKit use Pbuffer-based offscreen contexts as fallback, instead of crashing
+(5a4b58c).
+
+
+
Minor cleanups in headers and function prototypes
+(#25,
+#24).
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Improved how CMake searches for wayland-scanner, making it friendlier for
+cross-compilation (#39).
+
+
+
Fixed the build when using EGL headers which define prototypes for
+EGL extensions (#51),
+and when the EGL_WAYLAND_BUFFER_WL definition is missing
+(#50).
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Fix build when --no-undefined is passed to the linker. This was caused
+due to an explicit reference to the GObject library missing in the linker
+command line.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
This is a development release leading towards the 2.26 series.
+
What’s new in the WPE WebKit 2.25.91 release?
+
+
Do not enable the sandbox in Snap.
+
Fix sandbox parsing DISPLAY on X11.
+
Add WEBKIT_USE_SINGLE_WEB_PROCESS environment variable to force single process model in all WebKitWebContext.
+This is a temporary solution for applications still depending on the single process mode behavior. It will be
+only available in 2.26 series.
+
Add new API to remove a filter from an user content manager given its identifier.
+
Add support for HSTS.
+
Several improvements and bug fixes in MSE media player.
+
Switch to use libsoup WebSockets API.
+
Add support for permessage-deflate WebSocket extension.
+
Add user agent quirk to make GitHub work in FreeBSD.
+
Fix content disappearing when using CSS transforms.
+
Fix building without unified sources.
+
Fix web process deadlock when scrolling twitter timeline which contains HLS videos.
+
Fix a crash with empty video source.
+
Fix some radio streams that could not be played.
+
Fix video pause that sometimes caused to skip to finish.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
This is the first development release leading towards the 2.32 series.
+
What’s new in WPE WebKit 2.31.1?
+
+
Removed support for NPAPI plugins.
+
Enabled the web process cache when PSON is enabled too.
+
TLS errors and the proxy settings APIs have been moved from WebKitContext
+to WebKitWebsiteDataManager.
+
Added new API to remove individual scripts and style sheets using
+WebKitUserContentManager.
+
Fixed application of the system font scaling factor.
+
Added support for showing information about main loop frames in the web
+inspector.
+
Added internal audio rendering support. The WebProcess can now maintain a
+single connection to the system audio service and perform audio mixing
+internally. For the time being this has to be enabled at runtime through
+the WEBKIT_GST_ENABLE_AUDIO_MIXER=1 environment variable.
+
Switched GStreamer initialization to be on-demand and mostly contained to
+the WebProcess. GStreamer used to be initialized unconditionally once from
+the UIProcess and once from the WebProcess. GStreamer is now used mostly only
+from the WebProcess, even for probing audio and video capture devices. Users
+of the webkit_web_view_can_show_mime_type() API will still trigger GStreamer
+initialization in the UIProcess, though.
+
Changed the image decoder for videos to use decodebin3.
+
Added support for sending WebAudio to MediaStream.
+
Added multi-channel (>2) support for AudioFileReader and the WebAudio renderer.
+
Added support for audio worklets.
+
Added optional support for native formats rendering.
+
Added Opus support for the Thunder CDM.
+
Added common-encryption support for CMAF in Thunder CDM.
+
MSE/EME/WebAudio and general media playback bug fixes.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
This is a development release leading towards the 2.36 series.
+
What’s new in WPE WebKit 2.35.90?
+
+
Fix scrolling with the mouse wheel on sites using overscroll-behavior.
+
Suspend web processes after some time in the process cache.
+
Ensure EGL displays are terminated before web process exits.
+
Deinitialize GStreamer before the web process exits.
+
Make fonts under XDG_DATA_DIRS available in the web process sanbox.
+
Canonicalize paths passed to the Bubblewrap launcher.
+
The WebKitSettings:enable-developer-extras option is no longer enabled by default.
+
Allow tweaking media source buffering with the MSE_MAX_BUFFER_SIZE, and configure
+regular playback on-disk buffering with WPE_SHELL_DISABLE_MEDIA_DISK_CACHE and
+WPE_SHELL_MEDIA_DISK_CACHE_PATH environment variables.
+
Add new accessibility implementation using ATSPI D-Bus interfaces instead of ATK.
+
Add support for requestVideoFrameCallback().
+
Fix a crash at startup when the Bubblewrap sandbox is enabled.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
This is a bug fix release in the stable 2.36 series.
+
What’s new in WPE WebKit 2.36.3?
+
+
Support capturing already encoded video streams, which takes advantage
+of encoding done in hardware by devices which support this feature.
+
Avoid using experimental GStreamer elements for video demuxing.
+
Avoid using the legacy GStreamer VA-API decoding plug-ins, which often
+cause rendering issues and are not much maintained. Their usage can be
+re-enabled setting WEBKIT_GST_ENABLE_LEGACY_VAAPI=1 in the environment.
+
Fix playback of YouTube streams which use dynamic ad insertion.
+
Fix display capture with Pipewire.
+
Fix the build without the X11 target when X11 headers are not present.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
This is a bug fix release in the stable 2.36 series.
+
What’s new in WPE WebKit 2.36.4?
+
+
Fix the new ATSPI accessibility implementation to add the missing Collection interface for the loaded document.
+
Fix the MediaSession implementation to make the MPRIS object names more sandbox friendly, which plays better with Flatpak and WebKit’s own Bubblewrap-based sandboxing.
+
Fix leaked Web Processes in some particular situations.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
This is a bug fix release in the stable 2.38 series.
+
What’s new in WPE WebKit 2.38.4?
+
+
Improve GStreamer multimedia playback across the board with improved
+codec selection logic, better handling of latency, and improving
+frame discard to avoid audio/video desynchronization, among other
+fixes.
+
Disable HLS media playback by default, which makes web sites use MSE
+instead. If needed WEBKIT_GST_ENABLE_HLS_SUPPORT=1 can be set in the
+environment to enable it back.
+
Fix MediaSession API not showing artwork images.
+
Fix MediaSession MPRIS usage when running inside a Flatpak sandbox.
+
Fix input element controls to correctly scale when applying a zoom
+factor different than the default.
+
Fix leakage of Web processes in certain situations.
+
Fix the injected bundle not being found when running inside a sandbox.
+
Fix the build with ENABLE_INTROSPECTION when cross-compiling.
+
FIx the build with ENABLE_WEBGL disabled.
+
Fix the build with GStreamer-based WebRTC enabled.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
This is a bug fix release in the stable 2.38 series.
+
What’s new in WPE WebKit 2.38.6?
+
+
Support :has() CSS selectors in content filters.
+
Apply basic font properties as font variation settings.
+
The Bubblewrap sandbox no longer requires setting an application
+identifier via GApplication to operate correctly. Using GApplication
+is still recommended, but optional.
+
Improvements to the GStreamer multimedia playback, in particular
+around MSE, WebRTC, and seeking.
+
Fix the build with journald support enabled when using elogind
+instead of the systemd libraries.
+
Fix the build with Link-Time Optimization enabled (-flto=auto).
+
Fix context menus not working in the remote Web Inspector.
+
Fix usage of the remote Web Inspector over HTTP.
+
Fix debug logs not being emitted in release builds.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
This is a development release leading towards the 2.40 series.
+
What’s new in WPE WebKit 2.39.5?
+
+
Use ANGLE for the WebGL implementation and enable WebGL 2.
+
Add support for background-repeat: space.
+
Add API to check if a response policy decision is for the main resource.
+
Add support for the “get computed label” and “get computed role”
+WebDriver commands.
+
Add API to support asynchronously returning values from user script messages.
+
Add API to query the permission state of web features.
+
Add API to disable Web security.
+
Add support for client side certificates on WebSocket connections.
+
Add webkit_web_hit_test_result_get_js_node() to get the JSCValue for the node.
+
Add WebKitWebFormManager and deprecate WebKitWebPage form related signals.
+
Make checkbox, radio and inner spin button scale along by page zoom.
+
Use asynchronous scrolling also for keyboard scrolling.
+
Deprecate the WebKitConsoleMessage API.
+
Deprecate the event parameter of WebKitWebView::context-menu and
+WebKitWebView::show-option-menu signals in favor of a getter in
+WebKitContextMenu and WebKitOptionMenu.
+
Do not emit context-menu signals for the media settings popup menu.
+
Do not perform position queries on the video sink when a player
+is for audio only.
+
Fix WebGL when sandbox is enabled.
+
Fix loading of media documents.
+
Fix first party for cookies set on every media request.
+
Fix gibberish text when loading alternate data.
+
Fix rendering of checkbox and radio buttons on black backgrounds.
+
Fix several crashes and rendering issues.
+
Fix several warnings when building for ARMv7 (32-bits).
+
Fix web process leak when webkit_download_set_destination()
+is called with empty destination.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
This is the first stable release in the 2.40 series.
+
Highlights of the WPE WebKit 2.40.0 release
+
+
The new 2.0 API is now considered stable. It is still possible to build the
+old 1.0 API using -USE_SOUP2=ON, or the 1.1 API using
+-DENABLE_WPE_1_1_API=ON.
Support for the Speech Synthesis API,
+using Flite. This may be disabled at build
+time using -DENABLE_SPEECH_SYNTHESIS=OFF, which also avoids the Flite
+dependency.
+
Support client-side TLS certificates over WebSocket connections.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
This is the first bug fix release in the stable 2.40 series.
+
What’s new in WPE WebKit 2.40.1?
+
+
The Bubblewrap sandbox no longer requires setting an application
+identifier via GApplication to operate correctly. Using GApplication
+is still recommended, but optional.
+
Improvements to the GStreamer multimedia playback, in particular
+around MSE, WebRTC, and seeking.
+
Make all supported image types appear in the Accept HTTP header.
+
Long touch presses no longer generate mouse click events, to align
+with other web engines and WebKit ports.
+
Fix default database quota size definition.
+
Fix application of all caps tags listed in the font-feature-settings
+CSS property.
+
Fix the build with journald support enabled when using elogind
+instead of the systemd libraries.
+
Fix the build when libgcrypt provides a libgcrypt-config script
+instead of a pkg-config module file.
+
Fix font height calculations for the font-size-adjust CSS property.
+
Fix the build when ccache is used in certain setups.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
This is a development release leading towards the 2.42 series.
+
What’s new in WPE WebKit 2.41.2?
+
+
Properly handle the modifier value when exporting/importing DMA-BUF buffers.
+
The Bubblewrap sandbox no longer requires setting an application
+identifier via GApplication to operate correctly. Using GApplication
+is still recommended, but optional.
+
Show DRM device and render node if available in webkit://gpu.
+
Long touch presses no longer generate mouse click events, to align with
+other web engines and WebKit ports.
+
New build options to fine-tune WPE for certain hardware platforms
+(Westeros, Broadcom, Broadcom Nexus, Amlogic, Raspberry Pi).
+
Ensure that the correct GPU device is used for WebGL when using GBM.
+
Fix touchmove events not being produced.
+
Fix cap height calculation in font metrics.
+
Fix the build on i386.
+
Fix the build with libgbm disabled.
+
Fix the build with USE_WPE_VIDEO_PLANE_DISPLAY_DMABUF enabled.
+
Add WebKitClipboardPermissionRequest to handle DOM paste access requests.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
This is a bug fix release in the stable 2.42 series.
+
What’s new in WPE WebKit 2.42.5?
+
+
Fix webkit_web_context_allow_tls_certificate_for_host() to handle IPv6
+URIs produced by SoupURI.
+
Ignore stops with offset zero before last one when rendering gradients
+with Cairo.
+
Write bwrapinfo.json to disk for xdg-desktop-portal.
+
Support gamepad button sixteen (center button in center cluster).
+
Update quirks to fix compatibility issues in a number of websites,
+including bing.com, nfl.com, msn.com, bankofamerica.com,
+outlook.live.com, hulu.com, jsfiddle.net, vote.gov,
+youtube.com, airtable.com, gizmodo.com, and ceac.state.gov
+among others.
+
Fix incorrect periodic deletion of LocalStorage and IndexedDB databases
+for all websites.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK+ before 2.20.3 and WPE WebKit before
+2.20.1.
+
Credit to Jun Kokatsu (@shhnjk).
+
Impact: Visiting a maliciously crafted website may leak sensitive
+data. Description: Credentials were unexpectedly sent when fetching
+CSS mask images. This was addressed by using a CORS-enabled fetch
+method.
Credit to Markus Gaasedelen, Nick Burnett, and Patrick Biernat of
+Ret2 Systems, Inc working with Trend Micro’s Zero Day Initiative.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A race condition was
+addressed with improved locking.
Versions affected: WebKitGTK+ before 2.20.3 and WPE WebKit before
+2.20.1.
+
Credit to Alex Plaskett, Georgi Geshev, Fabi Beterke, and Nils of
+MWR Labs working with Trend Micro’s Zero Day Initiative.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A buffer overflow issue was
+addressed with improved memory handling.
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: Multiple memory corruption
+issues were addressed with improved memory handling.
Impact: Processing maliciously crafted web content may lead to an
+unexpected application crash. Description: A memory corruption issue
+was addressed with improved input validation.
Versions affected: WebKitGTK+ before 2.20.3 and WPE WebKit before
+2.20.1.
+
Credit to Natalie Silvanovich of Google Project Zero.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: Multiple memory corruption
+issues were addressed with improved memory handling.
Versions affected: WebKitGTK+ before 2.20.3 and WPE WebKit before
+2.20.1.
+
Credit to Natalie Silvanovich of Google Project Zero.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: An out-of-bounds read was
+addressed with improved input validation.
Versions affected: WebKitGTK+ before 2.20.3 and WPE WebKit before
+2.20.1.
+
Credit to Aymeric Chaib.
+
Impact: Visiting a maliciously crafted website may lead to cookies
+being overwritten. Description: A permissions issue existed in the
+handling of web browser cookies. This issue was addressed with
+improved restrictions.
Versions affected: WebKitGTK+ before 2.20.3 and WPE WebKit before
+2.20.1.
+
Credit to Samuel Groß (@5aelo) working with Trend Micro’s Zero Day
+Initiative.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: Multiple memory corruption
+issues were addressed with improved memory handling.
Versions affected: WebKitGTK+ before 2.20.0 or without libsoup
+2.62.0.
+
Credit to Dirkjan Ochtman.
+
The libsoup network backend of WebKit unexpectedly failed to use
+system proxy settings for WebSocket connections. As a result, users
+could be deanonymized by crafted web sites via a WebSocket
+connection.
Maliciously crafted web content could trigger a use-after-free of a
+TextureMapperLayer object.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK+ and
+WPE WebKit. It is the best way to ensure that you are running a safe
+version of WebKit. Please check our websites for information about the
+latest stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK+ before 2.20.4 and WPE WebKit before
+2.20.2.
+
Credit to Omair working with Trend Micro’s Zero Day Initiative.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. A memory corruption issue was addressed with
+improved memory handling.
Versions affected: WebKitGTK+ before 2.20.4 and WPE WebKit before
+2.20.2.
+
Credit to Mateusz Krzywicki working with Trend Micro’s Zero Day
+Initiative.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. A memory corruption issue was addressed with
+improved memory handling.
Versions affected: WebKitGTK+ before 2.20.4 and WPE WebKit before
+2.20.2.
+
Credit to Arayz working with Trend Micro’s Zero Day Initiative.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. A memory corruption issue was addressed with
+improved memory handling.
Versions affected: WebKitGTK+ before 2.20.4 and WPE WebKit before
+2.20.2.
+
Credit to OSS-Fuzz, Yu Zhou and Jundong Xie of Ant-financial Light-
+Year Security Lab.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. A memory corruption issue was addressed with
+improved memory handling.
Versions affected: WebKitGTK+ before 2.20.4 and WPE WebKit before
+2.20.2.
+
Credit to cc working with Trend Micro’s Zero Day Initiative.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. A memory corruption issue was addressed with
+improved memory handling.
Versions affected: WebKitGTK+ before 2.20.4 and WPE WebKit before
+2.20.2.
+
Credit to Arayz of Pangu team working with Trend Micro’s Zero Day
+Initiative.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. A memory corruption issue was addressed with
+improved memory handling.
Versions affected: WebKitGTK+ before 2.20.4 and WPE WebKit before
+2.20.2.
+
Credit to OSS-Fuzz.
+
Processing maliciously crafted web content may lead to an unexpected
+application crash. A memory corruption issue was addressed with
+improved memory handling.
Processing maliciously crafted web content may lead to an unexpected
+application crash. A memory corruption issue was addressed with
+improved input validation.
Versions affected: WebKitGTK+ before 2.20.4 and WPE WebKit before
+2.20.2.
+
Credit to OSS-Fuzz.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. A memory corruption issue was addressed with
+improved memory handling.
Versions affected: WebKitGTK+ before 2.20.4 and WPE WebKit before
+2.20.2.
+
Credit to OSS-Fuzz.
+
Processing maliciously crafted web content may lead to an unexpected
+application crash. A memory corruption issue was addressed with
+improved input validation.
Versions affected: WebKitGTK+ before 2.20.4 and WPE WebKit before
+2.20.2.
+
Credit to Jun Kokatsu (@shhnjk).
+
A malicious website may exfiltrate audio data cross-origin. Sound
+fetched through audio elements may be exfiltrated cross-origin. This
+issue was addressed with improved audio taint tracking.
Versions affected: WebKitGTK+ before 2.20.4 and WPE WebKit before
+2.20.2.
+
Credit to Yu Haiwan.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. A buffer overflow issue was addressed with improved
+memory handling.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK+ and
+WPE WebKit. It is the best way to ensure that you are running safe
+versions of WebKit. Please check our websites for information about the
+latest stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Unexpected interaction with indexing types caused a failure. An
+array indexing issue existed in the handling of a function in
+JavaScriptCore. This issue was addressed with improved checks.
Versions affected: WebKitGTK+ and WPE WebKit before 2.22.0.
+
Credit to Ivan Fratric of Google Project Zero.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. A use after free issue was addressed with improved
+memory management.
Versions affected: WebKitGTK+ and WPE WebKit before 2.22.0.
+
Credit to Samuel Groβ (saelo) working with Trend Micro’s Zero Day
+Initiative.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK+ and WPE WebKit before 2.22.0.
+
Credit to Ivan Fratric of Google Project Zero.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. A use after free issue was addressed with improved
+memory management.
Versions affected: WebKitGTK+ and WPE WebKit before 2.22.0.
+
Credit to an anonymous researcher working with Trend Micro’s Zero
+Day Initiative.
+
A malicious website may be able to execute scripts in the context of
+another website. A cross-site scripting issue existed in WebKit.
+This issue was addressed with improved URL validation.
Versions affected: WebKitGTK+ and WPE WebKit before 2.22.0.
+
Credit to Ivan Fratric of Google Project Zero.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. A use after free issue was addressed with improved
+memory management.
Versions affected: WebKitGTK+ and WPE WebKit before 2.22.0.
+
Credit to Ivan Fratric of Google Project Zero.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. A use after free issue was addressed with improved
+memory management.
Versions affected: WebKitGTK+ and WPE WebKit before 2.22.0.
+
Credit to Ivan Fratric of Google Project Zero.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. A use after free issue was addressed with improved
+memory management.
Versions affected: WebKitGTK+ and WPE WebKit before 2.22.0.
+
Credit to crixer, Hanming Zhang (@4shitak4) of Qihoo 360 Vulcan
+Team.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. A memory corruption issue was addressed with
+improved state management.
Versions affected: WebKitGTK+ and WPE WebKit before 2.22.0.
+
Credit to Ivan Fratric of Google Project Zero.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. A use after free issue was addressed with improved
+memory management.
Versions affected: WebKitGTK+ and WPE WebKit before 2.22.0.
+
Credit to Ivan Fratric of Google Project Zero.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. A use after free issue was addressed with improved
+memory management.
Versions affected: WebKitGTK+ and WPE WebKit before 2.22.0.
+
Credit to John Pettitt of Google.
+
A malicious website may cause unexepected cross-origin behavior. A
+cross-origin issue existed with iframe elements. This was addressed
+with improved tracking of security origins.
Versions affected: WebKitGTK+ and WPE WebKit before 2.22.0.
+
Credit to Ivan Fratric of Google Project Zero.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK+ and WPE WebKit before 2.22.0.
+
Credit to Ivan Fratric of Google Project Zero.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK+ and WPE WebKit before 2.22.0.
+
Credit to @phoenhex team (@bkth_ @5aelo @_niklasb) working with
+Trend Micro’s Zero Day Initiative.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK+ and WPE WebKit before 2.22.0.
+
Credit to Samuel Groß (@5aelo).
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK+ and WPE WebKit before 2.22.0.
+
Credit to Google OSS-Fuzz.
+
Unexpected interaction causes an ASSERT failure. A memory corruption
+issue was addressed with improved memory handling.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK+ and
+WPE WebKit. It is the best way to ensure that you are running safe
+versions of WebKit. Please check our websites for information about the
+latest stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK+ before 2.22.4 and WPE WebKit before
+2.22.2.
+
Credit to HyungSeok Han, DongHyeon Oh, and Sang Kil Cha of KAIST
+Softsec Lab, Korea.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK+ and WPE WebKit before 2.22.0.
+
Credit to ngg, alippai, DirtYiCE, KT of Tresorit working with Trend
+Micro’s Zero Day Initiative.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK+ before 2.22.1 and WPE WebKit before
+2.22.0.
+
Credit to Yu Haiwan and Wu Hongjun From Nanyang Technological
+University working with Trend Micro’s Zero Day Initiative.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK+ before 2.22.1 and WPE WebKit before
+2.22.0.
+
Credit to 010 working with Trend Micro’s Zero Day Initiative.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK+ before 2.22.1 and WPE WebKit before
+2.22.0.
+
Credit to lokihardt of Google Project Zero.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK+ before 2.22.3 and WPE WebKit before
+2.22.1.
+
Credit to lokihardt of Google Project Zero.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK+ before 2.22.1 and WPE WebKit before
+2.22.0.
+
Credit to zhunki of 360 ESG Codesafe Team.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK+ before 2.22.1 and WPE WebKit before
+2.22.0.
+
Credit to lokihardt of Google Project Zero.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK+ and
+WPE WebKit. It is the best way to ensure that you are running safe
+versions of WebKit. Please check our websites for information about the
+latest stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK+ before 2.22.5 and WPE WebKit before
+2.22.3.
+
Credit to HyungSeok Han, DongHyeon Oh, and Sang Kil Cha of KAIST
+Softsec Lab, Korea.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK+ before 2.22.3 and WPE WebKit before
+2.22.1.
+
Credit to lokihardt of Google Project Zero.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. A logic issue existed resulting in memory
+corruption. This was addressed with improved state management.
Versions affected: WebKitGTK+ before 2.22.3 and WPE WebKit before
+2.22.1.
+
Credit to lokihardt of Google Project Zero.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. A memory corruption issue was addressed with
+improved memory handling.
Versions affected: WebKitGTK+ before 2.22.3 and WPE WebKit before
+2.22.1.
+
Credit to lokihardt of Google Project Zero.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. A memory corruption issue was addressed with
+improved memory handling.
Versions affected: WebKitGTK+ before 2.22.3 and WPE WebKit before
+2.22.1.
+
Credit to lokihardt of Google Project Zero.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. A memory corruption issue was addressed with
+improved memory handling.
Versions affected: WebKitGTK+ and WPE WebKit before 2.22.0.
+
Credit to HyungSeok Han, DongHyeon Oh, and Sang Kil Cha of KAIST
+Softsec Lab, Korea.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK+ and
+WPE WebKit. It is the best way to ensure that you are running safe
+versions of WebKit. Please check our websites for information about the
+latest stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK+ before 2.22.6 and WPE WebKit before
+2.22.4.
+
Credit to an anonymous researcher.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK+ before 2.22.5 and WPE WebKit before
+2.22.3.
+
Credit to Fluoroacetate working with Trend Micro’s Zero Day
+Initiative.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK+ before 2.22.5 and WPE WebKit before
+2.22.3.
+
Credit to Fluoroacetate working with Trend Micro’s Zero Day
+Initiative, Proteas, Shrek_wzw, and Zhuo Liang of Qihoo 360 Nirvan
+Team.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK+ and WPE WebKit before 2.22.0.
+
Credit to Apple.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK+ before 2.22.5 and WPE WebKit before
+2.22.3.
+
Credit to Qixun Zhao of Qihoo 360 Vulcan Team.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. A memory corruption issue was addressed with
+improved memory handling.
Versions affected: WebKitGTK+ before 2.22.4 and WPE WebKit before
+2.22.2.
+
Credit to G. Geshev from MWR Labs working with Trend Micro’s Zero
+Day Initiative.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. A memory corruption issue was addressed with
+improved memory handling.
Versions affected: WebKitGTK+ before 2.22.4 and WPE WebKit before
+2.22.2.
+
Credit to G. Geshev from MWR Labs working with Trend Micro’s Zero
+Day Initiative.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. A memory corruption issue was addressed with
+improved memory handling.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK+ and
+WPE WebKit. It is the best way to ensure that you are running safe
+versions of WebKit. Please check our websites for information about the
+latest stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK before 2.22.6 and WPE WebKit before
+2.22.4.
+
Credit to dwfault working with ADLab of Venustech.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.24.1.
+
Credit to Dhiraj.
+
Processing maliciously crafted web content may lead to spoofing.
+WebKitGTK and WPE WebKit were vulnerable to a URI spoofing attack
+similar to the CVE-2018-8383 issue in Microsoft Edge.
Versions affected: WebKitGTK before 2.22.6 and WPE WebKit before
+2.22.4.
+
Credit to dwfault working at ADLab of Venustech.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. A use after free issue was addressed with improved
+memory management.
Versions affected: WebKitGTK before 2.22.6 and WPE WebKit before
+2.22.4.
+
Credit to James Lee, @Windowsrcer.
+
Processing maliciously crafted web content may disclose sensitive
+user information. A cross-origin issue existed with the fetch API.
+This was addressed with improved input validation.
Versions affected: WebKitGTK before 2.22.7 and WPE WebKit before
+2.22.5.
+
Credit to Samuel Groß of Google Project Zero.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK before 2.22.7 and WPE WebKit before
+2.22.5.
+
Credit to Apple.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.24.0.
+
Credit to G. Geshev working with Trend Micro Zero Day Initiative.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.24.0.
+
Credit to Zhiyang Zeng, @Wester, of Tencent Blade Team.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. A memory corruption issue was addressed with
+improved state management.
Versions affected: WebKitGTK and WPE WebKit before 2.24.0.
+
Credit to Apple.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. A memory corruption issue was addressed with
+improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.24.0.
+
Credit to an anonymous researcher.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. A memory corruption issue was addressed with
+improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.24.0.
+
Credit to Samuel Groß of Google Project Zero.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.24.0.
+
Credit to Apple.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.24.0.
+
Credit to Apple.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.24.1.
+
Credit to Igalia.
+
WebKitGTK and WPE WebKit failed to properly apply configured HTTP
+proxy settings when downloading livestream video (HLS, DASH, or
+Smooth Streaming), an error resulting in deanonymization. This issue
+was corrected by changing the way livestreams are downloaded.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK and WPE WebKit before 2.24.1.
+
Credit to G. Geshev working with Trend Micro Zero Day Initiative,
+Liu Long of Qihoo 360 Vulcan Team.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.24.0.
+
Credit to 01 working with Trend Micro’s Zero Day Initiative.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.24.0.
+
Credit to sakura of Tencent Xuanwu Lab, jessica (@babyjess1ca_) of
+Tencent Keen Lab, and dwfault working at ADLab of Venustech.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.24.1.
+
Credit to G. Geshev of MWR Labs working with Trend Micro Zero Day
+Initiative.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.24.0.
+
Credit to an anonymous researcher.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.24.1.
+
Credit to G. Geshev working with Trend Micro Zero Day Initiative.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.24.0.
+
Credit to Suyoung Lee and Sooel Son of KAIST Web Security & Privacy
+Lab and HyungSeok Han and Sang Kil Cha of KAIST SoftSec Lab.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.24.2.
+
Credit to G. Geshev from MWR Labs working with Trend Micro Zero Day
+Initiative.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.24.1.
+
Credit to Wen Xu of SSLab at Georgia Tech.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.24.1.
+
Credit to 01 working with Trend Micro Zero Day Initiative.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.24.1.
+
Credit to Fluoroacetate working with Trend Micro’s Zero Day
+Initiative.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.24.2.
+
Credit to Junho Jang and Hanul Choi of LINE Security Team.
+
Processing maliciously crafted web content may result in the
+disclosure of process memory. An out-of-bounds read was addressed
+with improved input validation.
Versions affected: WebKitGTK and WPE WebKit before 2.24.1.
+
Credit to G. Geshev working with Trend Micro Zero Day Initiative.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.24.0.
+
Credit to Wen Xu of SSLab, Georgia Tech.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.24.1.
+
Credit to Anonymous working with Trend Micro Zero Day Initiative.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.24.2.
+
Credit to G. Geshev from MWR Labs working with Trend Micro’s Zero
+Day Initiative.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.24.0.
+
Credit to Samuel Groß of Google Project Zero.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.24.1.
+
Credit to Wen Xu of SSLab at Georgia Tech and Hanqing Zhao of
+Chaitin Security Research Lab.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.24.0.
+
Credit to Samuel Groß of Google Project Zero.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.24.0.
+
Credit to Samuel Groß of Google Project Zero.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK before 2.24.4 and WPE WebKit before
+2.24.3.
+
Credit to G. Geshev working with Trend Micro’s Zero Day Initiative.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK before 2.24.4 and WPE WebKit before
+2.24.3.
+
Credit to Sergei Glazunov of Google Project Zero.
+
Processing maliciously crafted web content may lead to universal
+cross site scripting. A logic issue existed in the handling of
+synchronous page loads. This issue was addressed with improved state
+management.
Versions affected: WebKitGTK and WPE WebKit before 2.24.3.
+
Credit to Zongming Wang (王宗明) and Zhe Jin (金哲) from Chengdu Security
+Response Center of Qihoo 360 Technology Co. Ltd.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK before 2.24.4 and WPE WebKit before
+2.24.3.
+
Credit to akayn working with Trend Micro’s Zero Day Initiative.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.24.2.
+
Credit to Apple.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.24.2.
+
Credit to Samuel Groß of Google Project Zero.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.24.3.
+
Credit to Soyeon Park and Wen Xu of SSLab at Georgia Tech.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.24.3.
+
Credit to Soyeon Park and Wen Xu of SSLab at Georgia Tech.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.24.2.
+
Credit to Jihui Lu of Tencent KeenLab.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK before 2.24.4 and WPE WebKit before
+2.24.3.
+
Credit to an anonymous researcher, Anthony Lai (@darkfloyd1014) of
+Knownsec, Ken Wong (@wwkenwong) of VXRL, Jeonghoon Shin (@singi21a)
+of Theori, Johnny Yu (@straight_blast) of VX Browser Exploitation
+Group, Chris Chan (@dr4g0nfl4me) of VX Browser Exploitation Group,
+Phil Mok (@shadyhamsters) of VX Browser Exploitation Group, Alan Ho
+(@alan_h0) of Knownsec, Byron Wai of VX Browser Exploitation.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.24.2.
+
Credit to Jihui Lu of Tencent KeenLab.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK before 2.24.4 and WPE WebKit before
+2.24.3.
+
Credit to Jihui Lu of Tencent KeenLab.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.24.3.
+
Credit to G. Geshev working with Trend Micro Zero Day Initiative.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK before 2.24.4 and WPE WebKit before
+2.24.3.
+
Credit to lokihardt of Google Project Zero.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK before 2.24.4 and WPE WebKit before
+2.24.3.
+
Credit to lokihardt of Google Project Zero.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.24.2.
+
Credit to G. Geshev working with Trend Micro’s Zero Day Initiative.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.24.3.
+
Credit to Apple.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK before 2.24.4 and WPE WebKit before
+2.24.3.
+
Credit to Insu Yun of SSLab at Georgia Tech.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.24.3.
+
Credit to lokihardt of Google Project Zero.
+
Processing maliciously crafted web content may lead to arbitrary
+code execution. Multiple memory corruption issues were addressed
+with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.24.3.
+
Credit to Sergei Glazunov of Google Project Zero.
+
Processing maliciously crafted web content may lead to universal
+cross site scripting. A logic issue existed in the handling of
+document loads. This issue was addressed with improved state
+management.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK before 2.26.0 and WPE WebKit before
+2.26.0.
+
Credit to Sergei Glazunov of Google Project Zero.
+
Impact: Processing maliciously crafted web content may lead to
+universal cross site scripting. Description: A logic issue was
+addressed with improved state management.
Versions affected: WebKitGTK before 2.24.4 and WPE WebKit before
+2.24.3.
+
Credit to Sergei Glazunov of Google Project Zero.
+
Impact: Processing maliciously crafted web content may lead to
+universal cross site scripting. Description: A logic issue was
+addressed with improved state management.
Versions affected: WebKitGTK before 2.24.4 and WPE WebKit before
+2.24.3.
+
Credit to an anonymous researcher working with Trend Micro’s Zero
+Day Initiative, cc working with Trend Micro Zero Day Initiative.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: Multiple memory corruption
+issues were addressed with improved memory handling.
Versions affected: WebKitGTK before 2.24.4 and WPE WebKit before
+2.24.3.
+
Credit to Sergei Glazunov of Google Project Zero.
+
Impact: Processing maliciously crafted web content may lead to
+universal cross site scripting. Description: A logic issue was
+addressed with improved state management.
Versions affected: WebKitGTK before 2.26.0 and WPE WebKit before
+2.26.0.
+
Credit to Wen Xu of SSLab at Georgia Tech.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: Multiple memory corruption
+issues were addressed with improved memory handling.
Versions affected: WebKitGTK before 2.24.3 and WPE WebKit before
+2.24.3.
+
Credit to Jihui Lu of Tencent KeenLab.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: Multiple memory corruption
+issues were addressed with improved memory handling.
Versions affected: WebKitGTK before 2.24.4 and WPE WebKit before
+2.24.3.
+
Credit to Sergei Glazunov of Google Project Zero.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: Multiple memory corruption
+issues were addressed with improved memory handling.
Versions affected: WebKitGTK before 2.24.2 and WPE WebKit before
+2.24.2.
+
Credit to G. Geshev working with Trend Micro Zero Day Initiative.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: Multiple memory corruption
+issues were addressed with improved memory handling.
Versions affected: WebKitGTK before 2.24.4 and WPE WebKit before
+2.24.3.
+
Credit to Sergei Glazunov of Google Project Zero.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: Multiple memory corruption
+issues were addressed with improved memory handling.
Versions affected: WebKitGTK before 2.24.0 and WPE WebKit before
+2.24.0.
+
Credit to Hugo S. Diaz (coldpointblue).
+
Impact: A user may be unable to delete browsing history items.
+Description: “Clear History and Website Data” did not clear the
+history. The issue was addressed with improved data deletion.
Versions affected: WebKitGTK before 2.26.0 and WPE WebKit before
+2.26.0.
+
Credit to Piérre Reimertz (@reimertz).
+
Impact: Visiting a maliciously crafted website may reveal browsing
+history. Description: An issue existed in the drawing of web page
+elements. The issue was addressed with improved logic.
Versions affected: WebKitGTK before 2.26.0 and WPE WebKit before
+2.26.0.
+
Credit to Eliya Stein of Confiant.
+
Impact: Maliciously crafted web content may violate iframe
+sandboxing policy. Description: This issue was addressed with
+improved iframe sandbox enforcement.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK before 2.26.0 and WPE WebKit before
+2.26.0.
+
Credit to found by OSS-Fuzz.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: Multiple memory corruption
+issues were addressed with improved memory handling.
Versions affected: WebKitGTK before 2.26.0 and WPE WebKit before
+2.26.0.
+
Credit to zhunki from Codesafe Team of Legendsec at Qi’anxin Group.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: Multiple memory corruption
+issues were addressed with improved memory handling.
Versions affected: WebKitGTK before 2.26.0 and WPE WebKit before
+2.26.0.
+
Credit to Sergei Glazunov of Google Project Zero.
+
Impact: Processing maliciously crafted web content may lead to
+universal cross site scripting. Description: A logic issue was
+addressed with improved state management.
Versions affected: WebKitGTK before 2.24.4 and WPE WebKit before
+2.24.3.
+
Credit to Samuel Groß of Google Project Zero.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: Multiple memory corruption
+issues were addressed with improved memory handling.
Versions affected: WebKitGTK before 2.26.0 and WPE WebKit before
+2.26.0.
+
Credit to found by OSS-Fuzz.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: Multiple memory corruption
+issues were addressed with improved memory handling.
Versions affected: WebKitGTK before 2.26.0 and WPE WebKit before
+2.26.0.
+
Credit to Cheolung Lee of LINE+ Security Team.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: Multiple memory corruption
+issues were addressed with improved memory handling.
Versions affected: WebKitGTK before 2.26.1 and WPE WebKit before
+2.26.1.
+
Credit to Cheolung Lee of LINE+ Graylab Security Team.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: Multiple memory corruption
+issues were addressed with improved memory handling.
Versions affected: WebKitGTK before 2.26.0 and WPE WebKit before
+2.26.0.
+
Credit to found by OSS-Fuzz.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: Multiple memory corruption
+issues were addressed with improved memory handling.
Versions affected: WebKitGTK before 2.26.1 and WPE WebKit before
+2.26.1.
+
Credit to Soyeon Park of SSLab at Georgia Tech.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: Multiple memory corruption
+issues were addressed with improved memory handling.
Versions affected: WebKitGTK before 2.26.2 and WPE WebKit before
+2.26.2.
+
Credit to an anonymous researcher.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: Multiple memory corruption
+issues were addressed with improved memory handling.
Versions affected: WebKitGTK before 2.26.1 and WPE WebKit before
+2.26.1.
+
Credit to an anonymous researcher.
+
Impact: Processing maliciously crafted web content may lead to
+universal cross site scripting. Description: A logic issue was
+addressed with improved state management.
Versions affected: WebKitGTK before 2.26.2 and WPE WebKit before
+2.26.2.
+
Credit to Cheolung Lee of LINE+ Security Team.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: Multiple memory corruption
+issues were addressed with improved memory handling.
Versions affected: WebKitGTK before 2.26.0 and WPE WebKit before
+2.26.0.
+
Credit to Apple.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: Multiple memory corruption
+issues were addressed with improved memory handling.
Versions affected: WebKitGTK before 2.26.1 and WPE WebKit before
+2.26.1.
+
Credit to Soyeon Park of SSLab at Georgia Tech.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: Multiple memory corruption
+issues were addressed with improved memory handling.
Versions affected: WebKitGTK before 2.26.1 and WPE WebKit before
+2.26.1.
+
Credit to Cheolung Lee of LINE+ Security Team.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: Multiple memory corruption
+issues were addressed with improved memory handling.
Versions affected: WebKitGTK before 2.26.1 and WPE WebKit before
+2.26.1.
+
Credit to Samuel Groß of Google Project Zero.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: Multiple memory corruption
+issues were addressed with improved memory handling.
Versions affected: WebKitGTK before 2.24.4 and WPE WebKit before
+2.24.3.
+
Credit to Sergei Glazunov of Google Project Zero.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: Multiple memory corruption
+issues were addressed with improved memory handling.
Versions affected: WebKitGTK before 2.24.4 and WPE WebKit before
+2.24.3.
+
Credit to Sergei Glazunov of Google Project Zero.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: Multiple memory corruption
+issues were addressed with improved memory handling.
Versions affected: WebKitGTK before 2.26.1 and WPE WebKit before
+2.26.1.
+
Credit to Sergei Glazunov of Google Project Zero.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: Multiple memory corruption
+issues were addressed with improved memory handling.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK before 2.26.3 and WPE WebKit before
+2.26.3.
+
Credit to Anonymous working with Trend Micro’s Zero Day Initiative,
+Mike Zhang of Pangu Team.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: Multiple memory corruption
+issues were addressed with improved memory handling.
Versions affected: WebKitGTK before 2.26.3 and WPE WebKit before
+2.26.3.
+
Credit to William Bowling (@wcbowling).
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: Multiple memory corruption
+issues were addressed with improved memory handling.
Versions affected: WebKitGTK before 2.26.3 and WPE WebKit before
+2.26.3.
+
Credit to Marcin Towalski of Cisco Talos.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A use after free issue was
+addressed with improved memory management.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK before 2.26.4 and WPE WebKit before
+2.26.4.
+
Credit to Srikanth Gatta of Google Chrome.
+
Impact: A malicious website may be able to cause a denial of
+service. Description: A denial of service issue was addressed with
+improved memory handling.
Versions affected: WebKitGTK before 2.26.4 and WPE WebKit before
+2.26.4.
+
Credit to Ryan Pickren (ryanpickren.com).
+
Impact: A top-level DOM object context may have incorrectly been
+considered secure. Description: A logic issue was addressed with
+improved validation.
Versions affected: WebKitGTK before 2.26.4 and WPE WebKit before
+2.26.4.
+
Credit to an anonymous researcher.
+
Impact: Processing maliciously crafted web content may lead to
+universal cross site scripting. Description: A logic issue was
+addressed with improved state management.
Versions affected: WebKitGTK before 2.26.4 and WPE WebKit before
+2.26.4.
+
Credit to Marcin Towalski of Cisco Talos.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: Multiple memory corruption
+issues were addressed with improved memory handling.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK before 2.28.0 and WPE WebKit before
+2.28.0.
+
Credit to Sudhakar Verma, Ashfaq Ansari & Siddhant Badhe - Project
+Srishti of CloudFuzz.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A memory corruption issue
+(use-after-free) was addressed with improved memory handling.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK before 2.28.1 and WPE WebKit before
+2.28.1.
+
Credit to Cim Stordal of Cognite.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution or application crash (denial of service).
+Description: A memory corruption issue (use-after-free) was
+addressed with improved memory handling.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK before 2.28.0 and WPE WebKit before
+2.28.0.
+
Credit to grigoritchy.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A memory corruption issue was
+addressed with improved memory handling.
Versions affected: WebKitGTK before 2.28.0 and WPE WebKit before
+2.28.0.
+
Credit to Brendan Draper (@6r3nd4n) working with Trend Micro’s Zero
+Day Initiative.
+
Impact: A remote attacker may be able to cause arbitrary code
+execution. Description: A type confusion issue was addressed with
+improved memory handling.
Versions affected: WebKitGTK before 2.28.2 and WPE WebKit before
+2.28.2.
+
Credit to OSS-Fuzz.
+
Impact: A remote attacker may be able to cause arbitrary code
+execution. Description: A memory consumption issue was addressed
+with improved memory handling.
Versions affected: WebKitGTK before 2.28.0 and WPE WebKit before
+2.28.0.
+
Credit to Dongzhuo Zhao working with ADLab of Venustech.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A memory corruption issue was
+addressed with improved memory handling.
Versions affected: WebKitGTK before 2.28.0 and WPE WebKit before
+2.28.0.
+
Credit to Benjamin Randazzo (@____benjamin).
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A type confusion issue was
+addressed with improved memory handling.
Versions affected: WebKitGTK before 2.28.0 and WPE WebKit before
+2.28.0.
+
Credit to Yiğit Can YILMAZ (@yilmazcanyigit).
+
Impact: Processing maliciously crafted web content may lead to a
+cross site scripting attack. Description: An input validation issue
+was addressed with improved input validation.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK before 2.28.3 and WPE WebKit before
+2.28.3.
+
Credit to Samuel Groß of Google Project Zero.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A logic issue was addressed
+with improved restrictions.
Versions affected: WebKitGTK before 2.28.3 and WPE WebKit before
+2.28.3.
+
Credit to Wen Xu of SSLab at Georgia Tech.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A memory corruption issue was
+addressed with improved validation.
Versions affected: WebKitGTK before 2.28.3 and WPE WebKit before
+2.28.3.
+
Credit to an anonymous researcher.
+
Impact: Processing maliciously crafted web content may lead to
+universal cross site scripting. Description: A logic issue was
+addressed with improved restrictions.
Versions affected: WebKitGTK before 2.28.3 and WPE WebKit before
+2.28.3.
+
Credit to Wen Xu of SSLab at Georgia Tech.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A memory corruption issue was
+addressed with improved state management.
Versions affected: WebKitGTK before 2.28.3 and WPE WebKit before
+2.28.3.
+
Credit to Wen Xu of SSLab at Georgia Tech.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A memory corruption issue was
+addressed with improved state management.
Versions affected: WebKitGTK before 2.28.3 and WPE WebKit before
+2.28.3.
+
Credit to Ryan Pickren (ryanpickren.com).
+
Impact: Processing maliciously crafted web content may lead to a
+cross site scripting attack. Description: An input validation issue
+was addressed with improved input validation.
Versions affected: WebKitGTK before 2.28.3 and WPE WebKit before
+2.28.3.
+
Credit to Milan Crha at Red Hat.
+
The bubblewrap sandbox of WebKitGTK and WPE WebKit, prior to 2.28.3,
+failed to properly block access to CLONE_NEWUSER and the TIOCSTI
+ioctl. CLONE_NEWUSER could potentially be used to confuse xdg-
+desktop-portal, which allows access outside the sandbox. TIOCSTI can
+be used to directly execute commands outside the sandbox by writing
+to the controlling terminal’s input buffer, similar to
+CVE-2017-5226.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK before 2.28.4 and WPE WebKit before
+2.28.4.
+
Credit to Ophir Lojkine (@lovasoa).
+
Impact: Copying a URL from Web Inspector may lead to command
+injection. Description: A command injection issue existed in Web
+Inspector. This issue was addressed with improved escaping.
Versions affected: WebKitGTK before 2.28.4 and WPE WebKit before
+2.28.4.
+
Credit to 0011 working with Trend Micro Zero Day Initiative.
+
Impact: A remote attacker may be able to cause unexpected
+application termination or arbitrary code execution. Description: An
+use-after-free issue was addressed with improved memory management.
Versions affected: WebKitGTK before 2.28.4 and WPE WebKit before
+2.28.4.
+
Credit to 0011 working with Trend Micro Zero Day Initiative.
+
Impact: A remote attacker may be able to cause unexpected
+application termination or arbitrary code execution. Description: An
+out-of-bounds read was addressed with improved input validation.
Versions affected: WebKitGTK before 2.28.4 and WPE WebKit before
+2.28.4.
+
Credit to Wen Xu of SSLab, Georgia Tech.
+
Impact: A remote attacker may be able to cause unexpected
+application termination or arbitrary code execution. Description: An
+use-after-free issue was addressed with improved memory management.
Versions affected: WebKitGTK before 2.28.4 and WPE WebKit before
+2.28.4.
+
Credit to Ayoub AIT ELMOKHTAR of Noon.
+
Impact: Processing maliciously crafted web content may prevent
+Content Security Policy from being enforced. Description: An access
+issue existed in Content Security Policy. This issue was addressed
+with improved access restrictions.
Versions affected: WebKitGTK before 2.28.4 and WPE WebKit before
+2.28.4.
+
Credit to an anonymous researcher.
+
Impact: Processing maliciously crafted web content may lead to
+universal cross site scripting. Description: A logic issue was
+addressed with improved state management.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK before 2.30.3 and WPE WebKit before
+2.30.3.
+
Credit to Marcin ‘Icewall’ Noga of Cisco Talos.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A use after free issue was
+addressed with improved memory management.
Versions affected: WebKitGTK before 2.30.0 and WPE WebKit before
+2.30.0.
+
Credit to Brendan Draper (@6r3nd4n) working with Trend Micro Zero
+Day Initiative.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A type confusion issue was
+addressed with improved memory handling.
Versions affected: WebKitGTK before 2.30.0 and WPE WebKit before
+2.30.0.
+
Credit to Marcin ‘Icewall’ Noga of Cisco Talos.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A use after free issue was
+addressed with improved memory management.
Versions affected: WebKitGTK before 2.28.3 and WPE WebKit before
+2.28.3.
+
Credit to Ryan Pickren (ryanpickren.com).
+
Impact: Processing maliciously crafted web content may lead to a
+cross site scripting attack. Description: An input validation issue
+was addressed with improved input validation.
Versions affected: WebKitGTK before 2.30.3 and WPE WebKit before
+2.30.3.
+
Credit to zhunki.
+
Impact: Processing maliciously crafted web content may lead to code
+execution. Description: An out-of-bounds write issue was addressed
+with improved bounds checking.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK before 2.30.3 and WPE WebKit before
+2.30.3.
+
Credit to Marcin ‘Icewall’ Noga of Cisco Talos.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A use after free issue was
+addressed with improved memory management.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK before 2.30.5 and WPE WebKit before
+2.30.5.
+
Credit to Marcin ‘Icewall’ Noga of Cisco Talos.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A use after free issue in
+the AudioSourceProviderGStreamer class was addressed with improved
+memory management.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK before 2.30.6 and WPE WebKit before
+2.30.6.
+
Credit to Liu Long of Ant Security Light-Year Lab.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A use after free issue was
+addressed with improved memory management.
Versions affected: WebKitGTK before 2.30.6 and WPE WebKit before
+2.30.6.
+
Credit to Simon Hunt of OvalTwo LTD.
+
Impact: A user may be unable to fully delete browsing history.
+Description: “Clear History and Website Data” did not clear the
+history in some circumstances. The issue was addressed with improved
+data deletion.
Versions affected: WebKitGTK before 2.30.0 and WPE WebKit before
+2.30.0.
+
Credit to cc working with Trend Micro Zero Day Initiative.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A use after free issue was
+addressed with improved memory management.
Versions affected: WebKitGTK before 2.30.6 and WPE WebKit before
+2.30.6.
+
Credit to Eliya Stein of Confiant.
+
Impact: Maliciously crafted web content may violate iframe
+sandboxing policy. Description: This issue was addressed with
+improved iframe sandbox enforcement.
Versions affected: WebKitGTK before 2.30.6 and WPE WebKit before
+2.30.6.
+
Credit to @S0rryMybad of 360 Vulcan Team.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A type confusion issue was
+addressed with improved state handling.
Versions affected: WebKitGTK before 2.30.6 and WPE WebKit before
+2.30.6.
+
Credit to Gregory Vishnepolsky & Ben Seri of Armis Security, and
+Samy Kamkar.
+
Impact: A malicious website may be able to access restricted ports
+on arbitrary servers, Description: A port redirection issue was
+addressed with additional port validation.
Versions affected: WebKitGTK before 2.30.6 and WPE WebKit before
+2.30.6.
+
Credit to Eliya Stein of Confiant.
+
Impact: Maliciously crafted web content may violate iframe
+sandboxing policy. Description: This issue was addressed with
+improved iframe sandbox enforcement.
Versions affected: WebKitGTK before 2.30.6 and WPE WebKit before
+2.30.6.
+
Credit to an anonymous researcher.
+
Impact: A remote attacker may be able to cause arbitrary code
+execution. Apple is aware of a report that this issue may have been
+actively exploited. Description: A logic issue was addressed with
+improved restrictions.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK before 2.32.0 and WPE WebKit before
+2.32.0.
+
Credit to Francisco Alonso (@revskills).
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A use after free issue was
+addressed with improved memory management.
Versions affected: WebKitGTK before 2.32.0 and WPE WebKit before
+2.32.0.
+
Credit to Clément Lecigne of Google’s Threat Analysis Group, Alison
+Huffman of Microsoft Browser Vulnerability Research.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A memory corruption issue was
+addressed with improved validation.
Versions affected: WebKitGTK before 2.32.0 and WPE WebKit before
+2.32.0.
+
Credit to an anonymous researcher.
+
Impact: A remote attacker may be able to cause arbitrary code
+execution. Apple is aware of a report that this issue may have been
+actively exploited. Description: A logic issue was addressed with
+improved restrictions.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK and WPE WebKit before 2.30.0.
+
Credit to zhunki.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A memory corruption issue was
+addressed with improved state management.
Versions affected: WebKitGTK and WPE WebKit before 2.30.0.
+
Credit to André Bargull.
+
Impact: Processing maliciously crafted web content may result in the
+disclosure of process memory. Description: A memory initialization
+issue was addressed with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.30.0.
+
Credit to Alex Camboe of Aon’s Cyber Solutions.
+
Impact: Processing maliciously crafted web content may lead to a
+cross site scripting attack. Description: An input validation issue
+was addressed with improved input validation.
Versions affected: WebKitGTK and WPE WebKit before 2.30.0.
+
Credit to an anonymous researcher.
+
Impact: Processing maliciously crafted web content may lead to
+universal cross site scripting. Description: A logic issue was
+addressed with improved restrictions.
Versions affected: WebKitGTK and WPE WebKit before 2.32.3.
+
Credit to Marcin Towalski of Cisco Talos.
+
A use-after-free vulnerability exists in the way certain events are
+processed for ImageLoader objects of WebKit. A specially crafted web
+page can lead to a potential information leak and further memory
+corruption. In order to trigger the vulnerability, a victim must be
+tricked into visiting a malicious webpage.
Versions affected: WebKitGTK and WPE WebKit before 2.32.3.
+
Credit to Marcin Towalski of Cisco Talos.
+
A use-after-free vulnerability exists in the way that WebKit
+GraphicsContext handles certain events. A specially crafted web page
+can lead to a potential information leak and further memory
+corruption. A victim must be tricked into visiting a malicious web
+page to trigger this vulnerability.
Versions affected: WebKitGTK and WPE WebKit before 2.30.6.
+
Credit to Marcin ‘Icewall’ Noga of Cisco Talos.
+
An exploitable use-after-free vulnerability exists in WebKit. A
+specially crafted HTML web page can cause a use-after-free
+condition, resulting in remote code execution. The victim needs to
+visit a malicious web site to trigger the vulnerability.
Versions affected: WebKitGTK and WPE WebKit before 2.30.0.
+
Credit to yangkang(@dnpushme) of 360 ATA.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Apple is aware of a report that this issue
+may have been actively exploited. Description: A use after free
+issue was addressed with improved memory management.
Versions affected: WebKitGTK and WPE WebKit before 2.32.3.
+
Credit to an anonymous researcher.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: An integer overflow was
+addressed with improved input validation.
Versions affected: WebKitGTK and WPE WebKit before 2.32.3.
+
Credit to yangkang (@dnpushme)&zerokeeper&bianliang of 360 ATA.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Apple is aware of a report that this issue
+may have been actively exploited. Description: A memory corruption
+issue was addressed with improved state management.
Versions affected: WebKitGTK and WPE WebKit before 2.26.0.
+
Credit to yangkang (@dnpushme)&zerokeeper&bianliang of 360 ATA.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Apple is aware of a report that this issue
+may have been actively exploited. Description: A buffer overflow
+issue was addressed with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.32.3.
+
Credit to an anonymous researcher.
+
Impact: Processing maliciously crafted web content may lead to
+universal cross site scripting. Description: A logic issue was
+addressed with improved state management.
Versions affected: WebKitGTK and WPE WebKit before 2.32.3.
+
Credit to David Schütz (@xdavidhu).
+
Impact: A malicious website may be able to access restricted ports
+on arbitrary servers. Description: A logic issue was addressed with
+improved restrictions.
Versions affected: WebKitGTK and WPE WebKit before 2.32.3.
+
Credit to Jack Dates of RET2 Systems, Inc. (@ret2systems) working
+with Trend Micro Zero Day Initiative.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: Multiple memory corruption
+issues were addressed with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.32.3.
+
Credit to Dan Hite of jsontop.
+
Impact: Processing maliciously crafted web content may lead to
+universal cross site scripting. Description: A cross-origin issue
+with iframe elements was addressed with improved tracking of
+security origins.
Versions affected: WebKitGTK and WPE WebKit before 2.32.3.
+
Credit to an anonymous researcher and mipu94 of SEFCOM lab, ASU.
+working with Trend Micro Zero Day Initiative.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: Multiple memory corruption
+issues were addressed with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.32.2.
+
Credit to Christoph Guttandin of Media Codings.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A type confusion issue was
+addressed with improved state handling.
Versions affected: WebKitGTK and WPE WebKit before 2.26.0.
+
Credit to an anonymous researcher.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Apple is aware of a report that this issue
+may have been actively exploited. Description: A memory corruption
+issue was addressed with improved state management.
Versions affected: WebKitGTK and WPE WebKit before 2.28.0.
+
Credit to an anonymous researcher.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Apple is aware of a report that this issue
+may have been actively exploited. Description: A use after free
+issue was addressed with improved memory management.
Versions affected: WebKitGTK and WPE WebKit before 2.32.3.
+
Credit to Sergei Glazunov of Google Project Zero.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A use after free issue was
+addressed with improved memory management.
Versions affected: WebKitGTK and WPE WebKit before 2.32.3.
+
Credit to Sergei Glazunov of Google Project Zero.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: Multiple memory corruption
+issues were addressed with improved memory handling.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK and WPE WebKit before 2.32.4.
+
Credit to an anonymous researcher.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Apple is aware of a report that this issue
+may have been actively exploited. Description: A use after free
+issue was addressed with improved memory management.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK and WPE WebKit before 2.34.0.
+
Credit to Sergei Glazunov of Google Project Zero.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A memory corruption issue was
+addressed with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.32.4.
+
Credit to Sergei Glazunov of Google Project Zero.
+
Impact: Processing maliciously crafted web content may lead to code
+execution. Description: A memory corruption issue was addressed with
+improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.32.4.
+
Credit to Sergei Glazunov of Google Project Zero.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: Multiple memory corruption
+issues were addressed with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.34.0.
+
Credit to Samuel Groß of Google Project Zero.
+
Impact: Processing maliciously crafted web content may lead to code
+execution. Description: A memory corruption vulnerability was
+addressed with improved locking.
Versions affected: WebKitGTK and WPE WebKit before 2.32.4.
+
Credit to an anonymous researcher.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Apple is aware of a report that this issue
+may have been actively exploited. Description: A use after free
+issue was addressed with improved memory management.
Versions affected: WebKitGTK and WPE WebKit before 2.34.1.
+
Credit to an anonymous reporter.
+
BubblewrapLauncher.cpp allows a limited sandbox bypass that allows a
+sandboxed process to trick host processes into thinking the
+sandboxed process is not confined by the sandbox, by abusing VFS
+syscalls that manipulate its filesystem namespace. The impact is
+limited to host services that create UNIX sockets that WebKit mounts
+inside its sandbox, and the sandboxed process remains otherwise
+confined. NOTE: this is similar to CVE-2021-41133.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK and WPE WebKit before 2.32.4.
+
Credit to an anonymous researcher.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A use after free issue was
+addressed with improved memory management.
Versions affected: WebKitGTK and WPE WebKit before 2.34.0.
+
Credit to Amar Menezes (@amarekano) of Zon8Research.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A type confusion issue was
+addressed with improved state handling.
Versions affected: WebKitGTK and WPE WebKit before 2.34.0.
+
Credit to David Gullasch of Recurity Labs.
+
Impact: An attacker in a privileged network position may be able to
+bypass HSTS. Description: A logic issue was addressed with improved
+restrictions.
Versions affected: WebKitGTK and WPE WebKit before 2.34.0.
+
Credit to an anonymous researcher.
+
Impact: Visiting a maliciously crafted website may reveal a user’s
+browsing history. Description: The issue was resolved with
+additional restrictions on CSS compositing.
Versions affected: WebKitGTK and WPE WebKit before 2.34.3.
+
Credit to Narendra Bhati (@imnarendrabhati) of Suma Soft Pvt. Ltd.
+
Impact: Processing maliciously crafted web content may lead to
+unexpectedly unenforced Content Security Policy. Description: A
+logic issue was addressed with improved restrictions.
Versions affected: WebKitGTK and WPE WebKit before 2.34.0.
+
Credit to Prakash (@1lastBr3ath).
+
Impact: A malicious website using Content Security Policy reports
+may be able to leak information via redirect behavior. Description:
+An information leakage issue was addressed.
Versions affected: WebKitGTK and WPE WebKit before 2.34.0.
+
Credit to Chijin Zhou of ShuiMuYuLin Ltd and Tsinghua wingtecher
+lab.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution, Description: A buffer overflow issue was
+addressed with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.34.3.
+
Credit to an anonymous researcher.
+
Impact: Processing maliciously crafted web content may lead to
+universal cross site scripting. Description: A logic issue was
+addressed with improved state management.
Versions affected: WebKitGTK and WPE WebKit before 2.34.0.
+
Credit to an anonymous researcher.
+
Impact: A malicious website may exfiltrate data cross-origin.
+Description: An issue existed in the specification for the resource
+timing API. The specification was updated and the updated
+specification was implemented.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK and WPE WebKit before 2.34.4.
+
Credit to Dani Biro.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A buffer overflow issue was
+addressed with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.34.4.
+
Credit to Chijin Zhou of ShuiMuYuLin Ltd and Tsinghua wingtecher
+lab.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A use after free issue was
+addressed with improved memory management.
Versions affected: WebKitGTK and WPE WebKit before 2.34.4.
+
Credit to Pangu.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A use after free issue was
+addressed with improved memory management.
Versions affected: WebKitGTK and WPE WebKit before 2.34.4.
+
Credit to WeBin.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: An integer overflow was
+addressed with improved input validation.
Versions affected: WebKitGTK and WPE WebKit before 2.34.4.
+
Credit to VRIJ.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: An out-of-bounds read was
+addressed with improved bounds checking.
Versions affected: WebKitGTK and WPE WebKit before 2.34.4.
+
Credit to Kunlun Lab.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A type confusion issue was
+addressed with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.34.4.
+
Credit to Kunlun Lab.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A race condition was
+addressed with improved state handling.
Versions affected: WebKitGTK and WPE WebKit before 2.34.4.
+
Credit to Martin Bajanik of fingerprintjs.com.
+
Impact: A website may be able to track sensitive user information.
+Description: A cross-origin issue in the IndexDB API was addressed
+with improved input validation. Notes: There is a public PoC
+demonstrating this issue at safarileaks.com so it may have been
+actively exploited.
Versions affected: WebKitGTK and WPE WebKit before 2.34.0.
+
Credit to Chijin Zhou of ShuiMuYuLin Ltd and Tsinghua wingtecher
+lab.
+
Processing maliciously crafted web content may cause an application
+crash due to an incorrect memory allocation in
+WebCore::ImageBufferCairoImageSurfaceBackend::create.
Versions affected: WebKitGTK and WPE WebKit before 2.34.0.
+
Credit to Chijin Zhou of ShuiMuYuLin Ltd and Tsinghua wingtecher
+lab.
+
Processing maliciously crafted web content may cause a memory
+corruption issue (heap-use-after-free) in WebCore::Frame::page.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK and WPE WebKit before 2.34.5.
+
Credit to Heige of KnownSec 404 Team (knownsec.com) and Bo Qu of
+Palo Alto Networks (paloaltonetworks.com).
+
Impact: Processing a maliciously crafted mail message may lead to
+running arbitrary javascript. Description: A validation issue was
+addressed with improved input sanitization.
Versions affected: WebKitGTK and WPE WebKit before 2.34.5.
+
Credit to Toan Pham from Team Orca of Sea Security
+(security.sea.com).
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A use after free issue was
+addressed with improved memory management.
Versions affected: WebKitGTK and WPE WebKit before 2.34.5.
+
Credit to Prakash (@1lastBr3ath).
+
Impact: Processing maliciously crafted web content may prevent
+Content Security Policy from being enforced. Description: A logic
+issue was addressed with improved state management.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK and WPE WebKit before 2.34.6.
+
Credit to an anonymous researcher.
+
Impact: processing maliciously crafted web content may lead to
+arbitrary code execution. Apple is aware of a report that this issue
+may have been actively exploited. Description: A use after free
+issue was addressed with improved memory management.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK before 2.36.0 and WPE WebKit before
+2.34.7.
+
Credit to Kirin (@Pwnrin) of Tencent Security Xuanwu Lab.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A use after free issue was
+addressed with improved memory management.
Versions affected: WebKitGTK before 2.36.0 and WPE WebKit before
+2.34.7.
+
Credit to Kirin (@Pwnrin) of Tencent Security Xuanwu Lab.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A use after free issue was
+addressed with improved memory management.
Versions affected: WebKitGTK before 2.36.0 and WPE WebKit before
+2.34.7.
+
Credit to Jeonghoon Shin at Theori working with Trend Micro Zero Day
+Initiative.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A buffer overflow issue was
+addressed with improved memory handling.
Versions affected: WebKitGTK before 2.34.4 and WPE WebKit before
+2.34.4.
+
Credit to Tom McKee of Google.
+
Impact: A malicious website may cause unexpected cross-origin
+behavior. Description: A logic issue was addressed with improved
+state management.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK and WPE WebKit before 2.36.3.
+
Credit to ryuzaki.
+
Impact: Processing maliciously crafted web content may lead to code
+execution. Description: A memory corruption issue was addressed with
+improved state management.
Versions affected: WebKitGTK and WPE WebKit before 2.36.3.
+
Credit to Chijin Zhou of ShuiMuYuLin Ltd and Tsinghua wingtecher
+lab.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A use after free issue was
+addressed with improved memory management.
Versions affected: WebKitGTK and WPE WebKit before 2.36.3.
+
Credit to Jeonghoon Shin of Theori.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A use after free issue was
+addressed with improved memory management.
Versions affected: WebKitGTK and WPE WebKit before 2.36.3.
+
Credit to SorryMybad (@S0rryMybad) of Kunlun Lab.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A memory corruption issue was
+addressed with improved state management.
Versions affected: WebKitGTK and WPE WebKit before 2.36.3.
+
Credit to Dongzhuo Zhao working with ADLab of Venustech.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A memory corruption issue was
+addressed with improved state management.
Versions affected: WebKitGTK and WPE WebKit before 2.36.1.
+
Credit to Chijin Zhou of ShuiMuYuLin Ltd and Tsinghua wingtecher
+lab.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution or to a denial of service (application
+crash). Description: A memory corruption issue that could cause a
+heap use after free or a heap buffer overflow in
+WebCore::TextureMapperLayer::setContentsLayer was addressed with
+improved state management.
Versions affected: WebKitGTK and WPE WebKit before 2.36.1.
+
Credit to Chijin Zhou of ShuiMuYuLin Ltd and Tsinghua wingtecher
+lab.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution or to a denial of service (application
+crash). Description: A memory corruption issue that could cause a
+heap use after free or a heap buffer overflow in
+WebCore::TextureMapperLayer::setContentsLayer was addressed with
+improved state management. This is the same issue than
+CVE-2022-30293.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK and WPE WebKit before 2.36.0.
+
Credit to Prakash (@1lastBr3ath) of Threat Nix.
+
Impact: Processing maliciously crafted web content may disclose
+sensitive user information. Description: A cookie management issue
+was addressed with improved state management.
Versions affected: WebKitGTK and WPE WebKit before 2.36.4.
+
Credit to an anonymous researcher.
+
Impact: The video in a webRTC call may be interrupted if the audio
+capture gets interrupted. Description: A logic issue in the handling
+of concurrent media was addressed with improved state handling.
Versions affected: WebKitGTK and WPE WebKit before 2.36.4.
+
Credit to Chijin Zhou of ShuiMuYuLin Ltd and Tsinghua wingtecher
+lab.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A use after free issue was
+addressed with improved memory management.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK and WPE WebKit before 2.36.5.
+
Credit to Manfred Paul (@_manfp) working with Trend Micro Zero Day
+Initiative.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: An out-of-bounds write issue
+was addressed with improved input validation.
Versions affected: WebKitGTK and WPE WebKit before 2.36.5 if
+USE_LIBWEBRTC is enabled.
+
Credit to Jan Vojtesek of Avast Threat Intelligence team.
+
Heap buffer overflow in LibWebRTC allowed a remote attacker to
+potentially exploit heap corruption via a crafted HTML page. NOTE:
+The tarballs of WebKitGTK or WPE WebKit don’t ship LibWebRTC. Also
+the LibWebRTC support is disabled by default. You only are affected
+by this vulnerability if your build enabled the USE_LIBWEBRTC CMake
+option and used the repository as source instead of the tarballs.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK and WPE WebKit before 2.36.7.
+
Credit to an anonymous researcher.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Apple is aware of a report that this issue
+may have been actively exploited.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK and WPE WebKit before 2.36.8.
+
Credit to P1umer, afang5472, xmzyshypnc.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A buffer overflow issue was
+addressed with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.36.8.
+
Credit to Jeonghoon Shin (@singi21a) at Theori working with Trend
+Micro Zero Day Initiative.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: An out-of-bounds read was
+addressed with improved bounds checking. This issue only affects
+MacOS builds (Linux builds are not affected).
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK and WPE WebKit before 2.38.0.
+
Credit to P1umer (@p1umer).
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: An out-of-bounds write issue
+was addressed with improved bounds checking.
Versions affected: WebKitGTK and WPE WebKit before 2.38.0.
+
Credit to Wonyoung Jung (@nonetype_pwn) of KAIST Hacking Lab.
+
Impact: Processing maliciously crafted web content may disclose
+internal states of the app. Description: A correctness issue in the
+JIT was addressed with improved checks.
Versions affected: WebKitGTK and WPE WebKit before 2.38.2.
+
Credit to Dohyun Lee (@l33d0hyun) of SSD Labs.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A type confusion issue was
+addressed with improved memory handling.
Credit to Abdulrahman Alqabandi of Microsoft Browser Vulnerability
+Research, Ryan Shin of IAAI SecLab at Korea University, Dohyun Lee
+(@l33d0hyun) of DNSLab at Korea University.
+
Impact: Processing maliciously crafted web content may disclose
+sensitive user information. Description: A logic issue was addressed
+with improved state management.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK and WPE WebKit before 2.38.3.
+
Credit to hazbinhotel working with Trend Micro Zero Day Initiative.
+
Impact: Processing maliciously crafted web content may result in the
+disclosure of process memory. Description: The issue was addressed
+with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.38.3.
+
Credit to Clément Lecigne of Google’s Threat Analysis Group.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A type confusion issue was
+addressed with improved state handling.
Versions affected: WebKitGTK and WPE WebKit before 2.38.0.
+
Credit to an anonymous researcher.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A memory corruption issue was
+addressed with improved state management.
Versions affected: WebKitGTK and WPE WebKit before 2.38.3.
+
Credit to Maddie Stone of Google Project Zero.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A use after free issue was
+addressed with improved memory management.
Versions affected: WebKitGTK and WPE WebKit before 2.38.1.
+
Credit to an anonymous researcher.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A memory consumption issue
+was addressed with improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.38.3.
+
Credit to KirtiKumar Anandrao Ramchandani.
+
Impact: Processing maliciously crafted web content may bypass Same
+Origin Policy. Description: A logic issue was addressed with
+improved state management.
Versions affected: WebKitGTK and WPE WebKit before 2.38.3.
+
Credit to Dohyun Lee (@l33d0hyun) of DNSLab at Korea University,
+Ryan Shin of IAAI SecLab at Korea University.
+
Impact: Processing maliciously crafted web content may disclose
+sensitive user information. Description: A logic issue was addressed
+with improved checks.
Versions affected: WebKitGTK and WPE WebKit before 2.38.3.
+
Credit to Samuel Groß of Google V8 Security.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A memory corruption issue was
+addressed with improved state management.
Versions affected: WebKitGTK and WPE WebKit before 2.38.3.
+
Credit to Samuel Groß of Google V8 Security.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A memory corruption issue was
+addressed with improved input validation.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK and WPE WebKit before 2.38.4.
+
Credit to YeongHyeon Choi (@hyeon101010), Hyeon Park
+(@tree_segment), SeOk JEON (@_seokjeon), YoungSung Ahn (@_ZeroSung),
+JunSeo Bae (@snakebjs0107), Dohyun Lee (@l33d0hyun) of Team
+ApplePIE.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: The issue was addressed with
+improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.38.4.
+
Credit to YeongHyeon Choi (@hyeon101010), Hyeon Park
+(@tree_segment), SeOk JEON (@_seokjeon), YoungSung Ahn (@_ZeroSung),
+JunSeo Bae (@snakebjs0107), Dohyun Lee (@l33d0hyun) of Team
+ApplePIE.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: The issue was addressed with
+improved memory handling.
Versions affected: WebKitGTK and WPE WebKit before 2.38.4.
+
Credit to Francisco Alonso (@revskills).
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A use after free issue was
+addressed with improved memory management.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK and WPE WebKit before 2.38.5.
+
Credit to an anonymous researcher.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Apple is aware of a report that this issue
+may have been actively exploited. Description: A type confusion
+issue was addressed with improved checks.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK and WPE WebKit before 2.36.8.
+
Credit to Chijin Zhou of ShuiMuYuLin Ltd and Tsinghua wingtecher
+lab.
+
A use-after-free vulnerability exists in WebCore::RenderLayer. This
+issue allows remote attackers to execute arbitrary code or cause a
+denial of service (memory corruption and application crash) via a
+crafted web site. This is the same issue as CVE-2023-25360,
+CVE-2023-25361, CVE-2023-25362 and CVE-2023-25363.
Versions affected: WebKitGTK and WPE WebKit before 2.38.6 and 2.40
+branch before 2.40.1.
+
Credit to Luan Herrera (@lbherrera_).
+
Impact: An HTML document may be able to render iframes with
+sensitive user information. Description: This issue was addressed
+with improved iframe sandbox enforcement.
Versions affected: WebKitGTK and WPE WebKit before 2.38.6 and 2.40
+branch before 2.40.1.
+
Credit to P1umer(@p1umer) and Q1IQ(@q1iqF).
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Description: A memory corruption issue was
+addressed with improved validation.
Versions affected: WebKitGTK and WPE WebKit before 2.38.6 and 2.40
+branch before 2.40.1.
+
Credit to an anonymous researcher.
+
Impact: Processing maliciously crafted web content may bypass Same
+Origin Policy. Description: This issue was addressed with improved
+state management.
Versions affected: WebKitGTK and WPE WebKit before 2.38.6 and 2.40
+branch before 2.40.1.
+
Credit to Clément Lecigne of Google’s Threat Analysis Group and
+Donncha Ó Cearbhaill of Amnesty International’s Security Lab.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Apple is aware of a report that this issue
+may have been actively exploited. Description: A use after free
+issue was addressed with improved memory management.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK and WPE WebKit before 2.40.2.
+
Credit to an anonymous researcher.
+
Impact: Processing web content may disclose sensitive information.
+Apple is aware of a report that this issue may have been actively
+exploited. Description: An out-of-bounds read was addressed with
+improved input validation.
Versions affected: WebKitGTK and WPE WebKit before 2.40.2.
+
Credit to an anonymous researcher.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Apple is aware of a report that this issue
+may have been actively exploited. Description: A use-after-free
+issue was addressed with improved memory management.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK and WPE WebKit before 2.40.0.
+
Credit to Georgy Kucherin (@kucher1n), Leonid Bezvershenko (@bzvr_),
+and Boris Larin (@oct0xor) of Kaspersky.
+
Impact: Processing web content may lead to arbitrary code execution.
+Apple is aware of a report that this issue may have been actively
+exploited. Description: A memory corruption issue was addressed with
+improved state management.
Versions affected: WebKitGTK and WPE WebKit before 2.40.3.
+
Credit to an anonymous researcher.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Apple is aware of a report that this issue
+may have been actively exploited. Description: A type confusion
+issue was addressed with improved checks.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK and WPE WebKit before 2.40.4.
+
Credit to an anonymous researcher.
+
Impact: Processing web content may lead to arbitrary code execution.
+Apple is aware of a report that this issue may have been actively
+exploited. Description: The issue was addressed with improved
+checks.
Versions affected: WebKitGTK and WPE WebKit before 2.40.0.
+
Credit to Francisco Alonso (@revskills).
+
Impact: Processing web content may lead to arbitrary code execution.
+Description: The issue was addressed with improved memory handling.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK and WPE WebKit before 2.40.5.
+
Credit to Narendra Bhati (twitter.com/imnarendrabhati) of Suma Soft
+Pvt. Ltd, Pune - India, Valentino Dalla Valle, Pedro Bernardo, Marco
+Squarcina, and Lorenzo Veronese of TU Wien.
+
Impact: Processing web content may lead to arbitrary code execution.
+Description: A logic issue was addressed with improved restrictions.
Versions affected: WebKitGTK and WPE WebKit before 2.40.5.
+
Credit to Francisco Alonso (@revskills).
+
Impact: Processing web content may lead to arbitrary code execution.
+Description: The issue was addressed with improved memory handling.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK and WPE WebKit before 2.40.1.
+
Credit to hazbinhotel working with Trend Micro Zero Day Initiative.
+
Impact: Processing web content may lead to arbitrary code execution.
+Description: A use-after-free issue was addressed with improved
+memory management.
Versions affected: WebKitGTK and WPE WebKit before 2.40.5.
+
Credit to Johan Carlsson (joaxcar).
+
Impact: A remote attacker may be able to cause arbitrary javascript
+code execution. Description: The issue was addressed with improved
+checks.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK and WPE WebKit before 2.42.0.
+
Credit to Marcin ‘Icewall’ Noga of Cisco Talos.
+
A use-after-free vulnerability exists in the MediaRecorder API of
+the WebKit GStreamer-based ports (WebKitGTK and WPE WebKit). A
+specially crafted web page can abuse this vulnerability to cause
+memory corruption and potentially arbitrary code execution. A user
+would need to to visit a malicious webpage to trigger this
+vulnerability. WebKit Bugzilla: 260649.
Versions affected: WebKitGTK and WPE WebKit before 2.40.5.
+
Credit to Francisco Alonso (@revskills), and Dohyun Lee (@l33d0hyun)
+of PK Security.
+
Impact: Processing web content may lead to arbitrary code execution.
+Description: A use-after-free issue was addressed with improved
+memory management.
Versions affected: WebKitGTK and WPE WebKit before 2.40.5.
+
Credit to an anonymous researcher.
+
Impact: An attacker with JavaScript execution may be able to execute
+arbitrary code. Description: This issue was addressed with improved
+iframe sandbox enforcement.
Versions affected: WebKitGTK and WPE WebKit before 2.42.1.
+
Credit to Bill Marczak of The Citizen Lab at The University of
+Toronto’s Munk School and Maddie Stone of Google’s Threat Analysis
+Group.
+
Impact: Processing web content may lead to arbitrary code execution.
+Apple is aware of a report that this issue may have been actively
+exploited. Description: The issue was addressed with improved
+checks.
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK and WPE WebKit before 2.38.0.
+
Credit to Binoy Chitale, MS student, Stony Brook University, Nick
+Nikiforakis, Associate Professor, Stony Brook University, Jason
+Polakis, Associate Professor, University of Illinois at Chicago, Mir
+Masood Ali, PhD student, University of Illinois at Chicago, Chris
+Kanich, Associate Professor, University of Illinois at Chicago, and
+Mohammad Ghasemisharif, PhD Candidate, University of Illinois at
+Chicago.
+
Impact: A website may be able to track the websites a user visited
+in private browsing mode. Description: An information disclosure
+issue was addressed by removing the vulnerable code.
Versions affected: WebKitGTK and WPE WebKit before 2.38.4.
+
Credit to Hyeon Park (@tree_segment) of Team ApplePIE.
+
Impact: Visiting a malicious website may lead to address bar
+spoofing. Description: A spoofing issue existed in the handling of
+URLs. This issue was addressed with improved input validation.
Versions affected: WebKitGTK and WPE WebKit before 2.38.4.
+
Credit to Hyeon Park (@tree_segment) of Team ApplePIE.
+
Impact: Visiting a malicious website may lead to address bar
+spoofing. Description: A spoofing issue existed in the handling of
+URLs. This issue was addressed with improved input validation.
Versions affected: WebKitGTK and WPE WebKit before 2.42.0.
+
Credit to Claire Houston.
+
Impact: A user’s password may be read aloud by a text-to-speech
+accessibility feature. Description: This issue was addressed with
+improved redaction of sensitive information.
Versions affected: WebKitGTK and WPE WebKit before 2.42.2.
+
Credit to Pedro Ribeiro (@pedrib1337) and Vitor Pedreira (@0xvhp_) of Agile Information Security.
+
Impact: Processing web content may lead to arbitrary code execution.
+Description: A logic issue was addressed with improved checks.
+
WebKit Bugzilla: 260173
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK and WPE WebKit before 2.42.3.
+
Credit to Clément Lecigne of Google’s Threat Analysis Group.
+
Impact: Processing web content may disclose sensitive information.
+Apple is aware of a report that this issue may have been actively
+exploited. Description: An out-of-bounds read was addressed with
+improved input validation.
Versions affected: WebKitGTK and WPE WebKit before 2.42.3.
+
Credit to Clément Lecigne of Google’s Threat Analysis Group.
+
Impact: Processing web content may lead to arbitrary code execution.
+Apple is aware of a report that this issue may have been actively
+exploited. Description: A memory corruption vulnerability was
+addressed with improved locking.
+
WebKit Bugzilla: 265067
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK and WPE WebKit before 2.42.0.
+
Credit to Pwn2car.
+
Impact: Processing web content may lead to arbitrary code execution.
+Description: The issue was addressed with improved memory handling.
+
WebKit Bugzilla: 259830
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
Versions affected: WebKitGTK and WPE WebKit before 2.42.5.
+
Credit to Apple.
+
Impact: Processing maliciously crafted web content may lead to
+arbitrary code execution. Apple is aware of a report that this issue
+may have been exploited. Description: A type confusion issue was
+addressed with improved checks.
Versions affected: WebKitGTK and WPE WebKit before 2.42.5.
+
Credit to An anonymous researcher.
+
Impact: A maliciously crafted webpage may be able to fingerprint the
+user. Description: An access issue was addressed with improved
+access restrictions.
Versions affected: WebKitGTK and WPE WebKit before 2.42.1.
+
Credit to Francisco Alonso (@revskills).
+
Impact: Processing web content may lead to arbitrary code execution.
+Description: A use-after-free issue was addressed with improved
+memory management.
Versions affected: WebKitGTK and WPE WebKit before 2.42.0.
+
Credit to An anonymous researcher.
+
Impact: Processing a file may lead to a denial-of-service or
+potentially disclose memory contents. Description: The issue was
+addressed with improved checks.
+
WebKit Bugzilla: 249434
+
+
+
+
We recommend updating to the latest stable versions of WebKitGTK and WPE
+WebKit. It is the best way to ensure that you are running safe versions
+of WebKit. Please check our websites for information about the latest
+stable releases.
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
+ If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!
+
` elements.\n\nbody {\n margin: 0; // 1\n font-family: $font-family-base;\n @include font-size($font-size-base);\n font-weight: $font-weight-base;\n line-height: $line-height-base;\n color: $body-color;\n text-align: left; // 3\n background-color: $body-bg; // 2\n}\n\n// Future-proof rule: in browsers that support :focus-visible, suppress the focus outline\n// on elements that programmatically receive focus but wouldn't normally show a visible\n// focus outline. In general, this would mean that the outline is only applied if the\n// interaction that led to the element receiving programmatic focus was a keyboard interaction,\n// or the browser has somehow determined that the user is primarily a keyboard user and/or\n// wants focus outlines to always be presented.\n//\n// See https://developer.mozilla.org/en-US/docs/Web/CSS/:focus-visible\n// and https://developer.paciellogroup.com/blog/2018/03/focus-visible-and-backwards-compatibility/\n[tabindex=\"-1\"]:focus:not(:focus-visible) {\n outline: 0 !important;\n}\n\n\n// Content grouping\n//\n// 1. Add the correct box sizing in Firefox.\n// 2. Show the overflow in Edge and IE.\n\nhr {\n box-sizing: content-box; // 1\n height: 0; // 1\n overflow: visible; // 2\n}\n\n\n//\n// Typography\n//\n\n// Remove top margins from headings\n//\n// By default, `
`-`
` all receive top and bottom margins. We nuke the top\n// margin for easier control within type scales as it avoids margin collapsing.\n// stylelint-disable-next-line selector-list-comma-newline-after\nh1, h2, h3, h4, h5, h6 {\n margin-top: 0;\n margin-bottom: $headings-margin-bottom;\n}\n\n// Reset margins on paragraphs\n//\n// Similarly, the top margin on `
`s get reset. However, we also reset the\n// bottom margin to use `rem` units instead of `em`.\np {\n margin-top: 0;\n margin-bottom: $paragraph-margin-bottom;\n}\n\n// Abbreviations\n//\n// 1. Duplicate behavior to the data-* attribute for our tooltip plugin\n// 2. Add the correct text decoration in Chrome, Edge, IE, Opera, and Safari.\n// 3. Add explicit cursor to indicate changed behavior.\n// 4. Remove the bottom border in Firefox 39-.\n// 5. Prevent the text-decoration to be skipped.\n\nabbr[title],\nabbr[data-original-title] { // 1\n text-decoration: underline; // 2\n text-decoration: underline dotted; // 2\n cursor: help; // 3\n border-bottom: 0; // 4\n text-decoration-skip-ink: none; // 5\n}\n\naddress {\n margin-bottom: 1rem;\n font-style: normal;\n line-height: inherit;\n}\n\nol,\nul,\ndl {\n margin-top: 0;\n margin-bottom: 1rem;\n}\n\nol ol,\nul ul,\nol ul,\nul ol {\n margin-bottom: 0;\n}\n\ndt {\n font-weight: $dt-font-weight;\n}\n\ndd {\n margin-bottom: .5rem;\n margin-left: 0; // Undo browser default\n}\n\nblockquote {\n margin: 0 0 1rem;\n}\n\nb,\nstrong {\n font-weight: $font-weight-bolder; // Add the correct font weight in Chrome, Edge, and Safari\n}\n\nsmall {\n @include font-size(80%); // Add the correct font size in all browsers\n}\n\n//\n// Prevent `sub` and `sup` elements from affecting the line height in\n// all browsers.\n//\n\nsub,\nsup {\n position: relative;\n @include font-size(75%);\n line-height: 0;\n vertical-align: baseline;\n}\n\nsub { bottom: -.25em; }\nsup { top: -.5em; }\n\n\n//\n// Links\n//\n\na {\n color: $link-color;\n text-decoration: $link-decoration;\n background-color: transparent; // Remove the gray background on active links in IE 10.\n\n @include hover() {\n color: $link-hover-color;\n text-decoration: $link-hover-decoration;\n }\n}\n\n// And undo these styles for placeholder links/named anchors (without href).\n// It would be more straightforward to just use a[href] in previous block, but that\n// causes specificity issues in many other styles that are too complex to fix.\n// See https://github.com/twbs/bootstrap/issues/19402\n\na:not([href]) {\n color: inherit;\n text-decoration: none;\n\n @include hover() {\n color: inherit;\n text-decoration: none;\n }\n}\n\n\n//\n// Code\n//\n\npre,\ncode,\nkbd,\nsamp {\n font-family: $font-family-monospace;\n @include font-size(1em); // Correct the odd `em` font sizing in all browsers.\n}\n\npre {\n // Remove browser default top margin\n margin-top: 0;\n // Reset browser default of `1em` to use `rem`s\n margin-bottom: 1rem;\n // Don't allow content to break outside\n overflow: auto;\n}\n\n\n//\n// Figures\n//\n\nfigure {\n // Apply a consistent margin strategy (matches our type styles).\n margin: 0 0 1rem;\n}\n\n\n//\n// Images and content\n//\n\nimg {\n vertical-align: middle;\n border-style: none; // Remove the border on images inside links in IE 10-.\n}\n\nsvg {\n // Workaround for the SVG overflow bug in IE10/11 is still required.\n // See https://github.com/twbs/bootstrap/issues/26878\n overflow: hidden;\n vertical-align: middle;\n}\n\n\n//\n// Tables\n//\n\ntable {\n border-collapse: collapse; // Prevent double borders\n}\n\ncaption {\n padding-top: $table-cell-padding;\n padding-bottom: $table-cell-padding;\n color: $table-caption-color;\n text-align: left;\n caption-side: bottom;\n}\n\nth {\n // Matches default `
` alignment by inheriting from the ``, or the\n // closest parent with a set `text-align`.\n text-align: inherit;\n}\n\n\n//\n// Forms\n//\n\nlabel {\n // Allow labels to use `margin` for spacing.\n display: inline-block;\n margin-bottom: $label-margin-bottom;\n}\n\n// Remove the default `border-radius` that macOS Chrome adds.\n//\n// Details at https://github.com/twbs/bootstrap/issues/24093\nbutton {\n // stylelint-disable-next-line property-blacklist\n border-radius: 0;\n}\n\n// Work around a Firefox/IE bug where the transparent `button` background\n// results in a loss of the default `button` focus styles.\n//\n// Credit: https://github.com/suitcss/base/\nbutton:focus {\n outline: 1px dotted;\n outline: 5px auto -webkit-focus-ring-color;\n}\n\ninput,\nbutton,\nselect,\noptgroup,\ntextarea {\n margin: 0; // Remove the margin in Firefox and Safari\n font-family: inherit;\n @include font-size(inherit);\n line-height: inherit;\n}\n\nbutton,\ninput {\n overflow: visible; // Show the overflow in Edge\n}\n\nbutton,\nselect {\n text-transform: none; // Remove the inheritance of text transform in Firefox\n}\n\n// Remove the inheritance of word-wrap in Safari.\n//\n// Details at https://github.com/twbs/bootstrap/issues/24990\nselect {\n word-wrap: normal;\n}\n\n\n// 1. Prevent a WebKit bug where (2) destroys native `audio` and `video`\n// controls in Android 4.\n// 2. Correct the inability to style clickable types in iOS and Safari.\nbutton,\n[type=\"button\"], // 1\n[type=\"reset\"],\n[type=\"submit\"] {\n -webkit-appearance: button; // 2\n}\n\n// Opinionated: add \"hand\" cursor to non-disabled button elements.\n@if $enable-pointer-cursor-for-buttons {\n button,\n [type=\"button\"],\n [type=\"reset\"],\n [type=\"submit\"] {\n &:not(:disabled) {\n cursor: pointer;\n }\n }\n}\n\n// Remove inner border and padding from Firefox, but don't restore the outline like Normalize.\nbutton::-moz-focus-inner,\n[type=\"button\"]::-moz-focus-inner,\n[type=\"reset\"]::-moz-focus-inner,\n[type=\"submit\"]::-moz-focus-inner {\n padding: 0;\n border-style: none;\n}\n\ninput[type=\"radio\"],\ninput[type=\"checkbox\"] {\n box-sizing: border-box; // 1. Add the correct box sizing in IE 10-\n padding: 0; // 2. Remove the padding in IE 10-\n}\n\n\ninput[type=\"date\"],\ninput[type=\"time\"],\ninput[type=\"datetime-local\"],\ninput[type=\"month\"] {\n // Remove the default appearance of temporal inputs to avoid a Mobile Safari\n // bug where setting a custom line-height prevents text from being vertically\n // centered within the input.\n // See https://bugs.webkit.org/show_bug.cgi?id=139848\n // and https://github.com/twbs/bootstrap/issues/11266\n -webkit-appearance: listbox;\n}\n\ntextarea {\n overflow: auto; // Remove the default vertical scrollbar in IE.\n // Textareas should really only resize vertically so they don't break their (horizontal) containers.\n resize: vertical;\n}\n\nfieldset {\n // Browsers set a default `min-width: min-content;` on fieldsets,\n // unlike e.g. `
`s, which have `min-width: 0;` by default.\n // So we reset that to ensure fieldsets behave more like a standard block element.\n // See https://github.com/twbs/bootstrap/issues/12359\n // and https://html.spec.whatwg.org/multipage/#the-fieldset-and-legend-elements\n min-width: 0;\n // Reset the default outline behavior of fieldsets so they don't affect page layout.\n padding: 0;\n margin: 0;\n border: 0;\n}\n\n// 1. Correct the text wrapping in Edge and IE.\n// 2. Correct the color inheritance from `fieldset` elements in IE.\nlegend {\n display: block;\n width: 100%;\n max-width: 100%; // 1\n padding: 0;\n margin-bottom: .5rem;\n @include font-size(1.5rem);\n line-height: inherit;\n color: inherit; // 2\n white-space: normal; // 1\n}\n\nprogress {\n vertical-align: baseline; // Add the correct vertical alignment in Chrome, Firefox, and Opera.\n}\n\n// Correct the cursor style of increment and decrement buttons in Chrome.\n[type=\"number\"]::-webkit-inner-spin-button,\n[type=\"number\"]::-webkit-outer-spin-button {\n height: auto;\n}\n\n[type=\"search\"] {\n // This overrides the extra rounded corners on search inputs in iOS so that our\n // `.form-control` class can properly style them. Note that this cannot simply\n // be added to `.form-control` as it's not specific enough. For details, see\n // https://github.com/twbs/bootstrap/issues/11586.\n outline-offset: -2px; // 2. Correct the outline style in Safari.\n -webkit-appearance: none;\n}\n\n//\n// Remove the inner padding in Chrome and Safari on macOS.\n//\n\n[type=\"search\"]::-webkit-search-decoration {\n -webkit-appearance: none;\n}\n\n//\n// 1. Correct the inability to style clickable types in iOS and Safari.\n// 2. Change font properties to `inherit` in Safari.\n//\n\n::-webkit-file-upload-button {\n font: inherit; // 2\n -webkit-appearance: button; // 1\n}\n\n//\n// Correct element displays\n//\n\noutput {\n display: inline-block;\n}\n\nsummary {\n display: list-item; // Add the correct display in all browsers\n cursor: pointer;\n}\n\ntemplate {\n display: none; // Add the correct display in IE\n}\n\n// Always hide an element with the `hidden` HTML attribute (from PureCSS).\n// Needed for proper display in IE 10-.\n[hidden] {\n display: none !important;\n}\n","// Variables\n//\n// Variables should follow the `$component-state-property-size` formula for\n// consistent naming. Ex: $nav-link-disabled-color and $modal-content-box-shadow-xs.\n\n// Color system\n\n$white: #fff !default;\n$gray-100: #f8f9fa !default;\n$gray-200: #e9ecef !default;\n$gray-300: #dee2e6 !default;\n$gray-400: #ced4da !default;\n$gray-500: #adb5bd !default;\n$gray-600: #6c757d !default;\n$gray-700: #495057 !default;\n$gray-800: #343a40 !default;\n$gray-900: #212529 !default;\n$black: #000 !default;\n\n$grays: () !default;\n// stylelint-disable-next-line scss/dollar-variable-default\n$grays: map-merge(\n (\n \"100\": $gray-100,\n \"200\": $gray-200,\n \"300\": $gray-300,\n \"400\": $gray-400,\n \"500\": $gray-500,\n \"600\": $gray-600,\n \"700\": $gray-700,\n \"800\": $gray-800,\n \"900\": $gray-900\n ),\n $grays\n);\n\n$blue: #007bff !default;\n$indigo: #6610f2 !default;\n$purple: #6f42c1 !default;\n$pink: #e83e8c !default;\n$red: #dc3545 !default;\n$orange: #fd7e14 !default;\n$yellow: #ffc107 !default;\n$green: #28a745 !default;\n$teal: #20c997 !default;\n$cyan: #17a2b8 !default;\n\n$colors: () !default;\n// stylelint-disable-next-line scss/dollar-variable-default\n$colors: map-merge(\n (\n \"blue\": $blue,\n \"indigo\": $indigo,\n \"purple\": $purple,\n \"pink\": $pink,\n \"red\": $red,\n \"orange\": $orange,\n \"yellow\": $yellow,\n \"green\": $green,\n \"teal\": $teal,\n \"cyan\": $cyan,\n \"white\": $white,\n \"gray\": $gray-600,\n \"gray-dark\": $gray-800\n ),\n $colors\n);\n\n$primary: $blue !default;\n$secondary: $gray-600 !default;\n$success: $green !default;\n$info: $cyan !default;\n$warning: $yellow !default;\n$danger: $red !default;\n$light: $gray-100 !default;\n$dark: $gray-800 !default;\n\n$theme-colors: () !default;\n// stylelint-disable-next-line scss/dollar-variable-default\n$theme-colors: map-merge(\n (\n \"primary\": $primary,\n \"secondary\": $secondary,\n \"success\": $success,\n \"info\": $info,\n \"warning\": $warning,\n \"danger\": $danger,\n \"light\": $light,\n \"dark\": $dark\n ),\n $theme-colors\n);\n\n// Set a specific jump point for requesting color jumps\n$theme-color-interval: 8% !default;\n\n// The yiq lightness value that determines when the lightness of color changes from \"dark\" to \"light\". Acceptable values are between 0 and 255.\n$yiq-contrasted-threshold: 150 !default;\n\n// Customize the light and dark text colors for use in our YIQ color contrast function.\n$yiq-text-dark: $gray-900 !default;\n$yiq-text-light: $white !default;\n\n// Characters which are escaped by the escape-svg function\n$escaped-characters: (\n (\"<\",\"%3c\"),\n (\">\",\"%3e\"),\n (\"#\",\"%23\"),\n) !default;\n\n\n// Options\n//\n// Quickly modify global styling by enabling or disabling optional features.\n\n$enable-caret: true !default;\n$enable-rounded: true !default;\n$enable-shadows: false !default;\n$enable-gradients: false !default;\n$enable-transitions: true !default;\n$enable-prefers-reduced-motion-media-query: true !default;\n$enable-hover-media-query: false !default; // Deprecated, no longer affects any compiled CSS\n$enable-grid-classes: true !default;\n$enable-pointer-cursor-for-buttons: true !default;\n$enable-print-styles: true !default;\n$enable-responsive-font-sizes: false !default;\n$enable-validation-icons: true !default;\n$enable-deprecation-messages: true !default;\n\n\n// Spacing\n//\n// Control the default styling of most Bootstrap elements by modifying these\n// variables. Mostly focused on spacing.\n// You can add more entries to the $spacers map, should you need more variation.\n\n$spacer: 1rem !default;\n$spacers: () !default;\n// stylelint-disable-next-line scss/dollar-variable-default\n$spacers: map-merge(\n (\n 0: 0,\n 1: ($spacer * .25),\n 2: ($spacer * .5),\n 3: $spacer,\n 4: ($spacer * 1.5),\n 5: ($spacer * 3)\n ),\n $spacers\n);\n\n// This variable affects the `.h-*` and `.w-*` classes.\n$sizes: () !default;\n// stylelint-disable-next-line scss/dollar-variable-default\n$sizes: map-merge(\n (\n 25: 25%,\n 50: 50%,\n 75: 75%,\n 100: 100%,\n auto: auto\n ),\n $sizes\n);\n\n\n// Body\n//\n// Settings for the `` element.\n\n$body-bg: $white !default;\n$body-color: $gray-900 !default;\n\n\n// Links\n//\n// Style anchor elements.\n\n$link-color: theme-color(\"primary\") !default;\n$link-decoration: none !default;\n$link-hover-color: darken($link-color, 15%) !default;\n$link-hover-decoration: underline !default;\n// Darken percentage for links with `.text-*` class (e.g. `.text-success`)\n$emphasized-link-hover-darken-percentage: 15% !default;\n\n// Paragraphs\n//\n// Style p element.\n\n$paragraph-margin-bottom: 1rem !default;\n\n\n// Grid breakpoints\n//\n// Define the minimum dimensions at which your layout will change,\n// adapting to different screen sizes, for use in media queries.\n\n$grid-breakpoints: (\n xs: 0,\n sm: 576px,\n md: 768px,\n lg: 992px,\n xl: 1200px\n) !default;\n\n@include _assert-ascending($grid-breakpoints, \"$grid-breakpoints\");\n@include _assert-starts-at-zero($grid-breakpoints, \"$grid-breakpoints\");\n\n\n// Grid containers\n//\n// Define the maximum width of `.container` for different screen sizes.\n\n$container-max-widths: (\n sm: 540px,\n md: 720px,\n lg: 960px,\n xl: 1140px\n) !default;\n\n@include _assert-ascending($container-max-widths, \"$container-max-widths\");\n\n\n// Grid columns\n//\n// Set the number of columns and specify the width of the gutters.\n\n$grid-columns: 12 !default;\n$grid-gutter-width: 30px !default;\n$grid-row-columns: 6 !default;\n\n\n// Components\n//\n// Define common padding and border radius sizes and more.\n\n$line-height-lg: 1.5 !default;\n$line-height-sm: 1.5 !default;\n\n$border-width: 1px !default;\n$border-color: $gray-300 !default;\n\n$border-radius: .25rem !default;\n$border-radius-lg: .3rem !default;\n$border-radius-sm: .2rem !default;\n\n$rounded-pill: 50rem !default;\n\n$box-shadow-sm: 0 .125rem .25rem rgba($black, .075) !default;\n$box-shadow: 0 .5rem 1rem rgba($black, .15) !default;\n$box-shadow-lg: 0 1rem 3rem rgba($black, .175) !default;\n\n$component-active-color: $white !default;\n$component-active-bg: theme-color(\"primary\") !default;\n\n$caret-width: .3em !default;\n$caret-vertical-align: $caret-width * .85 !default;\n$caret-spacing: $caret-width * .85 !default;\n\n$transition-base: all .2s ease-in-out !default;\n$transition-fade: opacity .15s linear !default;\n$transition-collapse: height .35s ease !default;\n\n$embed-responsive-aspect-ratios: () !default;\n// stylelint-disable-next-line scss/dollar-variable-default\n$embed-responsive-aspect-ratios: join(\n (\n (21 9),\n (16 9),\n (4 3),\n (1 1),\n ),\n $embed-responsive-aspect-ratios\n);\n\n// Typography\n//\n// Font, line-height, and color for body text, headings, and more.\n\n// stylelint-disable value-keyword-case\n$font-family-sans-serif: -apple-system, BlinkMacSystemFont, \"Segoe UI\", Roboto, \"Helvetica Neue\", Arial, \"Noto Sans\", sans-serif, \"Apple Color Emoji\", \"Segoe UI Emoji\", \"Segoe UI Symbol\", \"Noto Color Emoji\" !default;\n$font-family-monospace: SFMono-Regular, Menlo, Monaco, Consolas, \"Liberation Mono\", \"Courier New\", monospace !default;\n$font-family-base: $font-family-sans-serif !default;\n// stylelint-enable value-keyword-case\n\n$font-size-base: 1rem !default; // Assumes the browser default, typically `16px`\n$font-size-lg: $font-size-base * 1.25 !default;\n$font-size-sm: $font-size-base * .875 !default;\n\n$font-weight-lighter: lighter !default;\n$font-weight-light: 300 !default;\n$font-weight-normal: 400 !default;\n$font-weight-bold: 700 !default;\n$font-weight-bolder: bolder !default;\n\n$font-weight-base: $font-weight-normal !default;\n$line-height-base: 1.5 !default;\n\n$h1-font-size: $font-size-base * 2.5 !default;\n$h2-font-size: $font-size-base * 2 !default;\n$h3-font-size: $font-size-base * 1.75 !default;\n$h4-font-size: $font-size-base * 1.5 !default;\n$h5-font-size: $font-size-base * 1.25 !default;\n$h6-font-size: $font-size-base !default;\n\n$headings-margin-bottom: $spacer / 2 !default;\n$headings-font-family: null !default;\n$headings-font-weight: 500 !default;\n$headings-line-height: 1.2 !default;\n$headings-color: null !default;\n\n$display1-size: 6rem !default;\n$display2-size: 5.5rem !default;\n$display3-size: 4.5rem !default;\n$display4-size: 3.5rem !default;\n\n$display1-weight: 300 !default;\n$display2-weight: 300 !default;\n$display3-weight: 300 !default;\n$display4-weight: 300 !default;\n$display-line-height: $headings-line-height !default;\n\n$lead-font-size: $font-size-base * 1.25 !default;\n$lead-font-weight: 300 !default;\n\n$small-font-size: 80% !default;\n\n$text-muted: $gray-600 !default;\n\n$blockquote-small-color: $gray-600 !default;\n$blockquote-small-font-size: $small-font-size !default;\n$blockquote-font-size: $font-size-base * 1.25 !default;\n\n$hr-border-color: rgba($black, .1) !default;\n$hr-border-width: $border-width !default;\n\n$mark-padding: .2em !default;\n\n$dt-font-weight: $font-weight-bold !default;\n\n$kbd-box-shadow: inset 0 -.1rem 0 rgba($black, .25) !default;\n$nested-kbd-font-weight: $font-weight-bold !default;\n\n$list-inline-padding: .5rem !default;\n\n$mark-bg: #fcf8e3 !default;\n\n$hr-margin-y: $spacer !default;\n\n\n// Tables\n//\n// Customizes the `.table` component with basic values, each used across all table variations.\n\n$table-cell-padding: .75rem !default;\n$table-cell-padding-sm: .3rem !default;\n\n$table-color: $body-color !default;\n$table-bg: null !default;\n$table-accent-bg: rgba($black, .05) !default;\n$table-hover-color: $table-color !default;\n$table-hover-bg: rgba($black, .075) !default;\n$table-active-bg: $table-hover-bg !default;\n\n$table-border-width: $border-width !default;\n$table-border-color: $border-color !default;\n\n$table-head-bg: $gray-200 !default;\n$table-head-color: $gray-700 !default;\n\n$table-dark-color: $white !default;\n$table-dark-bg: $gray-800 !default;\n$table-dark-accent-bg: rgba($white, .05) !default;\n$table-dark-hover-color: $table-dark-color !default;\n$table-dark-hover-bg: rgba($white, .075) !default;\n$table-dark-border-color: lighten($table-dark-bg, 7.5%) !default;\n\n$table-striped-order: odd !default;\n\n$table-caption-color: $text-muted !default;\n\n$table-bg-level: -9 !default;\n$table-border-level: -6 !default;\n\n\n// Buttons + Forms\n//\n// Shared variables that are reassigned to `$input-` and `$btn-` specific variables.\n\n$input-btn-padding-y: .375rem !default;\n$input-btn-padding-x: .75rem !default;\n$input-btn-font-family: null !default;\n$input-btn-font-size: $font-size-base !default;\n$input-btn-line-height: $line-height-base !default;\n\n$input-btn-focus-width: .2rem !default;\n$input-btn-focus-color: rgba($component-active-bg, .25) !default;\n$input-btn-focus-box-shadow: 0 0 0 $input-btn-focus-width $input-btn-focus-color !default;\n\n$input-btn-padding-y-sm: .25rem !default;\n$input-btn-padding-x-sm: .5rem !default;\n$input-btn-font-size-sm: $font-size-sm !default;\n$input-btn-line-height-sm: $line-height-sm !default;\n\n$input-btn-padding-y-lg: .5rem !default;\n$input-btn-padding-x-lg: 1rem !default;\n$input-btn-font-size-lg: $font-size-lg !default;\n$input-btn-line-height-lg: $line-height-lg !default;\n\n$input-btn-border-width: $border-width !default;\n\n\n// Buttons\n//\n// For each of Bootstrap's buttons, define text, background, and border color.\n\n$btn-padding-y: $input-btn-padding-y !default;\n$btn-padding-x: $input-btn-padding-x !default;\n$btn-font-family: $input-btn-font-family !default;\n$btn-font-size: $input-btn-font-size !default;\n$btn-line-height: $input-btn-line-height !default;\n$btn-white-space: null !default; // Set to `nowrap` to prevent text wrapping\n\n$btn-padding-y-sm: $input-btn-padding-y-sm !default;\n$btn-padding-x-sm: $input-btn-padding-x-sm !default;\n$btn-font-size-sm: $input-btn-font-size-sm !default;\n$btn-line-height-sm: $input-btn-line-height-sm !default;\n\n$btn-padding-y-lg: $input-btn-padding-y-lg !default;\n$btn-padding-x-lg: $input-btn-padding-x-lg !default;\n$btn-font-size-lg: $input-btn-font-size-lg !default;\n$btn-line-height-lg: $input-btn-line-height-lg !default;\n\n$btn-border-width: $input-btn-border-width !default;\n\n$btn-font-weight: $font-weight-normal !default;\n$btn-box-shadow: inset 0 1px 0 rgba($white, .15), 0 1px 1px rgba($black, .075) !default;\n$btn-focus-width: $input-btn-focus-width !default;\n$btn-focus-box-shadow: $input-btn-focus-box-shadow !default;\n$btn-disabled-opacity: .65 !default;\n$btn-active-box-shadow: inset 0 3px 5px rgba($black, .125) !default;\n\n$btn-link-disabled-color: $gray-600 !default;\n\n$btn-block-spacing-y: .5rem !default;\n\n// Allows for customizing button radius independently from global border radius\n$btn-border-radius: $border-radius !default;\n$btn-border-radius-lg: $border-radius-lg !default;\n$btn-border-radius-sm: $border-radius-sm !default;\n\n$btn-transition: color .15s ease-in-out, background-color .15s ease-in-out, border-color .15s ease-in-out, box-shadow .15s ease-in-out !default;\n\n\n// Forms\n\n$label-margin-bottom: .5rem !default;\n\n$input-padding-y: $input-btn-padding-y !default;\n$input-padding-x: $input-btn-padding-x !default;\n$input-font-family: $input-btn-font-family !default;\n$input-font-size: $input-btn-font-size !default;\n$input-font-weight: $font-weight-base !default;\n$input-line-height: $input-btn-line-height !default;\n\n$input-padding-y-sm: $input-btn-padding-y-sm !default;\n$input-padding-x-sm: $input-btn-padding-x-sm !default;\n$input-font-size-sm: $input-btn-font-size-sm !default;\n$input-line-height-sm: $input-btn-line-height-sm !default;\n\n$input-padding-y-lg: $input-btn-padding-y-lg !default;\n$input-padding-x-lg: $input-btn-padding-x-lg !default;\n$input-font-size-lg: $input-btn-font-size-lg !default;\n$input-line-height-lg: $input-btn-line-height-lg !default;\n\n$input-bg: $white !default;\n$input-disabled-bg: $gray-200 !default;\n\n$input-color: $gray-700 !default;\n$input-border-color: $gray-400 !default;\n$input-border-width: $input-btn-border-width !default;\n$input-box-shadow: inset 0 1px 1px rgba($black, .075) !default;\n\n$input-border-radius: $border-radius !default;\n$input-border-radius-lg: $border-radius-lg !default;\n$input-border-radius-sm: $border-radius-sm !default;\n\n$input-focus-bg: $input-bg !default;\n$input-focus-border-color: lighten($component-active-bg, 25%) !default;\n$input-focus-color: $input-color !default;\n$input-focus-width: $input-btn-focus-width !default;\n$input-focus-box-shadow: $input-btn-focus-box-shadow !default;\n\n$input-placeholder-color: $gray-600 !default;\n$input-plaintext-color: $body-color !default;\n\n$input-height-border: $input-border-width * 2 !default;\n\n$input-height-inner: add($input-line-height * 1em, $input-padding-y * 2) !default;\n$input-height-inner-half: add($input-line-height * .5em, $input-padding-y) !default;\n$input-height-inner-quarter: add($input-line-height * .25em, $input-padding-y / 2) !default;\n\n$input-height: add($input-line-height * 1em, add($input-padding-y * 2, $input-height-border, false)) !default;\n$input-height-sm: add($input-line-height-sm * 1em, add($input-padding-y-sm * 2, $input-height-border, false)) !default;\n$input-height-lg: add($input-line-height-lg * 1em, add($input-padding-y-lg * 2, $input-height-border, false)) !default;\n\n$input-transition: border-color .15s ease-in-out, box-shadow .15s ease-in-out !default;\n\n$form-text-margin-top: .25rem !default;\n\n$form-check-input-gutter: 1.25rem !default;\n$form-check-input-margin-y: .3rem !default;\n$form-check-input-margin-x: .25rem !default;\n\n$form-check-inline-margin-x: .75rem !default;\n$form-check-inline-input-margin-x: .3125rem !default;\n\n$form-grid-gutter-width: 10px !default;\n$form-group-margin-bottom: 1rem !default;\n\n$input-group-addon-color: $input-color !default;\n$input-group-addon-bg: $gray-200 !default;\n$input-group-addon-border-color: $input-border-color !default;\n\n$custom-forms-transition: background-color .15s ease-in-out, border-color .15s ease-in-out, box-shadow .15s ease-in-out !default;\n\n$custom-control-gutter: .5rem !default;\n$custom-control-spacer-x: 1rem !default;\n$custom-control-cursor: null !default;\n\n$custom-control-indicator-size: 1rem !default;\n$custom-control-indicator-bg: $input-bg !default;\n\n$custom-control-indicator-bg-size: 50% 50% !default;\n$custom-control-indicator-box-shadow: $input-box-shadow !default;\n$custom-control-indicator-border-color: $gray-500 !default;\n$custom-control-indicator-border-width: $input-border-width !default;\n\n$custom-control-label-color: null !default;\n\n$custom-control-indicator-disabled-bg: $input-disabled-bg !default;\n$custom-control-label-disabled-color: $gray-600 !default;\n\n$custom-control-indicator-checked-color: $component-active-color !default;\n$custom-control-indicator-checked-bg: $component-active-bg !default;\n$custom-control-indicator-checked-disabled-bg: rgba(theme-color(\"primary\"), .5) !default;\n$custom-control-indicator-checked-box-shadow: none !default;\n$custom-control-indicator-checked-border-color: $custom-control-indicator-checked-bg !default;\n\n$custom-control-indicator-focus-box-shadow: $input-focus-box-shadow !default;\n$custom-control-indicator-focus-border-color: $input-focus-border-color !default;\n\n$custom-control-indicator-active-color: $component-active-color !default;\n$custom-control-indicator-active-bg: lighten($component-active-bg, 35%) !default;\n$custom-control-indicator-active-box-shadow: none !default;\n$custom-control-indicator-active-border-color: $custom-control-indicator-active-bg !default;\n\n$custom-checkbox-indicator-border-radius: $border-radius !default;\n$custom-checkbox-indicator-icon-checked: url(\"data:image/svg+xml,\") !default;\n\n$custom-checkbox-indicator-indeterminate-bg: $component-active-bg !default;\n$custom-checkbox-indicator-indeterminate-color: $custom-control-indicator-checked-color !default;\n$custom-checkbox-indicator-icon-indeterminate: url(\"data:image/svg+xml,\") !default;\n$custom-checkbox-indicator-indeterminate-box-shadow: none !default;\n$custom-checkbox-indicator-indeterminate-border-color: $custom-checkbox-indicator-indeterminate-bg !default;\n\n$custom-radio-indicator-border-radius: 50% !default;\n$custom-radio-indicator-icon-checked: url(\"data:image/svg+xml,\") !default;\n\n$custom-switch-width: $custom-control-indicator-size * 1.75 !default;\n$custom-switch-indicator-border-radius: $custom-control-indicator-size / 2 !default;\n$custom-switch-indicator-size: subtract($custom-control-indicator-size, $custom-control-indicator-border-width * 4) !default;\n\n$custom-select-padding-y: $input-padding-y !default;\n$custom-select-padding-x: $input-padding-x !default;\n$custom-select-font-family: $input-font-family !default;\n$custom-select-font-size: $input-font-size !default;\n$custom-select-height: $input-height !default;\n$custom-select-indicator-padding: 1rem !default; // Extra padding to account for the presence of the background-image based indicator\n$custom-select-font-weight: $input-font-weight !default;\n$custom-select-line-height: $input-line-height !default;\n$custom-select-color: $input-color !default;\n$custom-select-disabled-color: $gray-600 !default;\n$custom-select-bg: $input-bg !default;\n$custom-select-disabled-bg: $gray-200 !default;\n$custom-select-bg-size: 8px 10px !default; // In pixels because image dimensions\n$custom-select-indicator-color: $gray-800 !default;\n$custom-select-indicator: url(\"data:image/svg+xml,\") !default;\n$custom-select-background: escape-svg($custom-select-indicator) no-repeat right $custom-select-padding-x center / $custom-select-bg-size !default; // Used so we can have multiple background elements (e.g., arrow and feedback icon)\n\n$custom-select-feedback-icon-padding-right: add(1em * .75, (2 * $custom-select-padding-y * .75) + $custom-select-padding-x + $custom-select-indicator-padding) !default;\n$custom-select-feedback-icon-position: center right ($custom-select-padding-x + $custom-select-indicator-padding) !default;\n$custom-select-feedback-icon-size: $input-height-inner-half $input-height-inner-half !default;\n\n$custom-select-border-width: $input-border-width !default;\n$custom-select-border-color: $input-border-color !default;\n$custom-select-border-radius: $border-radius !default;\n$custom-select-box-shadow: inset 0 1px 2px rgba($black, .075) !default;\n\n$custom-select-focus-border-color: $input-focus-border-color !default;\n$custom-select-focus-width: $input-focus-width !default;\n$custom-select-focus-box-shadow: 0 0 0 $custom-select-focus-width $input-btn-focus-color !default;\n\n$custom-select-padding-y-sm: $input-padding-y-sm !default;\n$custom-select-padding-x-sm: $input-padding-x-sm !default;\n$custom-select-font-size-sm: $input-font-size-sm !default;\n$custom-select-height-sm: $input-height-sm !default;\n\n$custom-select-padding-y-lg: $input-padding-y-lg !default;\n$custom-select-padding-x-lg: $input-padding-x-lg !default;\n$custom-select-font-size-lg: $input-font-size-lg !default;\n$custom-select-height-lg: $input-height-lg !default;\n\n$custom-range-track-width: 100% !default;\n$custom-range-track-height: .5rem !default;\n$custom-range-track-cursor: pointer !default;\n$custom-range-track-bg: $gray-300 !default;\n$custom-range-track-border-radius: 1rem !default;\n$custom-range-track-box-shadow: inset 0 .25rem .25rem rgba($black, .1) !default;\n\n$custom-range-thumb-width: 1rem !default;\n$custom-range-thumb-height: $custom-range-thumb-width !default;\n$custom-range-thumb-bg: $component-active-bg !default;\n$custom-range-thumb-border: 0 !default;\n$custom-range-thumb-border-radius: 1rem !default;\n$custom-range-thumb-box-shadow: 0 .1rem .25rem rgba($black, .1) !default;\n$custom-range-thumb-focus-box-shadow: 0 0 0 1px $body-bg, $input-focus-box-shadow !default;\n$custom-range-thumb-focus-box-shadow-width: $input-focus-width !default; // For focus box shadow issue in IE/Edge\n$custom-range-thumb-active-bg: lighten($component-active-bg, 35%) !default;\n$custom-range-thumb-disabled-bg: $gray-500 !default;\n\n$custom-file-height: $input-height !default;\n$custom-file-height-inner: $input-height-inner !default;\n$custom-file-focus-border-color: $input-focus-border-color !default;\n$custom-file-focus-box-shadow: $input-focus-box-shadow !default;\n$custom-file-disabled-bg: $input-disabled-bg !default;\n\n$custom-file-padding-y: $input-padding-y !default;\n$custom-file-padding-x: $input-padding-x !default;\n$custom-file-line-height: $input-line-height !default;\n$custom-file-font-family: $input-font-family !default;\n$custom-file-font-weight: $input-font-weight !default;\n$custom-file-color: $input-color !default;\n$custom-file-bg: $input-bg !default;\n$custom-file-border-width: $input-border-width !default;\n$custom-file-border-color: $input-border-color !default;\n$custom-file-border-radius: $input-border-radius !default;\n$custom-file-box-shadow: $input-box-shadow !default;\n$custom-file-button-color: $custom-file-color !default;\n$custom-file-button-bg: $input-group-addon-bg !default;\n$custom-file-text: (\n en: \"Browse\"\n) !default;\n\n\n// Form validation\n\n$form-feedback-margin-top: $form-text-margin-top !default;\n$form-feedback-font-size: $small-font-size !default;\n$form-feedback-valid-color: theme-color(\"success\") !default;\n$form-feedback-invalid-color: theme-color(\"danger\") !default;\n\n$form-feedback-icon-valid-color: $form-feedback-valid-color !default;\n$form-feedback-icon-valid: url(\"data:image/svg+xml,\") !default;\n$form-feedback-icon-invalid-color: $form-feedback-invalid-color !default;\n$form-feedback-icon-invalid: url(\"data:image/svg+xml,\") !default;\n\n$form-validation-states: () !default;\n// stylelint-disable-next-line scss/dollar-variable-default\n$form-validation-states: map-merge(\n (\n \"valid\": (\n \"color\": $form-feedback-valid-color,\n \"icon\": $form-feedback-icon-valid\n ),\n \"invalid\": (\n \"color\": $form-feedback-invalid-color,\n \"icon\": $form-feedback-icon-invalid\n ),\n ),\n $form-validation-states\n);\n\n// Z-index master list\n//\n// Warning: Avoid customizing these values. They're used for a bird's eye view\n// of components dependent on the z-axis and are designed to all work together.\n\n$zindex-dropdown: 1000 !default;\n$zindex-sticky: 1020 !default;\n$zindex-fixed: 1030 !default;\n$zindex-modal-backdrop: 1040 !default;\n$zindex-modal: 1050 !default;\n$zindex-popover: 1060 !default;\n$zindex-tooltip: 1070 !default;\n\n\n// Navs\n\n$nav-link-padding-y: .5rem !default;\n$nav-link-padding-x: 1rem !default;\n$nav-link-disabled-color: $gray-600 !default;\n\n$nav-tabs-border-color: $gray-300 !default;\n$nav-tabs-border-width: $border-width !default;\n$nav-tabs-border-radius: $border-radius !default;\n$nav-tabs-link-hover-border-color: $gray-200 $gray-200 $nav-tabs-border-color !default;\n$nav-tabs-link-active-color: $gray-700 !default;\n$nav-tabs-link-active-bg: $body-bg !default;\n$nav-tabs-link-active-border-color: $gray-300 $gray-300 $nav-tabs-link-active-bg !default;\n\n$nav-pills-border-radius: $border-radius !default;\n$nav-pills-link-active-color: $component-active-color !default;\n$nav-pills-link-active-bg: $component-active-bg !default;\n\n$nav-divider-color: $gray-200 !default;\n$nav-divider-margin-y: $spacer / 2 !default;\n\n\n// Navbar\n\n$navbar-padding-y: $spacer / 2 !default;\n$navbar-padding-x: $spacer !default;\n\n$navbar-nav-link-padding-x: .5rem !default;\n\n$navbar-brand-font-size: $font-size-lg !default;\n// Compute the navbar-brand padding-y so the navbar-brand will have the same height as navbar-text and nav-link\n$nav-link-height: $font-size-base * $line-height-base + $nav-link-padding-y * 2 !default;\n$navbar-brand-height: $navbar-brand-font-size * $line-height-base !default;\n$navbar-brand-padding-y: ($nav-link-height - $navbar-brand-height) / 2 !default;\n\n$navbar-toggler-padding-y: .25rem !default;\n$navbar-toggler-padding-x: .75rem !default;\n$navbar-toggler-font-size: $font-size-lg !default;\n$navbar-toggler-border-radius: $btn-border-radius !default;\n\n$navbar-dark-color: rgba($white, .5) !default;\n$navbar-dark-hover-color: rgba($white, .75) !default;\n$navbar-dark-active-color: $white !default;\n$navbar-dark-disabled-color: rgba($white, .25) !default;\n$navbar-dark-toggler-icon-bg: url(\"data:image/svg+xml,\") !default;\n$navbar-dark-toggler-border-color: rgba($white, .1) !default;\n\n$navbar-light-color: rgba($black, .5) !default;\n$navbar-light-hover-color: rgba($black, .7) !default;\n$navbar-light-active-color: rgba($black, .9) !default;\n$navbar-light-disabled-color: rgba($black, .3) !default;\n$navbar-light-toggler-icon-bg: url(\"data:image/svg+xml,\") !default;\n$navbar-light-toggler-border-color: rgba($black, .1) !default;\n\n$navbar-light-brand-color: $navbar-light-active-color !default;\n$navbar-light-brand-hover-color: $navbar-light-active-color !default;\n$navbar-dark-brand-color: $navbar-dark-active-color !default;\n$navbar-dark-brand-hover-color: $navbar-dark-active-color !default;\n\n\n// Dropdowns\n//\n// Dropdown menu container and contents.\n\n$dropdown-min-width: 10rem !default;\n$dropdown-padding-y: .5rem !default;\n$dropdown-spacer: .125rem !default;\n$dropdown-font-size: $font-size-base !default;\n$dropdown-color: $body-color !default;\n$dropdown-bg: $white !default;\n$dropdown-border-color: rgba($black, .15) !default;\n$dropdown-border-radius: $border-radius !default;\n$dropdown-border-width: $border-width !default;\n$dropdown-inner-border-radius: subtract($dropdown-border-radius, $dropdown-border-width) !default;\n$dropdown-divider-bg: $gray-200 !default;\n$dropdown-divider-margin-y: $nav-divider-margin-y !default;\n$dropdown-box-shadow: 0 .5rem 1rem rgba($black, .175) !default;\n\n$dropdown-link-color: $gray-900 !default;\n$dropdown-link-hover-color: darken($gray-900, 5%) !default;\n$dropdown-link-hover-bg: $gray-100 !default;\n\n$dropdown-link-active-color: $component-active-color !default;\n$dropdown-link-active-bg: $component-active-bg !default;\n\n$dropdown-link-disabled-color: $gray-600 !default;\n\n$dropdown-item-padding-y: .25rem !default;\n$dropdown-item-padding-x: 1.5rem !default;\n\n$dropdown-header-color: $gray-600 !default;\n\n\n// Pagination\n\n$pagination-padding-y: .5rem !default;\n$pagination-padding-x: .75rem !default;\n$pagination-padding-y-sm: .25rem !default;\n$pagination-padding-x-sm: .5rem !default;\n$pagination-padding-y-lg: .75rem !default;\n$pagination-padding-x-lg: 1.5rem !default;\n$pagination-line-height: 1.25 !default;\n\n$pagination-color: $link-color !default;\n$pagination-bg: $white !default;\n$pagination-border-width: $border-width !default;\n$pagination-border-color: $gray-300 !default;\n\n$pagination-focus-box-shadow: $input-btn-focus-box-shadow !default;\n$pagination-focus-outline: 0 !default;\n\n$pagination-hover-color: $link-hover-color !default;\n$pagination-hover-bg: $gray-200 !default;\n$pagination-hover-border-color: $gray-300 !default;\n\n$pagination-active-color: $component-active-color !default;\n$pagination-active-bg: $component-active-bg !default;\n$pagination-active-border-color: $pagination-active-bg !default;\n\n$pagination-disabled-color: $gray-600 !default;\n$pagination-disabled-bg: $white !default;\n$pagination-disabled-border-color: $gray-300 !default;\n\n\n// Jumbotron\n\n$jumbotron-padding: 2rem !default;\n$jumbotron-color: null !default;\n$jumbotron-bg: $gray-200 !default;\n\n\n// Cards\n\n$card-spacer-y: .75rem !default;\n$card-spacer-x: 1.25rem !default;\n$card-border-width: $border-width !default;\n$card-border-radius: $border-radius !default;\n$card-border-color: rgba($black, .125) !default;\n$card-inner-border-radius: subtract($card-border-radius, $card-border-width) !default;\n$card-cap-bg: rgba($black, .03) !default;\n$card-cap-color: null !default;\n$card-height: null !default;\n$card-color: null !default;\n$card-bg: $white !default;\n\n$card-img-overlay-padding: 1.25rem !default;\n\n$card-group-margin: $grid-gutter-width / 2 !default;\n$card-deck-margin: $card-group-margin !default;\n\n$card-columns-count: 3 !default;\n$card-columns-gap: 1.25rem !default;\n$card-columns-margin: $card-spacer-y !default;\n\n\n// Tooltips\n\n$tooltip-font-size: $font-size-sm !default;\n$tooltip-max-width: 200px !default;\n$tooltip-color: $white !default;\n$tooltip-bg: $black !default;\n$tooltip-border-radius: $border-radius !default;\n$tooltip-opacity: .9 !default;\n$tooltip-padding-y: .25rem !default;\n$tooltip-padding-x: .5rem !default;\n$tooltip-margin: 0 !default;\n\n$tooltip-arrow-width: .8rem !default;\n$tooltip-arrow-height: .4rem !default;\n$tooltip-arrow-color: $tooltip-bg !default;\n\n// Form tooltips must come after regular tooltips\n$form-feedback-tooltip-padding-y: $tooltip-padding-y !default;\n$form-feedback-tooltip-padding-x: $tooltip-padding-x !default;\n$form-feedback-tooltip-font-size: $tooltip-font-size !default;\n$form-feedback-tooltip-line-height: $line-height-base !default;\n$form-feedback-tooltip-opacity: $tooltip-opacity !default;\n$form-feedback-tooltip-border-radius: $tooltip-border-radius !default;\n\n\n// Popovers\n\n$popover-font-size: $font-size-sm !default;\n$popover-bg: $white !default;\n$popover-max-width: 276px !default;\n$popover-border-width: $border-width !default;\n$popover-border-color: rgba($black, .2) !default;\n$popover-border-radius: $border-radius-lg !default;\n$popover-inner-border-radius: subtract($popover-border-radius, $popover-border-width) !default;\n$popover-box-shadow: 0 .25rem .5rem rgba($black, .2) !default;\n\n$popover-header-bg: darken($popover-bg, 3%) !default;\n$popover-header-color: $headings-color !default;\n$popover-header-padding-y: .5rem !default;\n$popover-header-padding-x: .75rem !default;\n\n$popover-body-color: $body-color !default;\n$popover-body-padding-y: $popover-header-padding-y !default;\n$popover-body-padding-x: $popover-header-padding-x !default;\n\n$popover-arrow-width: 1rem !default;\n$popover-arrow-height: .5rem !default;\n$popover-arrow-color: $popover-bg !default;\n\n$popover-arrow-outer-color: fade-in($popover-border-color, .05) !default;\n\n\n// Toasts\n\n$toast-max-width: 350px !default;\n$toast-padding-x: .75rem !default;\n$toast-padding-y: .25rem !default;\n$toast-font-size: .875rem !default;\n$toast-color: null !default;\n$toast-background-color: rgba($white, .85) !default;\n$toast-border-width: 1px !default;\n$toast-border-color: rgba(0, 0, 0, .1) !default;\n$toast-border-radius: .25rem !default;\n$toast-box-shadow: 0 .25rem .75rem rgba($black, .1) !default;\n\n$toast-header-color: $gray-600 !default;\n$toast-header-background-color: rgba($white, .85) !default;\n$toast-header-border-color: rgba(0, 0, 0, .05) !default;\n\n\n// Badges\n\n$badge-font-size: 75% !default;\n$badge-font-weight: $font-weight-bold !default;\n$badge-padding-y: .25em !default;\n$badge-padding-x: .4em !default;\n$badge-border-radius: $border-radius !default;\n\n$badge-transition: $btn-transition !default;\n$badge-focus-width: $input-btn-focus-width !default;\n\n$badge-pill-padding-x: .6em !default;\n// Use a higher than normal value to ensure completely rounded edges when\n// customizing padding or font-size on labels.\n$badge-pill-border-radius: 10rem !default;\n\n\n// Modals\n\n// Padding applied to the modal body\n$modal-inner-padding: 1rem !default;\n\n// Margin between elements in footer, must be lower than or equal to 2 * $modal-inner-padding\n$modal-footer-margin-between: .5rem !default;\n\n$modal-dialog-margin: .5rem !default;\n$modal-dialog-margin-y-sm-up: 1.75rem !default;\n\n$modal-title-line-height: $line-height-base !default;\n\n$modal-content-color: null !default;\n$modal-content-bg: $white !default;\n$modal-content-border-color: rgba($black, .2) !default;\n$modal-content-border-width: $border-width !default;\n$modal-content-border-radius: $border-radius-lg !default;\n$modal-content-inner-border-radius: subtract($modal-content-border-radius, $modal-content-border-width) !default;\n$modal-content-box-shadow-xs: 0 .25rem .5rem rgba($black, .5) !default;\n$modal-content-box-shadow-sm-up: 0 .5rem 1rem rgba($black, .5) !default;\n\n$modal-backdrop-bg: $black !default;\n$modal-backdrop-opacity: .5 !default;\n$modal-header-border-color: $border-color !default;\n$modal-footer-border-color: $modal-header-border-color !default;\n$modal-header-border-width: $modal-content-border-width !default;\n$modal-footer-border-width: $modal-header-border-width !default;\n$modal-header-padding-y: 1rem !default;\n$modal-header-padding-x: 1rem !default;\n$modal-header-padding: $modal-header-padding-y $modal-header-padding-x !default; // Keep this for backwards compatibility\n\n$modal-xl: 1140px !default;\n$modal-lg: 800px !default;\n$modal-md: 500px !default;\n$modal-sm: 300px !default;\n\n$modal-fade-transform: translate(0, -50px) !default;\n$modal-show-transform: none !default;\n$modal-transition: transform .3s ease-out !default;\n$modal-scale-transform: scale(1.02) !default;\n\n\n// Alerts\n//\n// Define alert colors, border radius, and padding.\n\n$alert-padding-y: .75rem !default;\n$alert-padding-x: 1.25rem !default;\n$alert-margin-bottom: 1rem !default;\n$alert-border-radius: $border-radius !default;\n$alert-link-font-weight: $font-weight-bold !default;\n$alert-border-width: $border-width !default;\n\n$alert-bg-level: -10 !default;\n$alert-border-level: -9 !default;\n$alert-color-level: 6 !default;\n\n\n// Progress bars\n\n$progress-height: 1rem !default;\n$progress-font-size: $font-size-base * .75 !default;\n$progress-bg: $gray-200 !default;\n$progress-border-radius: $border-radius !default;\n$progress-box-shadow: inset 0 .1rem .1rem rgba($black, .1) !default;\n$progress-bar-color: $white !default;\n$progress-bar-bg: theme-color(\"primary\") !default;\n$progress-bar-animation-timing: 1s linear infinite !default;\n$progress-bar-transition: width .6s ease !default;\n\n\n// List group\n\n$list-group-color: null !default;\n$list-group-bg: $white !default;\n$list-group-border-color: rgba($black, .125) !default;\n$list-group-border-width: $border-width !default;\n$list-group-border-radius: $border-radius !default;\n\n$list-group-item-padding-y: .75rem !default;\n$list-group-item-padding-x: 1.25rem !default;\n\n$list-group-hover-bg: $gray-100 !default;\n$list-group-active-color: $component-active-color !default;\n$list-group-active-bg: $component-active-bg !default;\n$list-group-active-border-color: $list-group-active-bg !default;\n\n$list-group-disabled-color: $gray-600 !default;\n$list-group-disabled-bg: $list-group-bg !default;\n\n$list-group-action-color: $gray-700 !default;\n$list-group-action-hover-color: $list-group-action-color !default;\n\n$list-group-action-active-color: $body-color !default;\n$list-group-action-active-bg: $gray-200 !default;\n\n\n// Image thumbnails\n\n$thumbnail-padding: .25rem !default;\n$thumbnail-bg: $body-bg !default;\n$thumbnail-border-width: $border-width !default;\n$thumbnail-border-color: $gray-300 !default;\n$thumbnail-border-radius: $border-radius !default;\n$thumbnail-box-shadow: 0 1px 2px rgba($black, .075) !default;\n\n\n// Figures\n\n$figure-caption-font-size: 90% !default;\n$figure-caption-color: $gray-600 !default;\n\n\n// Breadcrumbs\n\n$breadcrumb-font-size: null !default;\n\n$breadcrumb-padding-y: .75rem !default;\n$breadcrumb-padding-x: 1rem !default;\n$breadcrumb-item-padding: .5rem !default;\n\n$breadcrumb-margin-bottom: 1rem !default;\n\n$breadcrumb-bg: $gray-200 !default;\n$breadcrumb-divider-color: $gray-600 !default;\n$breadcrumb-active-color: $gray-600 !default;\n$breadcrumb-divider: quote(\"/\") !default;\n\n$breadcrumb-border-radius: $border-radius !default;\n\n\n// Carousel\n\n$carousel-control-color: $white !default;\n$carousel-control-width: 15% !default;\n$carousel-control-opacity: .5 !default;\n$carousel-control-hover-opacity: .9 !default;\n$carousel-control-transition: opacity .15s ease !default;\n\n$carousel-indicator-width: 30px !default;\n$carousel-indicator-height: 3px !default;\n$carousel-indicator-hit-area-height: 10px !default;\n$carousel-indicator-spacer: 3px !default;\n$carousel-indicator-active-bg: $white !default;\n$carousel-indicator-transition: opacity .6s ease !default;\n\n$carousel-caption-width: 70% !default;\n$carousel-caption-color: $white !default;\n\n$carousel-control-icon-width: 20px !default;\n\n$carousel-control-prev-icon-bg: url(\"data:image/svg+xml,\") !default;\n$carousel-control-next-icon-bg: url(\"data:image/svg+xml,\") !default;\n\n$carousel-transition-duration: .6s !default;\n$carousel-transition: transform $carousel-transition-duration ease-in-out !default; // Define transform transition first if using multiple transitions (e.g., `transform 2s ease, opacity .5s ease-out`)\n\n\n// Spinners\n\n$spinner-width: 2rem !default;\n$spinner-height: $spinner-width !default;\n$spinner-border-width: .25em !default;\n\n$spinner-width-sm: 1rem !default;\n$spinner-height-sm: $spinner-width-sm !default;\n$spinner-border-width-sm: .2em !default;\n\n\n// Close\n\n$close-font-size: $font-size-base * 1.5 !default;\n$close-font-weight: $font-weight-bold !default;\n$close-color: $black !default;\n$close-text-shadow: 0 1px 0 $white !default;\n\n\n// Code\n\n$code-font-size: 87.5% !default;\n$code-color: $pink !default;\n\n$kbd-padding-y: .2rem !default;\n$kbd-padding-x: .4rem !default;\n$kbd-font-size: $code-font-size !default;\n$kbd-color: $white !default;\n$kbd-bg: $gray-900 !default;\n\n$pre-color: $gray-900 !default;\n$pre-scrollable-max-height: 340px !default;\n\n\n// Utilities\n\n$displays: none, inline, inline-block, block, table, table-row, table-cell, flex, inline-flex !default;\n$overflows: auto, hidden !default;\n$positions: static, relative, absolute, fixed, sticky !default;\n\n\n// Printing\n\n$print-page-size: a3 !default;\n$print-body-min-width: map-get($grid-breakpoints, \"lg\") !default;\n","// stylelint-disable property-blacklist, scss/dollar-variable-default\n\n// SCSS RFS mixin\n//\n// Automated font-resizing\n//\n// See https://github.com/twbs/rfs\n\n// Configuration\n\n// Base font size\n$rfs-base-font-size: 1.25rem !default;\n$rfs-font-size-unit: rem !default;\n\n// Breakpoint at where font-size starts decreasing if screen width is smaller\n$rfs-breakpoint: 1200px !default;\n$rfs-breakpoint-unit: px !default;\n\n// Resize font-size based on screen height and width\n$rfs-two-dimensional: false !default;\n\n// Factor of decrease\n$rfs-factor: 10 !default;\n\n@if type-of($rfs-factor) != \"number\" or $rfs-factor <= 1 {\n @error \"`#{$rfs-factor}` is not a valid $rfs-factor, it must be greater than 1.\";\n}\n\n// Generate enable or disable classes. Possibilities: false, \"enable\" or \"disable\"\n$rfs-class: false !default;\n\n// 1 rem = $rfs-rem-value px\n$rfs-rem-value: 16 !default;\n\n// Safari iframe resize bug: https://github.com/twbs/rfs/issues/14\n$rfs-safari-iframe-resize-bug-fix: false !default;\n\n// Disable RFS by setting $enable-responsive-font-sizes to false\n$enable-responsive-font-sizes: true !default;\n\n// Cache $rfs-base-font-size unit\n$rfs-base-font-size-unit: unit($rfs-base-font-size);\n\n// Remove px-unit from $rfs-base-font-size for calculations\n@if $rfs-base-font-size-unit == \"px\" {\n $rfs-base-font-size: $rfs-base-font-size / ($rfs-base-font-size * 0 + 1);\n}\n@else if $rfs-base-font-size-unit == \"rem\" {\n $rfs-base-font-size: $rfs-base-font-size / ($rfs-base-font-size * 0 + 1 / $rfs-rem-value);\n}\n\n// Cache $rfs-breakpoint unit to prevent multiple calls\n$rfs-breakpoint-unit-cache: unit($rfs-breakpoint);\n\n// Remove unit from $rfs-breakpoint for calculations\n@if $rfs-breakpoint-unit-cache == \"px\" {\n $rfs-breakpoint: $rfs-breakpoint / ($rfs-breakpoint * 0 + 1);\n}\n@else if $rfs-breakpoint-unit-cache == \"rem\" or $rfs-breakpoint-unit-cache == \"em\" {\n $rfs-breakpoint: $rfs-breakpoint / ($rfs-breakpoint * 0 + 1 / $rfs-rem-value);\n}\n\n// Responsive font-size mixin\n@mixin rfs($fs, $important: false) {\n // Cache $fs unit\n $fs-unit: if(type-of($fs) == \"number\", unit($fs), false);\n\n // Add !important suffix if needed\n $rfs-suffix: if($important, \" !important\", \"\");\n\n // If $fs isn't a number (like inherit) or $fs has a unit (not px or rem, like 1.5em) or $ is 0, just print the value\n @if not $fs-unit or $fs-unit != \"\" and $fs-unit != \"px\" and $fs-unit != \"rem\" or $fs == 0 {\n font-size: #{$fs}#{$rfs-suffix};\n }\n @else {\n // Variables for storing static and fluid rescaling\n $rfs-static: null;\n $rfs-fluid: null;\n\n // Remove px-unit from $fs for calculations\n @if $fs-unit == \"px\" {\n $fs: $fs / ($fs * 0 + 1);\n }\n @else if $fs-unit == \"rem\" {\n $fs: $fs / ($fs * 0 + 1 / $rfs-rem-value);\n }\n\n // Set default font-size\n @if $rfs-font-size-unit == rem {\n $rfs-static: #{$fs / $rfs-rem-value}rem#{$rfs-suffix};\n }\n @else if $rfs-font-size-unit == px {\n $rfs-static: #{$fs}px#{$rfs-suffix};\n }\n @else {\n @error \"`#{$rfs-font-size-unit}` is not a valid unit for $rfs-font-size-unit. Use `px` or `rem`.\";\n }\n\n // Only add media query if font-size is bigger as the minimum font-size\n // If $rfs-factor == 1, no rescaling will take place\n @if $fs > $rfs-base-font-size and $enable-responsive-font-sizes {\n $min-width: null;\n $variable-unit: null;\n\n // Calculate minimum font-size for given font-size\n $fs-min: $rfs-base-font-size + ($fs - $rfs-base-font-size) / $rfs-factor;\n\n // Calculate difference between given font-size and minimum font-size for given font-size\n $fs-diff: $fs - $fs-min;\n\n // Base font-size formatting\n // No need to check if the unit is valid, because we did that before\n $min-width: if($rfs-font-size-unit == rem, #{$fs-min / $rfs-rem-value}rem, #{$fs-min}px);\n\n // If two-dimensional, use smallest of screen width and height\n $variable-unit: if($rfs-two-dimensional, vmin, vw);\n\n // Calculate the variable width between 0 and $rfs-breakpoint\n $variable-width: #{$fs-diff * 100 / $rfs-breakpoint}#{$variable-unit};\n\n // Set the calculated font-size.\n $rfs-fluid: calc(#{$min-width} + #{$variable-width}) #{$rfs-suffix};\n }\n\n // Rendering\n @if $rfs-fluid == null {\n // Only render static font-size if no fluid font-size is available\n font-size: $rfs-static;\n }\n @else {\n $mq-value: null;\n\n // RFS breakpoint formatting\n @if $rfs-breakpoint-unit == em or $rfs-breakpoint-unit == rem {\n $mq-value: #{$rfs-breakpoint / $rfs-rem-value}#{$rfs-breakpoint-unit};\n }\n @else if $rfs-breakpoint-unit == px {\n $mq-value: #{$rfs-breakpoint}px;\n }\n @else {\n @error \"`#{$rfs-breakpoint-unit}` is not a valid unit for $rfs-breakpoint-unit. Use `px`, `em` or `rem`.\";\n }\n\n @if $rfs-class == \"disable\" {\n // Adding an extra class increases specificity,\n // which prevents the media query to override the font size\n &,\n .disable-responsive-font-size &,\n &.disable-responsive-font-size {\n font-size: $rfs-static;\n }\n }\n @else {\n font-size: $rfs-static;\n }\n\n @if $rfs-two-dimensional {\n @media (max-width: #{$mq-value}), (max-height: #{$mq-value}) {\n @if $rfs-class == \"enable\" {\n .enable-responsive-font-size &,\n &.enable-responsive-font-size {\n font-size: $rfs-fluid;\n }\n }\n @else {\n font-size: $rfs-fluid;\n }\n\n @if $rfs-safari-iframe-resize-bug-fix {\n // stylelint-disable-next-line length-zero-no-unit\n min-width: 0vw;\n }\n }\n }\n @else {\n @media (max-width: #{$mq-value}) {\n @if $rfs-class == \"enable\" {\n .enable-responsive-font-size &,\n &.enable-responsive-font-size {\n font-size: $rfs-fluid;\n }\n }\n @else {\n font-size: $rfs-fluid;\n }\n\n @if $rfs-safari-iframe-resize-bug-fix {\n // stylelint-disable-next-line length-zero-no-unit\n min-width: 0vw;\n }\n }\n }\n }\n }\n}\n\n// The font-size & responsive-font-size mixin uses RFS to rescale font sizes\n@mixin font-size($fs, $important: false) {\n @include rfs($fs, $important);\n}\n\n@mixin responsive-font-size($fs, $important: false) {\n @include rfs($fs, $important);\n}\n","// Hover mixin and `$enable-hover-media-query` are deprecated.\n//\n// Originally added during our alphas and maintained during betas, this mixin was\n// designed to prevent `:hover` stickiness on iOS-an issue where hover styles\n// would persist after initial touch.\n//\n// For backward compatibility, we've kept these mixins and updated them to\n// always return their regular pseudo-classes instead of a shimmed media query.\n//\n// Issue: https://github.com/twbs/bootstrap/issues/25195\n\n@mixin hover() {\n &:hover { @content; }\n}\n\n@mixin hover-focus() {\n &:hover,\n &:focus {\n @content;\n }\n}\n\n@mixin plain-hover-focus() {\n &,\n &:hover,\n &:focus {\n @content;\n }\n}\n\n@mixin hover-focus-active() {\n &:hover,\n &:focus,\n &:active {\n @content;\n }\n}\n","// stylelint-disable declaration-no-important, selector-list-comma-newline-after\n\n//\n// Headings\n//\n\nh1, h2, h3, h4, h5, h6,\n.h1, .h2, .h3, .h4, .h5, .h6 {\n margin-bottom: $headings-margin-bottom;\n font-family: $headings-font-family;\n font-weight: $headings-font-weight;\n line-height: $headings-line-height;\n color: $headings-color;\n}\n\nh1, .h1 { @include font-size($h1-font-size); }\nh2, .h2 { @include font-size($h2-font-size); }\nh3, .h3 { @include font-size($h3-font-size); }\nh4, .h4 { @include font-size($h4-font-size); }\nh5, .h5 { @include font-size($h5-font-size); }\nh6, .h6 { @include font-size($h6-font-size); }\n\n.lead {\n @include font-size($lead-font-size);\n font-weight: $lead-font-weight;\n}\n\n// Type display classes\n.display-1 {\n @include font-size($display1-size);\n font-weight: $display1-weight;\n line-height: $display-line-height;\n}\n.display-2 {\n @include font-size($display2-size);\n font-weight: $display2-weight;\n line-height: $display-line-height;\n}\n.display-3 {\n @include font-size($display3-size);\n font-weight: $display3-weight;\n line-height: $display-line-height;\n}\n.display-4 {\n @include font-size($display4-size);\n font-weight: $display4-weight;\n line-height: $display-line-height;\n}\n\n\n//\n// Horizontal rules\n//\n\nhr {\n margin-top: $hr-margin-y;\n margin-bottom: $hr-margin-y;\n border: 0;\n border-top: $hr-border-width solid $hr-border-color;\n}\n\n\n//\n// Emphasis\n//\n\nsmall,\n.small {\n @include font-size($small-font-size);\n font-weight: $font-weight-normal;\n}\n\nmark,\n.mark {\n padding: $mark-padding;\n background-color: $mark-bg;\n}\n\n\n//\n// Lists\n//\n\n.list-unstyled {\n @include list-unstyled();\n}\n\n// Inline turns list items into inline-block\n.list-inline {\n @include list-unstyled();\n}\n.list-inline-item {\n display: inline-block;\n\n &:not(:last-child) {\n margin-right: $list-inline-padding;\n }\n}\n\n\n//\n// Misc\n//\n\n// Builds on `abbr`\n.initialism {\n @include font-size(90%);\n text-transform: uppercase;\n}\n\n// Blockquotes\n.blockquote {\n margin-bottom: $spacer;\n @include font-size($blockquote-font-size);\n}\n\n.blockquote-footer {\n display: block;\n @include font-size($blockquote-small-font-size);\n color: $blockquote-small-color;\n\n &::before {\n content: \"\\2014\\00A0\"; // em dash, nbsp\n }\n}\n","// Lists\n\n// Unstyled keeps list items block level, just removes default browser padding and list-style\n@mixin list-unstyled() {\n padding-left: 0;\n list-style: none;\n}\n","// Responsive images (ensure images don't scale beyond their parents)\n//\n// This is purposefully opt-in via an explicit class rather than being the default for all ``s.\n// We previously tried the \"images are responsive by default\" approach in Bootstrap v2,\n// and abandoned it in Bootstrap v3 because it breaks lots of third-party widgets (including Google Maps)\n// which weren't expecting the images within themselves to be involuntarily resized.\n// See also https://github.com/twbs/bootstrap/issues/18178\n.img-fluid {\n @include img-fluid();\n}\n\n\n// Image thumbnails\n.img-thumbnail {\n padding: $thumbnail-padding;\n background-color: $thumbnail-bg;\n border: $thumbnail-border-width solid $thumbnail-border-color;\n @include border-radius($thumbnail-border-radius);\n @include box-shadow($thumbnail-box-shadow);\n\n // Keep them at most 100% wide\n @include img-fluid();\n}\n\n//\n// Figures\n//\n\n.figure {\n // Ensures the caption's text aligns with the image.\n display: inline-block;\n}\n\n.figure-img {\n margin-bottom: $spacer / 2;\n line-height: 1;\n}\n\n.figure-caption {\n @include font-size($figure-caption-font-size);\n color: $figure-caption-color;\n}\n","// Image Mixins\n// - Responsive image\n// - Retina image\n\n\n// Responsive image\n//\n// Keep images from scaling beyond the width of their parents.\n\n@mixin img-fluid() {\n // Part 1: Set a maximum relative to the parent\n max-width: 100%;\n // Part 2: Override the height to auto, otherwise images will be stretched\n // when setting a width and height attribute on the img element.\n height: auto;\n}\n\n\n// Retina image\n//\n// Short retina mixin for setting background-image and -size.\n\n@mixin img-retina($file-1x, $file-2x, $width-1x, $height-1x) {\n background-image: url($file-1x);\n\n // Autoprefixer takes care of adding -webkit-min-device-pixel-ratio and -o-min-device-pixel-ratio,\n // but doesn't convert dppx=>dpi.\n // There's no such thing as unprefixed min-device-pixel-ratio since it's nonstandard.\n // Compatibility info: https://caniuse.com/#feat=css-media-resolution\n @media only screen and (min-resolution: 192dpi), // IE9-11 don't support dppx\n only screen and (min-resolution: 2dppx) { // Standardized\n background-image: url($file-2x);\n background-size: $width-1x $height-1x;\n }\n @include deprecate(\"`img-retina()`\", \"v4.3.0\", \"v5\");\n}\n","// stylelint-disable property-blacklist\n// Single side border-radius\n\n@mixin border-radius($radius: $border-radius, $fallback-border-radius: false) {\n @if $enable-rounded {\n border-radius: $radius;\n }\n @else if $fallback-border-radius != false {\n border-radius: $fallback-border-radius;\n }\n}\n\n@mixin border-top-radius($radius) {\n @if $enable-rounded {\n border-top-left-radius: $radius;\n border-top-right-radius: $radius;\n }\n}\n\n@mixin border-right-radius($radius) {\n @if $enable-rounded {\n border-top-right-radius: $radius;\n border-bottom-right-radius: $radius;\n }\n}\n\n@mixin border-bottom-radius($radius) {\n @if $enable-rounded {\n border-bottom-right-radius: $radius;\n border-bottom-left-radius: $radius;\n }\n}\n\n@mixin border-left-radius($radius) {\n @if $enable-rounded {\n border-top-left-radius: $radius;\n border-bottom-left-radius: $radius;\n }\n}\n\n@mixin border-top-left-radius($radius) {\n @if $enable-rounded {\n border-top-left-radius: $radius;\n }\n}\n\n@mixin border-top-right-radius($radius) {\n @if $enable-rounded {\n border-top-right-radius: $radius;\n }\n}\n\n@mixin border-bottom-right-radius($radius) {\n @if $enable-rounded {\n border-bottom-right-radius: $radius;\n }\n}\n\n@mixin border-bottom-left-radius($radius) {\n @if $enable-rounded {\n border-bottom-left-radius: $radius;\n }\n}\n","// Inline code\ncode {\n @include font-size($code-font-size);\n color: $code-color;\n word-wrap: break-word;\n\n // Streamline the style when inside anchors to avoid broken underline and more\n a > & {\n color: inherit;\n }\n}\n\n// User input typically entered via keyboard\nkbd {\n padding: $kbd-padding-y $kbd-padding-x;\n @include font-size($kbd-font-size);\n color: $kbd-color;\n background-color: $kbd-bg;\n @include border-radius($border-radius-sm);\n @include box-shadow($kbd-box-shadow);\n\n kbd {\n padding: 0;\n @include font-size(100%);\n font-weight: $nested-kbd-font-weight;\n @include box-shadow(none);\n }\n}\n\n// Blocks of code\npre {\n display: block;\n @include font-size($code-font-size);\n color: $pre-color;\n\n // Account for some code outputs that place code tags in pre tags\n code {\n @include font-size(inherit);\n color: inherit;\n word-break: normal;\n }\n}\n\n// Enable scrollable blocks of code\n.pre-scrollable {\n max-height: $pre-scrollable-max-height;\n overflow-y: scroll;\n}\n","// Container widths\n//\n// Set the container width, and override it for fixed navbars in media queries.\n\n@if $enable-grid-classes {\n // Single container class with breakpoint max-widths\n .container {\n @include make-container();\n @include make-container-max-widths();\n }\n\n // 100% wide container at all breakpoints\n .container-fluid {\n @include make-container();\n }\n\n // Responsive containers that are 100% wide until a breakpoint\n @each $breakpoint, $container-max-width in $container-max-widths {\n .container-#{$breakpoint} {\n @extend .container-fluid;\n }\n\n @include media-breakpoint-up($breakpoint, $grid-breakpoints) {\n %responsive-container-#{$breakpoint} {\n max-width: $container-max-width;\n }\n\n @each $name, $width in $grid-breakpoints {\n @if ($container-max-width > $width or $breakpoint == $name) {\n .container#{breakpoint-infix($name, $grid-breakpoints)} {\n @extend %responsive-container-#{$breakpoint};\n }\n }\n }\n }\n }\n}\n\n\n// Row\n//\n// Rows contain your columns.\n\n@if $enable-grid-classes {\n .row {\n @include make-row();\n }\n\n // Remove the negative margin from default .row, then the horizontal padding\n // from all immediate children columns (to prevent runaway style inheritance).\n .no-gutters {\n margin-right: 0;\n margin-left: 0;\n\n > .col,\n > [class*=\"col-\"] {\n padding-right: 0;\n padding-left: 0;\n }\n }\n}\n\n// Columns\n//\n// Common styles for small and large grid columns\n\n@if $enable-grid-classes {\n @include make-grid-columns();\n}\n","/// Grid system\n//\n// Generate semantic grid columns with these mixins.\n\n@mixin make-container($gutter: $grid-gutter-width) {\n width: 100%;\n padding-right: $gutter / 2;\n padding-left: $gutter / 2;\n margin-right: auto;\n margin-left: auto;\n}\n\n\n// For each breakpoint, define the maximum width of the container in a media query\n@mixin make-container-max-widths($max-widths: $container-max-widths, $breakpoints: $grid-breakpoints) {\n @each $breakpoint, $container-max-width in $max-widths {\n @include media-breakpoint-up($breakpoint, $breakpoints) {\n max-width: $container-max-width;\n }\n }\n}\n\n@mixin make-row($gutter: $grid-gutter-width) {\n display: flex;\n flex-wrap: wrap;\n margin-right: -$gutter / 2;\n margin-left: -$gutter / 2;\n}\n\n@mixin make-col-ready($gutter: $grid-gutter-width) {\n position: relative;\n // Prevent columns from becoming too narrow when at smaller grid tiers by\n // always setting `width: 100%;`. This works because we use `flex` values\n // later on to override this initial width.\n width: 100%;\n padding-right: $gutter / 2;\n padding-left: $gutter / 2;\n}\n\n@mixin make-col($size, $columns: $grid-columns) {\n flex: 0 0 percentage($size / $columns);\n // Add a `max-width` to ensure content within each column does not blow out\n // the width of the column. Applies to IE10+ and Firefox. Chrome and Safari\n // do not appear to require this.\n max-width: percentage($size / $columns);\n}\n\n@mixin make-col-auto() {\n flex: 0 0 auto;\n width: auto;\n max-width: 100%; // Reset earlier grid tiers\n}\n\n@mixin make-col-offset($size, $columns: $grid-columns) {\n $num: $size / $columns;\n margin-left: if($num == 0, 0, percentage($num));\n}\n\n// Row columns\n//\n// Specify on a parent element(e.g., .row) to force immediate children into NN\n// numberof columns. Supports wrapping to new lines, but does not do a Masonry\n// style grid.\n@mixin row-cols($count) {\n & > * {\n flex: 0 0 100% / $count;\n max-width: 100% / $count;\n }\n}\n","// Breakpoint viewport sizes and media queries.\n//\n// Breakpoints are defined as a map of (name: minimum width), order from small to large:\n//\n// (xs: 0, sm: 576px, md: 768px, lg: 992px, xl: 1200px)\n//\n// The map defined in the `$grid-breakpoints` global variable is used as the `$breakpoints` argument by default.\n\n// Name of the next breakpoint, or null for the last breakpoint.\n//\n// >> breakpoint-next(sm)\n// md\n// >> breakpoint-next(sm, (xs: 0, sm: 576px, md: 768px, lg: 992px, xl: 1200px))\n// md\n// >> breakpoint-next(sm, $breakpoint-names: (xs sm md lg xl))\n// md\n@function breakpoint-next($name, $breakpoints: $grid-breakpoints, $breakpoint-names: map-keys($breakpoints)) {\n $n: index($breakpoint-names, $name);\n @return if($n != null and $n < length($breakpoint-names), nth($breakpoint-names, $n + 1), null);\n}\n\n// Minimum breakpoint width. Null for the smallest (first) breakpoint.\n//\n// >> breakpoint-min(sm, (xs: 0, sm: 576px, md: 768px, lg: 992px, xl: 1200px))\n// 576px\n@function breakpoint-min($name, $breakpoints: $grid-breakpoints) {\n $min: map-get($breakpoints, $name);\n @return if($min != 0, $min, null);\n}\n\n// Maximum breakpoint width. Null for the largest (last) breakpoint.\n// The maximum value is calculated as the minimum of the next one less 0.02px\n// to work around the limitations of `min-` and `max-` prefixes and viewports with fractional widths.\n// See https://www.w3.org/TR/mediaqueries-4/#mq-min-max\n// Uses 0.02px rather than 0.01px to work around a current rounding bug in Safari.\n// See https://bugs.webkit.org/show_bug.cgi?id=178261\n//\n// >> breakpoint-max(sm, (xs: 0, sm: 576px, md: 768px, lg: 992px, xl: 1200px))\n// 767.98px\n@function breakpoint-max($name, $breakpoints: $grid-breakpoints) {\n $next: breakpoint-next($name, $breakpoints);\n @return if($next, breakpoint-min($next, $breakpoints) - .02, null);\n}\n\n// Returns a blank string if smallest breakpoint, otherwise returns the name with a dash in front.\n// Useful for making responsive utilities.\n//\n// >> breakpoint-infix(xs, (xs: 0, sm: 576px, md: 768px, lg: 992px, xl: 1200px))\n// \"\" (Returns a blank string)\n// >> breakpoint-infix(sm, (xs: 0, sm: 576px, md: 768px, lg: 992px, xl: 1200px))\n// \"-sm\"\n@function breakpoint-infix($name, $breakpoints: $grid-breakpoints) {\n @return if(breakpoint-min($name, $breakpoints) == null, \"\", \"-#{$name}\");\n}\n\n// Media of at least the minimum breakpoint width. No query for the smallest breakpoint.\n// Makes the @content apply to the given breakpoint and wider.\n@mixin media-breakpoint-up($name, $breakpoints: $grid-breakpoints) {\n $min: breakpoint-min($name, $breakpoints);\n @if $min {\n @media (min-width: $min) {\n @content;\n }\n } @else {\n @content;\n }\n}\n\n// Media of at most the maximum breakpoint width. No query for the largest breakpoint.\n// Makes the @content apply to the given breakpoint and narrower.\n@mixin media-breakpoint-down($name, $breakpoints: $grid-breakpoints) {\n $max: breakpoint-max($name, $breakpoints);\n @if $max {\n @media (max-width: $max) {\n @content;\n }\n } @else {\n @content;\n }\n}\n\n// Media that spans multiple breakpoint widths.\n// Makes the @content apply between the min and max breakpoints\n@mixin media-breakpoint-between($lower, $upper, $breakpoints: $grid-breakpoints) {\n $min: breakpoint-min($lower, $breakpoints);\n $max: breakpoint-max($upper, $breakpoints);\n\n @if $min != null and $max != null {\n @media (min-width: $min) and (max-width: $max) {\n @content;\n }\n } @else if $max == null {\n @include media-breakpoint-up($lower, $breakpoints) {\n @content;\n }\n } @else if $min == null {\n @include media-breakpoint-down($upper, $breakpoints) {\n @content;\n }\n }\n}\n\n// Media between the breakpoint's minimum and maximum widths.\n// No minimum for the smallest breakpoint, and no maximum for the largest one.\n// Makes the @content apply only to the given breakpoint, not viewports any wider or narrower.\n@mixin media-breakpoint-only($name, $breakpoints: $grid-breakpoints) {\n $min: breakpoint-min($name, $breakpoints);\n $max: breakpoint-max($name, $breakpoints);\n\n @if $min != null and $max != null {\n @media (min-width: $min) and (max-width: $max) {\n @content;\n }\n } @else if $max == null {\n @include media-breakpoint-up($name, $breakpoints) {\n @content;\n }\n } @else if $min == null {\n @include media-breakpoint-down($name, $breakpoints) {\n @content;\n }\n }\n}\n","// Framework grid generation\n//\n// Used only by Bootstrap to generate the correct number of grid classes given\n// any value of `$grid-columns`.\n\n@mixin make-grid-columns($columns: $grid-columns, $gutter: $grid-gutter-width, $breakpoints: $grid-breakpoints) {\n // Common properties for all breakpoints\n %grid-column {\n position: relative;\n width: 100%;\n padding-right: $gutter / 2;\n padding-left: $gutter / 2;\n }\n\n @each $breakpoint in map-keys($breakpoints) {\n $infix: breakpoint-infix($breakpoint, $breakpoints);\n\n // Allow columns to stretch full width below their breakpoints\n @for $i from 1 through $columns {\n .col#{$infix}-#{$i} {\n @extend %grid-column;\n }\n }\n .col#{$infix},\n .col#{$infix}-auto {\n @extend %grid-column;\n }\n\n @include media-breakpoint-up($breakpoint, $breakpoints) {\n // Provide basic `.col-{bp}` classes for equal-width flexbox columns\n .col#{$infix} {\n flex-basis: 0;\n flex-grow: 1;\n max-width: 100%;\n }\n\n @for $i from 1 through $grid-row-columns {\n .row-cols#{$infix}-#{$i} {\n @include row-cols($i);\n }\n }\n\n .col#{$infix}-auto {\n @include make-col-auto();\n }\n\n @for $i from 1 through $columns {\n .col#{$infix}-#{$i} {\n @include make-col($i, $columns);\n }\n }\n\n .order#{$infix}-first { order: -1; }\n\n .order#{$infix}-last { order: $columns + 1; }\n\n @for $i from 0 through $columns {\n .order#{$infix}-#{$i} { order: $i; }\n }\n\n // `$columns - 1` because offsetting by the width of an entire row isn't possible\n @for $i from 0 through ($columns - 1) {\n @if not ($infix == \"\" and $i == 0) { // Avoid emitting useless .offset-0\n .offset#{$infix}-#{$i} {\n @include make-col-offset($i, $columns);\n }\n }\n }\n }\n }\n}\n","//\n// Basic Bootstrap table\n//\n\n.table {\n width: 100%;\n margin-bottom: $spacer;\n color: $table-color;\n background-color: $table-bg; // Reset for nesting within parents with `background-color`.\n\n th,\n td {\n padding: $table-cell-padding;\n vertical-align: top;\n border-top: $table-border-width solid $table-border-color;\n }\n\n thead th {\n vertical-align: bottom;\n border-bottom: (2 * $table-border-width) solid $table-border-color;\n }\n\n tbody + tbody {\n border-top: (2 * $table-border-width) solid $table-border-color;\n }\n}\n\n\n//\n// Condensed table w/ half padding\n//\n\n.table-sm {\n th,\n td {\n padding: $table-cell-padding-sm;\n }\n}\n\n\n// Border versions\n//\n// Add or remove borders all around the table and between all the columns.\n\n.table-bordered {\n border: $table-border-width solid $table-border-color;\n\n th,\n td {\n border: $table-border-width solid $table-border-color;\n }\n\n thead {\n th,\n td {\n border-bottom-width: 2 * $table-border-width;\n }\n }\n}\n\n.table-borderless {\n th,\n td,\n thead th,\n tbody + tbody {\n border: 0;\n }\n}\n\n// Zebra-striping\n//\n// Default zebra-stripe styles (alternating gray and transparent backgrounds)\n\n.table-striped {\n tbody tr:nth-of-type(#{$table-striped-order}) {\n background-color: $table-accent-bg;\n }\n}\n\n\n// Hover effect\n//\n// Placed here since it has to come after the potential zebra striping\n\n.table-hover {\n tbody tr {\n @include hover() {\n color: $table-hover-color;\n background-color: $table-hover-bg;\n }\n }\n}\n\n\n// Table backgrounds\n//\n// Exact selectors below required to override `.table-striped` and prevent\n// inheritance to nested tables.\n\n@each $color, $value in $theme-colors {\n @include table-row-variant($color, theme-color-level($color, $table-bg-level), theme-color-level($color, $table-border-level));\n}\n\n@include table-row-variant(active, $table-active-bg);\n\n\n// Dark styles\n//\n// Same table markup, but inverted color scheme: dark background and light text.\n\n// stylelint-disable-next-line no-duplicate-selectors\n.table {\n .thead-dark {\n th {\n color: $table-dark-color;\n background-color: $table-dark-bg;\n border-color: $table-dark-border-color;\n }\n }\n\n .thead-light {\n th {\n color: $table-head-color;\n background-color: $table-head-bg;\n border-color: $table-border-color;\n }\n }\n}\n\n.table-dark {\n color: $table-dark-color;\n background-color: $table-dark-bg;\n\n th,\n td,\n thead th {\n border-color: $table-dark-border-color;\n }\n\n &.table-bordered {\n border: 0;\n }\n\n &.table-striped {\n tbody tr:nth-of-type(#{$table-striped-order}) {\n background-color: $table-dark-accent-bg;\n }\n }\n\n &.table-hover {\n tbody tr {\n @include hover() {\n color: $table-dark-hover-color;\n background-color: $table-dark-hover-bg;\n }\n }\n }\n}\n\n\n// Responsive tables\n//\n// Generate series of `.table-responsive-*` classes for configuring the screen\n// size of where your table will overflow.\n\n.table-responsive {\n @each $breakpoint in map-keys($grid-breakpoints) {\n $next: breakpoint-next($breakpoint, $grid-breakpoints);\n $infix: breakpoint-infix($next, $grid-breakpoints);\n\n {$infix} {\n @include media-breakpoint-down($breakpoint) {\n display: block;\n width: 100%;\n overflow-x: auto;\n -webkit-overflow-scrolling: touch;\n\n // Prevent double border on horizontal scroll due to use of `display: block;`\n > .table-bordered {\n border: 0;\n }\n }\n }\n }\n}\n","// Tables\n\n@mixin table-row-variant($state, $background, $border: null) {\n // Exact selectors below required to override `.table-striped` and prevent\n // inheritance to nested tables.\n .table-#{$state} {\n &,\n > th,\n > td {\n background-color: $background;\n }\n\n @if $border != null {\n th,\n td,\n thead th,\n tbody + tbody {\n border-color: $border;\n }\n }\n }\n\n // Hover states for `.table-hover`\n // Note: this is not available for cells or rows within `thead` or `tfoot`.\n .table-hover {\n $hover-background: darken($background, 5%);\n\n .table-#{$state} {\n @include hover() {\n background-color: $hover-background;\n\n > td,\n > th {\n background-color: $hover-background;\n }\n }\n }\n }\n}\n","// Bootstrap functions\n//\n// Utility mixins and functions for evaluating source code across our variables, maps, and mixins.\n\n// Ascending\n// Used to evaluate Sass maps like our grid breakpoints.\n@mixin _assert-ascending($map, $map-name) {\n $prev-key: null;\n $prev-num: null;\n @each $key, $num in $map {\n @if $prev-num == null or unit($num) == \"%\" or unit($prev-num) == \"%\" {\n // Do nothing\n } @else if not comparable($prev-num, $num) {\n @warn \"Potentially invalid value for #{$map-name}: This map must be in ascending order, but key '#{$key}' has value #{$num} whose unit makes it incomparable to #{$prev-num}, the value of the previous key '#{$prev-key}' !\";\n } @else if $prev-num >= $num {\n @warn \"Invalid value for #{$map-name}: This map must be in ascending order, but key '#{$key}' has value #{$num} which isn't greater than #{$prev-num}, the value of the previous key '#{$prev-key}' !\";\n }\n $prev-key: $key;\n $prev-num: $num;\n }\n}\n\n// Starts at zero\n// Used to ensure the min-width of the lowest breakpoint starts at 0.\n@mixin _assert-starts-at-zero($map, $map-name: \"$grid-breakpoints\") {\n $values: map-values($map);\n $first-value: nth($values, 1);\n @if $first-value != 0 {\n @warn \"First breakpoint in #{$map-name} must start at 0, but starts at #{$first-value}.\";\n }\n}\n\n// Replace `$search` with `$replace` in `$string`\n// Used on our SVG icon backgrounds for custom forms.\n//\n// @author Hugo Giraudel\n// @param {String} $string - Initial string\n// @param {String} $search - Substring to replace\n// @param {String} $replace ('') - New value\n// @return {String} - Updated string\n@function str-replace($string, $search, $replace: \"\") {\n $index: str-index($string, $search);\n\n @if $index {\n @return str-slice($string, 1, $index - 1) + $replace + str-replace(str-slice($string, $index + str-length($search)), $search, $replace);\n }\n\n @return $string;\n}\n\n// See https://codepen.io/kevinweber/pen/dXWoRw\n@function escape-svg($string) {\n @if str-index($string, \"data:image/svg+xml\") {\n @each $char, $encoded in $escaped-characters {\n $string: str-replace($string, $char, $encoded);\n }\n }\n\n @return $string;\n}\n\n// Color contrast\n@function color-yiq($color, $dark: $yiq-text-dark, $light: $yiq-text-light) {\n $r: red($color);\n $g: green($color);\n $b: blue($color);\n\n $yiq: (($r * 299) + ($g * 587) + ($b * 114)) / 1000;\n\n @if ($yiq >= $yiq-contrasted-threshold) {\n @return $dark;\n } @else {\n @return $light;\n }\n}\n\n// Retrieve color Sass maps\n@function color($key: \"blue\") {\n @return map-get($colors, $key);\n}\n\n@function theme-color($key: \"primary\") {\n @return map-get($theme-colors, $key);\n}\n\n@function gray($key: \"100\") {\n @return map-get($grays, $key);\n}\n\n// Request a theme color level\n@function theme-color-level($color-name: \"primary\", $level: 0) {\n $color: theme-color($color-name);\n $color-base: if($level > 0, $black, $white);\n $level: abs($level);\n\n @return mix($color-base, $color, $level * $theme-color-interval);\n}\n\n// Return valid calc\n@function add($value1, $value2, $return-calc: true) {\n @if $value1 == null {\n @return $value2;\n }\n\n @if $value2 == null {\n @return $value1;\n }\n\n @if type-of($value1) == number and type-of($value2) == number and comparable($value1, $value2) {\n @return $value1 + $value2;\n }\n\n @return if($return-calc == true, calc(#{$value1} + #{$value2}), $value1 + unquote(\" + \") + $value2);\n}\n\n@function subtract($value1, $value2, $return-calc: true) {\n @if $value1 == null and $value2 == null {\n @return null;\n }\n\n @if $value1 == null {\n @return -$value2;\n }\n\n @if $value2 == null {\n @return $value1;\n }\n\n @if type-of($value1) == number and type-of($value2) == number and comparable($value1, $value2) {\n @return $value1 - $value2;\n }\n\n @return if($return-calc == true, calc(#{$value1} - #{$value2}), $value1 + unquote(\" - \") + $value2);\n}\n","// stylelint-disable selector-no-qualifying-type\n\n//\n// Textual form controls\n//\n\n.form-control {\n display: block;\n width: 100%;\n height: $input-height;\n padding: $input-padding-y $input-padding-x;\n font-family: $input-font-family;\n @include font-size($input-font-size);\n font-weight: $input-font-weight;\n line-height: $input-line-height;\n color: $input-color;\n background-color: $input-bg;\n background-clip: padding-box;\n border: $input-border-width solid $input-border-color;\n\n // Note: This has no effect on