July 09, 2020

WebKitGTK 2.28.3 released!

by The WebKitGTK Project

This is a bug fix release in the stable 2.28 series.

What’s new in the WebKitGTK 2.28.3 release?

  • Enable kinetic scrolling with async scrolling.
  • Fix web process hangs on large GitHub pages.
  • Bubblewrap sandbox should not attempt to bind empty paths.
  • Fix threading issues in the media player.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

July 09, 2020 12:00 AM



July 08, 2020

WebKitGTK 2.29.3 released!

by The WebKitGTK Project

This is a development release leading toward 2.30 series.

What’s new in the WebKitGTK 2.29.3 release?

  • Add webkit_authentication_request_get_security_origin.
  • Change the cookies accept policy to always when no-third-party is set and ITP is enabled.
  • Fix web process hangs on large GitHub pages.
  • Bubblewrap sandbox should not attempt to bind empty paths.
  • Add support for sndio to bubblewrap sandbox.
  • Also handle dark themes when the name ends with -Dark.
  • Fix a race condition causing a crash in media player.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

July 08, 2020 12:00 AM



July 02, 2020

Web-augmented graphics overlay broadcasting with WPE and GStreamer

by Philippe Normand

Graphics overlays are everywhere nowadays in the live video broadcasting industry. In this post I introduce a new demo relying on GStreamer and WPEWebKit to deliver low-latency web-augmented video broadcasts.

Readers of this blog might remember a few posts about WPEWebKit and a GStreamer element we at Igalia worked on …

by Philippe Normand at July 02, 2020 01:00 PM



June 24, 2020

WebKitGTK 2.29.2 released!

by The WebKitGTK Project

This is a development release leading toward 2.30 series.

What’s new in the WebKitGTK 2.29.2 release?

  • Add Intelligent Tracking Prevention (ITP) support.
  • Add support for video formats in img elements.
  • Add API to handle video autoplay policy that now defaults to disallow autoplay videos with audio.
  • Add API to mute a web view.
  • Add API to allow applications to handle the HTTP authentication credential storage.
  • Add a WebKitSetting to set the media content types requiring hardware support.
  • Fix a crash during drag an drop due to a bug introduced in 2.29.1.
  • Do not start page load during animation in back/forward gesture.
  • Fix several crashes and rendering issues.
  • Translation updates: Ukrainian.

Thanks to all the contributors who made possible this release.

June 24, 2020 12:00 AM



June 16, 2020

WebKit Flatpak SDK and gst-build

by Víctor Jáquez

This post is an annex of Phil’s Introducing the WebKit Flatpak SDK. Please make sure to read it, if you haven’t already.

Recapitulating, nowadays WebKitGtk/WPE developers —and their CI infrastructure— are moving towards to Flatpak-based environment for their workflow. This Flatpak-based environment, or Flatpak SDK for short, can be visualized as a software sandboxed-container, which bundles all the dependencies required to compile, run and debug WebKitGtk/WPE.

In a day-by-day work, this approach removes the potential compilation of the world in order to obtain reproducible builds, improving the development and testing work flow.

But what if you are also involved in the development of one dependency?

This is the case of Igalia’s multimedia team where, besides developing the multimedia features for WebKitGtk and WPE, we also participate in the GStreamer development, the framework used for multimedia.

Because of this, in our workflow we usually need to build WebKit with a fix, hack or new feature in GStreamer. Is it possible to add in Flatpak our custom GStreamer build without messing its own GStreamer setup? Yes, it’s possible.

gst-build is a set of scripts in Python which clone GStreamer repositories, compile them and setup an uninstalled environment. This uninstalled environment allows a transient usage of the compiled framework from their build tree, avoiding installation and further mess up with our system.

The WebKit scripts that wraps Flatpak operations are also capable to handle the scripts of gst-build to build GStreamer inside the container, and, when running WebKit’s artifacts, the scripts enable the mentioned uninstalled environment, overloading Flatpak’s GStreamer.

How do we unveil all this magic?

First of all, setup a gst-build installation as it is documented. In this installation is were the GStreamer plumbing is done.

Later, gst-build operations through WebKit compilation scripts are enabled when the environment variable GST_BUILD_PATH is exported. This variable should point to the directory where the gst-build tree is placed.

And that’s all!

But let’s put these words in actual commands. The following workflow assumes that WebKit repository is cloned in ~/WebKit and the gst-build tree is in ~/gst-build (please, excuse my bashisms).

Compiling WebKitGtk with symbols, using LLVM as toolchain (this command will also compile GStreamer):

$ cd ~/WebKit
% CC=clang CXX=clang++ GST_BUILD_PATH=/home/vjaquez/gst-build Tools/Scripts/build-webkit --gtk --debug
...

Running the generated minibrowser (remind GST_BUILD_PATH is required again for a correct linking):

$ GST_BUILD_PATH=/home/vjaquez/gst-build Tools/Scripts/run-minibrowser --gtk --debug
...

Running media layout tests:

$ GST_BUILD_PATH=/home/vjaquez/gst-build ./Tools/Scripts/run-webkit-tests --gtk --debug media

But wait! There’s more...

What if you I want to parametrize the GStreamer compilation. To say, I would like to enable a GStreamer module or disable the built of a specific element.

gst-build, as the rest of GStreamer modules, uses meson build system, so it’s possible to pass arguments to meson through the environment variable GST_BUILD_ARGS.

For example, I would like to enable gstreamer-vaapi 😇

$ cd ~/WebKit
% CC=clang CXX=clang++ GST_BUILD_PATH=/home/vjaquez/gst-build GST_BUILD_ARGS="-Dvaapi=enabled" Tools/Scripts/build-webkit --gtk --debug
...

by vjaquez at June 16, 2020 11:49 AM



June 09, 2020

WebKitGTK and WPE now supporting videos in the img tag

by Philippe Normand

Using videos in the <img> HTML tag can lead to more responsive web-page loads in most cases. Colin Bendell blogged about this topic, make sure to read his post on the cloudinary website. As it turns out, this feature has been supported for more than 2 years in Safari, but …

by Philippe Normand at June 09, 2020 04:00 PM



June 08, 2020

Introducing the WebKit Flatpak SDK

by Philippe Normand

Working on a web-engine often requires a complex build infrastructure. This post documents our transition from JHBuild to Flatpak for the WebKitGTK and WPEWebKit development builds.

For the last 10 years, WebKitGTK has been relying on a custom JHBuild moduleset to handle its dependencies and (try to) ensure a reproducible …

by Philippe Normand at June 08, 2020 04:50 PM



May 18, 2020

WebKitGTK 2.29.1 released!

by The WebKitGTK Project

This is the first development release leading toward 2.30 series.

What’s new in the WebKitGTK 2.29.1 release?

  • Stop using GTK theming to render form controls.
  • Add API to disable GTK theming for scrollbars too.
  • Fix several race conditions and threading issues in the media player.
  • Add USER_AGENT_BRANDING build option.
  • Add paste as plain text option to the context menu for rich editable content.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

May 18, 2020 12:00 AM



April 27, 2020

WebKitGTK and WPE WebKit Security Advisory WSA-2020-0005

by The WebKitGTK Project

Several vulnerabilities were discovered in WebKitGTK and WPE WebKit.

  • CVE-2020-3885
    • Versions affected: WebKitGTK before 2.28.0 and WPE WebKit before 2.28.0.
    • Credit to Ryan Pickren (ryanpickren.com).
    • Impact: A file URL may be incorrectly processed. Description: A logic issue was addressed with improved restrictions.
  • CVE-2020-3894
    • Versions affected: WebKitGTK before 2.28.0 and WPE WebKit before 2.28.0.
    • Credit to Sergei Glazunov of Google Project Zero.
    • Impact: An application may be able to read restricted memory. Description: A race condition was addressed with additional validation.
  • CVE-2020-3895
    • 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.
  • CVE-2020-3897
    • 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.
  • CVE-2020-3899
    • 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.
  • CVE-2020-3900
    • 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.
  • CVE-2020-3901
    • 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.
  • CVE-2020-3902
    • 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.

Further information about WebKitGTK and WPE WebKit security advisories can be found at: https://webkitgtk.org/security.html or https://wpewebkit.org/security/.

April 27, 2020 12:00 AM



April 24, 2020

WebKitGTK 2.28.2 released!

by The WebKitGTK Project

This is a bug fix release in the stable 2.28 series.

What’s new in the WebKitGTK 2.28.2 release?

  • Fix excessive CPU usage due to GdkFrameClock not being stopped.
  • Fix UI process crash when EGL_WL_bind_wayland_display extension is not available.
  • Fix position of select popup menus in X11.
  • Fix playing of Youtube ‘live stream’/H264 URLs.
  • Fix a crash under X11 when cairo uses xcb.
  • Fix the build in MIPS64.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

April 24, 2020 12:00 AM



April 16, 2020

WebKitGTK and WPE WebKit Security Advisory WSA-2020-0004

by The WebKitGTK Project

  • Date Reported: April 16, 2020

  • Advisory ID: WSA-2020-0004

  • CVE identifiers: CVE-2020-11793.

Several vulnerabilities were discovered in WebKitGTK and WPE WebKit.

  • CVE-2020-11793
    • 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.

Further information about WebKitGTK and WPE WebKit security advisories can be found at: https://webkitgtk.org/security.html or https://wpewebkit.org/security/.

April 16, 2020 12:00 AM



April 13, 2020

WebKitGTK 2.28.1 released!

by The WebKitGTK Project

This is the first bug fix release in the stable 2.28 series.

What’s new in the WebKitGTK 2.28.1 release?

  • Fix position of default option element popup windows under Wayland.
  • Fix rendering after a cross site navigation with PSON enabled and hardware acceleration forced.
  • Fix a crash in nested wayland compositor when closing a tab with PSON enabled.
  • Update Chrome and Firefox versions in user agent quirks.
  • Fix a crash with bubblewrap sandbox enabled.
  • Fix a crash in JavaScriptCore in ppc64el.
  • Fix the build with GStreamer 1.12.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

April 13, 2020 12:00 AM



March 31, 2020

Sandboxing WebKitGTK Apps

by Michael Catanzaro

When you connect to a Wi-Fi network, that network might block your access to the wider internet until you’ve signed into the network’s captive portal page. An untrusted network can disrupt your connection at any time by blocking secure requests and replacing the content of insecure requests with its login page. (Of course this can be done on wired networks as well, but in practice it mainly happens on Wi-Fi.) To detect a captive portal, NetworkManager sends a request to a special test address (e.g. http://fedoraproject.org/static/hotspot.txt) and checks to see whether it the content has been replaced. If so, GNOME Shell will open a little WebKitGTK browser window to display http://nmcheck.gnome.org, which, due to the captive portal, will be hijacked by your hotel or airport or whatever to display the portal login page. Rephrased in security lingo: an untrusted network may cause GNOME Shell to load arbitrary web content whenever it wants. If that doesn’t immediately sound dangerous to you, let’s ask me from four years ago why that might be bad:

Web engines are full of security vulnerabilities, like buffer overflows and use-after-frees. The details don’t matter; what’s important is that skilled attackers can turn these vulnerabilities into exploits, using carefully-crafted HTML to gain total control of your user account on your computer (or your phone). They can then install malware, read all the files in your home directory, use your computer in a botnet to attack websites, and do basically whatever they want with it.

If the web engine is sandboxed, then a second type of attack, called a sandbox escape, is needed. This makes it dramatically more difficult to exploit vulnerabilities.

The captive portal helper will pop up and load arbitrary web content without user interaction, so there’s nothing you as a user could possibly do about it. This makes it a tempting target for attackers, so we want to ensure that users are safe in the absence of a sandbox escape. Accordingly, beginning with GNOME 3.36, the captive portal helper is now sandboxed.

How did we do it? With basically one line of code (plus a check to ensure the WebKitGTK version is new enough). To sandbox any WebKitGTK app, just call webkit_web_context_set_sandbox_enabled(). Ta-da, your application is now magically secure!

No, really, that’s all you need to do. So if it’s that simple, why isn’t the sandbox enabled by default? It can break applications that use WebKitWebExtension to run custom code in the sandboxed web process, so you’ll need to test to ensure that your application still works properly after enabling the sandbox. (The WebKitGTK sandbox will become mandatory in the future when porting applications to GTK 4. That’s thinking far ahead, though, because GTK 4 isn’t supported yet at all.) You may need to use webkit_web_context_add_path_to_sandbox() to give your web extension access to directories that would otherwise be blocked by the sandbox.

The sandbox is critically important for web browsers and email clients, which are constantly displaying untrusted web content. But really, every app should enable it. Fix your apps! Then thank Patrick Griffis from Igalia for developing WebKitGTK’s sandbox, and the bubblewrap, Flatpak, and xdg-desktop-portal developers for providing the groundwork that makes it all possible.

by Michael Catanzaro at March 31, 2020 03:56 PM



March 16, 2020

Review of the Igalia Multimedia team Activities (2019/H2)

by Víctor Jáquez

This blog post is a review of the various activities the Igalia Multimedia team was involved along the second half of 2019.

Here are the previous 2018/H2 and 2019/H1 reports.

GstWPE

Succinctly, GstWPE is a GStreamer plugin which allows to render web-pages as a video stream where it frames are GL textures.

Phil, its main author, wrote a blog post explaning at detail what is GstWPE and its possible use-cases. He wrote a demo too, which grabs and previews a live stream from a webcam session and blends it with an overlay from wpesrc, which displays HTML content. This composited live stream can be broadcasted through YouTube or Twitch.

These concepts are better explained by Phil himself in the following lighting talk, presented at the last GStreamer Conference in Lyon:

Video Editing

After implementing a deep integration of the GStreamer Editing Services (a.k.a GES) into Pixar’s OpenTimelineIO during the first half of 2019, we decided to implement an important missing feature for the professional video editing industry: nested timelines.

Toward that goal, Thibault worked with the GSoC student Swayamjeet Swain to implement a flexible API to support nested timelines in GES. This means that users of GES can now decouple each scene into different projects when editing long videos. This work is going to be released in the upcoming GStreamer 1.18 version.

Henry Wilkes also implemented the support for nested timeline in OpenTimelineIO making GES integration one of the most advanced one as you can see on that table:

Feature OTIO EDL FCP7 XML FCP X AAF RV ALE GES
Single Track of Clips ✔ ✔ ✔ ✔ ✔ W-O ✔ ✔
Multiple Video Tracks ✔ ✖ ✔ ✔ ✔ W-O ✔ ✔
Audio Tracks & Clips ✔ ✔ ✔ ✔ ✔ W-O ✔ ✔
Gap/Filler ✔ ✔ ✔ ✔ ✔ ✔ ✖ ✔
Markers ✔ ✔ ✔ ✔ ✖ N/A ✖ ✔
Nesting ✔ ✖ ✔ ✔ ✔ W-O ✔ ✔
Transitions ✔ ✔ ✖ ✖ ✔ W-O ✖ ✔
Audio/Video Effects ✖ ✖ ✖ ✖ ✖ N/A ✖ ✔
Linear Speed Effects ✔ ✔ ✖ ✖ R-O ✖ ✖ ✖
Fancy Speed Effects ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖
Color Decision List ✔ ✔ ✖ ✖ ✖ ✖ N/A ✖

Along these lines, Thibault delivered a 15 minutes talk, also in the GStreamer Conference 2019:

After detecting a few regressions and issues in GStreamer, related to frame accuracy, we decided to make sure that we can seek in a perfectly frame accurate way using GStreamer and the GStreamer Editing Services. In order to ensure that, an extensive integration testsuite has been developed, mostly targeting most important container formats and codecs (namely mxf, quicktime, h264, h265, prores, jpeg) and issues have been fixed in different places. On top of that, new APIs are being added to GES to allow expressing times in frame number instead of nanoseconds. This work is still ongoing but should be merged in time for GStreamer 1.18.

GStreamer Validate Flow

GstValidate has been turning into one of the most important GStreamer testing tools to check that elements behave as they are supposed to do in the framework.

Along with our MSE work, we found that other way to specify tests, related with produced buffers and events through specific pads, was needed. Thus, Alicia developed a new plugin for GstValidate: Validate Flow.

Alicia gave an informative 30 minutes talk about GstValidate and the new plugin in the last GStreamer Conference too:

GStreamer VAAPI

Most of the work along the second half of 2019 were maintenance tasks and code reviews.

We worked mainly on memory restrictions per backend driver, and we reviewed a big refactor: internal encoders now use GstObject, instead of the custom GstVaapiObject. Also we reviewed patches for new features such as video rotation and cropping in vaapipostproc.

Servo multimedia

Last year we worked integrating media playing in Servo. We finally delivered hardware accelerated video playback in Linux and Android. We worked also for Windows and Mac ports but they were not finished. As natural, most of the work were in servo/media crate, pushing code and reviewing contributions. The major tasks were to rewrite the media player example and the internal source element looking to handle the download playbin‘s flag properly.

We also added WebGL integration support with <video> elements, thus webpages can use video frames as WebGL textures.

Finally we explored how to isolate the multimedia processing in a dedicated thread or process, but that task remains pending.

WebKit Media Source Extension

We did a lot of downstream and upstream bug fixing and patch review, both in WebKit and GStreamer, for our MSE GStreamer-based backend.

Along this line we improved WebKitMediaSource to use playbin3 but also compatibility with older GStreamer versions was added.

WebKit WebRTC

Most of the work in this area were maintenance and fix regressions uncovered by the layout tests. Besides, the support for the Rasberry Pi was improved by handling encoded streams from v4l2 video sources, with some explorations with Minnowboard on top of that.

Conferences

GStreamer Conference

Igalia was Gold sponsor this last GStreamer Conference held in Lyon, France.

All team attended and five talks were delivered. Only Thibault presented, besides the video editing one which we already referred, another two more: One about GstTranscoder API and the other about the new documentation infrastructure based in Hotdoc:

We also had a productive hackfest, after the conference, where we worked on AV1 Rust decoder, HLS Rust demuxer, hardware decoder flag in playbin, and other stuff.

Linaro Connect

Phil attended the Linaro Connect conference in San Diego, USA. He delivered a talk about WPE/Multimedia which you can enjoy here:

Demuxed

Charlie attended Demuxed, in San Francisco. The conference is heavily focused on streaming and codec engineering and validation. Sadly there are not much interest in GStreamer, as the main focus is on FFmpeg.

RustFest

Phil and I attended the last RustFest in Barcelona. Basically we went to meet with the Rust community and we attended the “WebRTC with GStreamer-rs” workshop presented by Sebastian Dröge.

by vjaquez at March 16, 2020 03:20 PM



March 12, 2020

WebKitGTK and WPE WebKit Security Advisory WSA-2020-0003

by The WebKitGTK Project

  • Date Reported: March 12, 2020

  • Advisory ID: WSA-2020-0003

  • CVE identifiers: CVE-2020-10018.

Several vulnerabilities were discovered in WebKitGTK and WPE WebKit.

  • CVE-2020-10018
    • 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.

Further information about WebKitGTK and WPE WebKit security advisories can be found at: https://webkitgtk.org/security.html or https://wpewebkit.org/security/.

March 12, 2020 12:00 AM



March 11, 2020

Epiphany 3.36 and WebKitGTK 2.28

by Michael Catanzaro

So, what’s new in Epiphany 3.36?

PDF.js

Once upon a time, beginning with GNOME 3.14, Epiphany had supported displaying PDF documents via the Evince NPAPI browser plugin developed by Carlos Garcia Campos. Unfortunately, because NPAPI plugins have to use X11-specific APIs to draw web content, this didn’t  suffice for very long. When GNOME switched to Wayland by default in GNOME 3.24 (yes, that was three years ago!), this functionality was left behind. Using an NPAPI plugin also meant the code was inherently unsandboxable and tied to a deprecated technology. Epiphany disabled support for NPAPI plugins by default in Epiphany 3.30, hiding the functionality behind a hidden setting, which has now finally been removed for Epiphany 3.36, killing off NPAPI for good.

Jan-Michael Brummer, who comaintains Epiphany with me, tried bringing back PDF support for Epiphany 3.34 using libevince, but eventually we decided to give up on this approach due to difficulty solving some user experience issues. Also, the rendering occurred in the unsandboxed UI process, which was again not good for security.

But PDF support is now back in Epiphany 3.36, and much better than before! Thanks to Jan-Michael, Epiphany now supports displaying PDFs using the amazing PDF.js. We are thankful for Mozilla’s work in developing PDF.js and open sourcing it for us to use. Viewing PDFs in Epiphany using PDF.js is more convenient than downloading them and opening them in Evince, and because the PDF is rendered in the sandboxed web process, using web technologies rather than poppler, it’s also approximately one bazillion times more secure.

Screenshot of Epiphany displaying a PDF document
Look, it’s a PDF!

One limitation of PDF.js is that it does not support forms. If you need to fill out PDF forms, you’ll need to download the PDF and open it in Evince, just as you would if using Firefox.

Dark Mode

Thanks to Carlos Garcia, it should finally be possible to use Epiphany with dark GTK themes. WebKitGTK has historically rendered HTML elements using the GTK theme, which has not been good for users of dark themes, which broke badly on many websites, usually due to dark text being drawn on dark backgrounds or various other problems with unexpected dark widgets. Since WebKitGTK 2.28, WebKit will try to manually change to a light GTK theme when it thinks a dark theme is in use, then use the light theme to render web content. (This work has actually been backported to WebKitGTK 2.26.4, so you don’t need to upgrade to WebKitGTK 2.28 to benefit, but the work landed very recently and we haven’t blogged about it yet.) Thanks to Cassidy James from elementary for providing example pages for testing dark mode behavior.

Screenshot demonstrating broken dark mode support
Broken dark mode support prior to WebKitGTK 2.26.4. Notice that the first two pages use dark color schemes when light color schemes are expected, and the dark blue links are hard to read over the dark gray background. Also notice that the text in the second image is unreadable.
Screenshot demonstrating fixed dark mode support in WebKitGTK 2.26.4
Since WebKitGTK 2.26.4, dark mode works as it does in most other browsers. Websites that don’t support dark mode are light, and websites that do support dark mode are dark. Widgets themed using GTK are always light.

Since Carlos had already added support for the prefers-color-scheme media query last year, this now gets us up to dark mode parity with most browsers, except, notably, Safari. Unlike other browsers, Safari allows websites to opt-in to rendering dark system widgets, like WebKitGTK used to do before these changes. Whether to support this in WebKitGTK remains to-be-determined.

Process Swap on Navigation (PSON)

PSON, which debuted in Safari 13, is a major change in WebKit’s process model. PSON is the first component of site isolation, which Chrome has supported for some time, and which Firefox is currently working towards. If you care about web security, you should care a lot about site isolation, because the web browser community has arrived at a consensus that this is the best way to mitigate speculative execution attacks.

Nowadays, all modern web browsers use separate, sandboxed helper processes to render web content, ensuring that the main user interface process, which is unsandboxed, does not touch untrusted web content. Prior to 3.36, Epiphany already used a separate web process to display each browser tab (except for “related views,” where one tab opens another and gains scripting ability over the opened tab, subject to the Same Origin Policy). But in Epiphany 3.36, we now also have a separate web process per website. Each tab will swap between different web processes when navigating between different websites, to prevent any one web process from loading content from different websites.

To make these process swap navigations fast, a pool of prewarmed processes is used to hide the startup cost of launching a new process by ensuring the new process exists before it’s needed; otherwise, the overhead of launching a new web process to perform the navigation would become noticeable. And suspended processes live on after they’re no longer in use because they may be needed for back/forward navigations, which use WebKit’s page cache when possible. (In the page cache, pages are kept in memory indefinitely, to make back/forward navigations fast.)

Due to internal refactoring, PSON previously necessitated some API breakage in WebKitGTK 2.26 that affected Evolution and Geary: WebKitGTK 2.26 deprecated WebKit’s single web process model and required that all applications use one web process per web view, which Evolution and Geary were not, at the time, prepared to handle. We tried hard to avoid this, because we hate to make behavioral changes that break applications, but in this case we decided it was unavoidable. That was the status quo in 2.26, without PSON, which we disabled just before releasing 2.26 in order to limit application breakage to just Evolution and Geary. Now, in WebKitGTK 2.28, PSON is finally available for applications to use on an opt-in basis. (It will become mandatory in the future, for GTK 4 applications.) Epiphany 3.36 opts in. To make this work, Carlos Garcia designed new WebKitGTK APIs for cross-process communication, and used them to replace the private D-Bus server that Epiphany previously used for this purpose.

WebKit still has a long way to go to fully implement site isolation, but PSON is a major step down that road. Thanks to Brady Eidson and Chris Dumez from Apple for making this work, and to Carlos Garcia for handling most of the breakage (there was a lot). As with any major intrusive change of such magnitude, regressions are inevitable, so don’t hesitate to report issues on WebKit Bugzilla.

highlight.js

Once upon a time, WebKit had its own implementation for viewing page source, but this was removed from WebKit way back in 2014, in WebKitGTK 2.6. Ever since, Epiphany would open your default text editor, usually gedit, to display page source. Suffice to say that this was not a very satisfactory solution.

I finally managed to implement view source mode at the Epiphany level for Epiphany 3.30, but I had trouble making syntax highlighting work. I tried using various open source syntax highlighting libraries, but most are designed to highlight small amounts of code, not large web pages. The libraries I tried were not fast enough, so I gave up on syntax highlighting at the time.

Thanks to Jan-Michael, Epiphany 3.36 supports syntax highlighting using highlight.js, so we finally have view source mode working fully properly once again. It works much better than my failed attempts with different JS libraries. Please thank the highlight.js developers for maintaining this library, and for making it open source.

Screenshot displaying Epiphany's view source mode
Colors!

Service Workers

Service workers are now available in WebKitGTK 2.28. Our friends at Apple had already implemented service worker support a couple years ago for Safari 11, but we were pretty slow in bringing this functionality to Linux. Finally, WebKitGTK should now be up to par with Safari in this regard.

Cookies!

Patrick Griffis has updated libsoup and WebKitGTK to support SameSite cookies. He’s also tightened up our cookie policy by implementing strict secure cookies, which prevents http:// pages from setting secure cookies (as they could overwrite secure cookies set by https:// pages).

Adaptive Design

As usual, there are more adaptive design improvements throughout the browser, to provide a better user experience on the Librem 5. There’s still more work to be done here, but Epiphany continues to provide the best user experience of any Linux browser at small screen sizes. Thanks to Adrien Plazas and Jan-Michael for their continued work on this.

Screenshot showing Epiphany running in mobile mode at small window size.
As before, simply resize your browser window to see Epiphany dynamically transition between desktop mode and mobile mode.

elementary OS

With help from Alexander Mikhaylenko, we’ve also upstreamed many elementary OS design changes, which will be used when running under the Pantheon desktop (and not impact users on other desktops), so that the elementary developers don’t need to maintain their customizations as separate patches anymore. This will eliminate a few elementary-specific bugs, including some keyboard shortcuts that were previously broken only in elementary, and some odd tab bar behavior. Although Epiphany still doesn’t feel quite as native as an app designed just for elementary OS, it’s getting closer.

Epiphany 3.34

I failed to blog about Epiphany 3.34 when I released it last September. Hopefully you have updated to 3.34 already, and are already enjoying the two big features from this release: the new adblocker, and the bubblewrap sandbox.

The new adblocker is based on WebKit Content Blockers, which was developed by Apple several years ago. Adrian Perez developed new WebKitGTK API to expose this functionality, changed Epiphany to use it, and deleted Epiphany’s older resource-hungry adblocker that was originally copied from Midori. Previously, Epiphany kept a large GHashMap of compiled regexes in every web process, consuming a very significant amount of RAM for each process. It also took time to compile these regexes when launching each new web process. Now, the adblock filters are instead compiled into an efficient bytecode format that gets mmapped between all web processes to avoid excessive resource use. The bytecode is interpreted by WebKit itself, rather than by Epiphany’s web process extension (which Epiphany uses to execute custom code in WebKit’s web process), for greatly improved performance.

Lastly, Epiphany 3.34 enabled Patrick’s bubblewrap sandbox, which was added in WebKitGTK 2.26. Bubblewrap is an amazing sandboxing tool, already used effectively by flatpak and rpm-ostree, and I’m very pleased with Patrick’s decision to use it for WebKit as well. Because enabling the sandbox can break applications, it is currently opt-in for GTK 3 apps (but will become mandatory for GTK 4 apps). If your application uses WebKitGTK, you really need to take some time to enable this sandbox using webkit_web_context_set_sandbox_enabled(). The sandbox has introduced a couple regressions that we didn’t notice until too late; notably,  printing no longer works, which, half a year later, we still haven’t managed to fix yet. (I’ll try to get to it soon.)

OK, this concludes your 3.36 and 3.34 updates. Onward to 3.38!

by Michael Catanzaro at March 11, 2020 03:00 PM



March 10, 2020

WebKitGTK 2.28.0 released!

by The WebKitGTK Project

This is the first stable release in the 2.28 series.

Highlights of the WebKitGTK 2.28.0 release

  • Add API to enable Process Swap on (Cross-site) Navigation.
  • Add user messages API for the communication with the web extension.
  • Add support for same-site cookies.
  • Service workers are enabled by default.
  • Add support for Pointer Lock API.
  • Add flatpak sandbox support.
  • Make ondemand hardware acceleration policy never leave accelerated compositing mode.
  • Always use a light theme for rendering form controls.
  • Add about:gpu to show information about the graphics stack.

For more details about all the changes included in WebKitGTK 2.28 see the NEWS file that is included in the tarball.

Thanks to all the contributors who made possible this release.

March 10, 2020 12:00 AM



February 27, 2020

WebKitGTK 2.27.91 released!

by The WebKitGTK Project

This is a development release leading toward 2.28 series.

What’s new in the WebKitGTK 2.27.91 release?

  • Update user agent quirks to fix the unsupported browser message in several google services.
  • Fix several compile warnings with GCC 10.
  • Fix the build with GCC 10.
  • Fix several crashes and rendering issues.
  • Translation updates: Chinese

Thanks to all the contributors who made possible this release.

February 27, 2020 12:00 AM



February 14, 2020

WebKitGTK and WPE WebKit Security Advisory WSA-2020-0002

by The WebKitGTK Project

Several vulnerabilities were discovered in WebKitGTK and WPE WebKit.

  • CVE-2020-3862
    • 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.
  • CVE-2020-3864
    • Versions affected: WebKitGTK before 2.26.4 and WPE WebKit before 2.26.4.
    • Credit to Ryan Pickren (ryanpickren.com).
    • Impact: A DOM object context may not have had a unique security origin. Description: A logic issue was addressed with improved validation.
  • CVE-2020-3865
    • 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.
  • CVE-2020-3867
    • 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.
  • CVE-2020-3868
    • 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.

Further information about WebKitGTK and WPE WebKit security advisories can be found at: https://webkitgtk.org/security.html or https://wpewebkit.org/security/.

February 14, 2020 12:00 AM



WebKitGTK 2.26.4 released!

by The WebKitGTK Project

This is a bug fix release in the stable 2.26 series.

What’s new in the WebKitGTK 2.26.4 release?

  • Always use a light theme for rendering form controls.
  • Fix the build with WPE renderer disabled.
  • Fix the build with OpenGL disabled.
  • Fix the build with GCC 10.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

February 14, 2020 12:00 AM



February 10, 2020

WebKitGTK 2.27.90 released!

by The WebKitGTK Project

This is a development release leading toward 2.28 series.

What’s new in the WebKitGTK 2.27.90 release?

  • Add support for same-site cookies.
  • Add flatpak sandbox support.
  • Enable WebAudio and WebGL by default in WebKitSettings.
  • Add a setting to disallow top level navigation to a data URI.
  • Add support for the -webkit-font-smoothing CSS property.
  • Always use a light theme for rendering form controls.
  • Stop making the Web Inspector windows transient.
  • Ensure mouse cursor is hidden during fullscreen video playback.
  • Add support for inspecting service workers to the remote inspector.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

February 10, 2020 12:00 AM



January 23, 2020

WebKitGTK and WPE WebKit Security Advisory WSA-2020-0001

by The WebKitGTK Project

Several vulnerabilities were discovered in WebKitGTK and WPE WebKit.

  • CVE-2019-8835
    • 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.
  • CVE-2019-8844
    • 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.
  • CVE-2019-8846
    • 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.

Further information about WebKitGTK and WPE WebKit security advisories can be found at: https://webkitgtk.org/security.html or https://wpewebkit.org/security/.

January 23, 2020 12:00 AM



January 22, 2020

WebKitGTK 2.26.3 released!

by The WebKitGTK Project

This is a bug fix release in the stable 2.26 series.

What’s new in the WebKitGTK 2.26.3 release?

  • Fix issues while trying to play a video on NextCloud.
  • Make sure the GL video sink uses a valid WebKit shared GL context.
  • Fix vertical alignment of text containing arabic diacritics.
  • Fix build with icu 65.1.
  • Fix page loading errors with websites using HSTS.
  • Fix web process crash when displaying a KaTeX formula.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

January 22, 2020 12:00 AM



January 10, 2020

WebKitGTK 2.27.4 released!

by The WebKitGTK Project

This is a development release leading toward 2.28 series.

What’s new in the WebKitGTK 2.27.4 release?

  • Add API for input methods.
  • Add API to serialize/deserialize a JSCValue to/from a JSON string.
  • Add support for strict secure cookies.
  • Add support for saving data from remote inspector.
  • Make ondemand hardware acceleration policy never leave accelerated compositing mode.
  • Fix rendering of conic gradients in high resolution displays.
  • Fix special combination characters not respecting the keystroke order when high CPU load.
  • Honor the IndexedDB directory set in WebsiteDataManager.
  • Fix rendering of text when there’s an initial advance in the text run.
  • Fix web process crash when displaying a KaTeX formula.
  • Fix network process crash with PSON enabled.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

January 10, 2020 12:00 AM



December 08, 2019

HTML overlays with GstWPE, the demo

by Philippe Normand

Once again this year I attended the GStreamer conference and just before that, Embedded Linux conference Europe which took place in Lyon (France). Both events were a good opportunity to demo one of the use-cases I have in mind for GstWPE, HTML overlays!

As we, at Igalia, usually have a …

by Philippe Normand at December 08, 2019 02:00 PM



November 26, 2019

WebKitGTK 2.27.3 released!

by The WebKitGTK Project

This is a development release leading toward 2.28 series.

What’s new in the WebKitGTK 2.27.3 release?

  • Add support for Pointer Lock API.
  • Improve performance when falling back to system fonts.
  • Stop using DBus for the remote inspector implementation to improve the performance of both WebDriver and remote inspector.
  • Implement support for new ARIA roles: code, strong, emphasis, generic.
  • Fix handling of content type with new custom protocols implementation.
  • Make image decoders fully thread safe.
  • Add support for get page source command in WebDriver.
  • Add support for network proxy capabilities in WebDriver.
  • Add support for new window command in WebDriver.
  • Fix several crashes and rendering issues.
  • Translation updates: Brazilian Portuguese, Ukrainian.

Thanks to all the contributors who made possible this release.

November 26, 2019 12:00 AM



November 08, 2019

WebKitGTK and WPE WebKit Security Advisory WSA-2019-0006

by The WebKitGTK Project

Several vulnerabilities were discovered in WebKitGTK and WPE WebKit.

  • CVE-2019-8710
    • 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.
  • CVE-2019-8743
    • 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.
  • CVE-2019-8764
    • 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.
  • CVE-2019-8765
    • 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.
  • CVE-2019-8766
    • 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.
  • CVE-2019-8782
    • 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.
  • CVE-2019-8783
    • 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.
  • CVE-2019-8808
    • 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.
  • CVE-2019-8811
    • 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.
  • CVE-2019-8812
    • 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.
  • CVE-2019-8813
    • 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.
  • CVE-2019-8814
    • 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.
  • CVE-2019-8815
    • 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.
  • CVE-2019-8816
    • 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.
  • CVE-2019-8819
    • 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.
  • CVE-2019-8820
    • 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.
  • CVE-2019-8821
    • 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.
  • CVE-2019-8822
    • 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.
  • CVE-2019-8823
    • 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.

Further information about WebKitGTK and WPE WebKit security advisories can be found at: https://webkitgtk.org/security.html or https://wpewebkit.org/security/.

November 08, 2019 12:00 AM



November 06, 2019

WebKitGTK 2.26.2 released!

by The WebKitGTK Project

This is a bug fix release in the stable 2.26 series.

What’s new in the WebKitGTK 2.26.2 release?

  • Improve performance of querying system fallback fonts.
  • Don’t use prgname in dbus-proxy socket path.
  • Fix thread-safety issues in image decoders.
  • Fix the build with WebDriver disabled.
  • Disable accelerated compositing when we fail to initialize the EGL dispaly under Wayland.
  • Fill the objects category in emoji picker.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

November 06, 2019 12:00 AM



October 29, 2019

WebKitGTK and WPE WebKit Security Advisory WSA-2019-0005

by The WebKitGTK Project

Several vulnerabilities were discovered in WebKitGTK and WPE WebKit.

  • CVE-2019-8625
    • 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.
  • CVE-2019-8674
    • 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.
  • CVE-2019-8707
    • 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.
  • CVE-2019-8719
    • 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.
  • CVE-2019-8720
    • 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.
  • CVE-2019-8726
    • 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.
  • CVE-2019-8733
    • 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.
  • CVE-2019-8735
    • 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.
  • CVE-2019-8763
    • 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.
  • CVE-2019-8768
    • 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.
  • CVE-2019-8769
    • 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.
  • CVE-2019-8771
    • 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.

Further information about WebKitGTK and WPE WebKit security advisories can be found at: https://webkitgtk.org/security.html or https://wpewebkit.org/security/.

October 29, 2019 12:00 AM



October 22, 2019

WebKitGTK 2.27.2 released!

by The WebKitGTK Project

This is a development release leading toward 2.28 series.

What’s new in the WebKitGTK 2.27.2 release?

  • Add user messages API for the communication with the web extension.
  • Enable service workers by default.
  • Add support for saving data in Web Inspector.
  • More navigation gesture improvement.
  • Fix the build with WebDriver disabled.
  • Show also client EGL extensions in about:gpu.
  • Disable accelerated compositing when we fail to initialize the EGL dispaly under Wayland.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

October 22, 2019 12:00 AM



October 04, 2019

WebKitGTK 2.27.1 released!

by The WebKitGTK Project

This is the first development release leading toward 2.28 series.

What’s new in the WebKitGTK 2.27.1 release?

  • Enable async scrolling when accelerating compositing policy is ‘always’.
  • Add about:gpu to show information about the graphics stack.
  • Add API to enable Process Swap on (Cross-site) Navigation, that is now disabled by default.
  • Add WebKitWebView:page-id property.
  • Improve swipe navigation gesture style.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

October 04, 2019 12:00 AM



September 23, 2019

WebKitGTK 2.26.1 released!

by The WebKitGTK Project

This is the first bug fix release in the stable 2.26 series.

What’s new in the WebKitGTK 2.26.1 release?

  • Fix MSE media player with GStreamer 1.14.
  • Fix HTML alternate loads never finishing.
  • Fix web view initialization delay on fisrt load.
  • Validate user agent string set via API.
  • Fix a crash when a web view is destroyed with accelerated compositing mode enabled.
  • Fix EGL initialization with newer versions of Mesa.
  • Do not enable the sandbox inside docker.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

September 23, 2019 12:00 AM



September 18, 2019

Epiphany Technology Preview Users: Action Required

by Michael Catanzaro

Epiphany Technology Preview has moved from https://sdk.gnome.org to https://nightly.gnome.org. The old Epiphany Technology Preview is now end-of-life. Action is required to update. If you installed Epiphany Technology Preview prior to a couple minutes ago, uninstall it using GNOME Software and then reinstall using this new flatpakref.

Apologies for this disruption.

The main benefit to end users is that you’ll no longer need separate remotes for nightly runtimes and nightly applications, because everything is now hosted in one repo. See Abderrahim’s announcement for full details on why this transition is occurring.

by Michael Catanzaro at September 18, 2019 02:19 PM



September 09, 2019

WebKitGTK 2.26.0 released!

by The WebKitGTK Project

This is the first stable release in the 2.26 series.

Highlights of the WebKitGTK 2.26.0 release

  • Add support for subprocess sandboxing.
  • Add support for HSTS (HTTP Strict Transport Security).
  • Use libwpe with fdo backend to implement accelerated compositing under wayland.
  • Remove support for GTK2 NPAPI plugins.
  • Add support for datalist element in text input fields.
  • Show the emoji chooser popover for editable content.
  • Improve rendering of form controls when GTK theme is dark.
  • Fix rendering artifacts in youtube volume button and github comment box.
  • Single process model has been deprecated for security reasons.

For more details about all the changes included in WebKitGTK 2.26 see the NEWS file that is included in the tarball.

Thanks to all the contributors who made possible this release.

September 09, 2019 12:00 AM



September 08, 2019

WebKit Vulnerabilities Facilitate Human Rights Abuses

by Michael Catanzaro

Chinese state actors have recently abused vulnerabilities in the JavaScriptCore component of WebKit to hack the personal computing devices of Uighur Muslims in the Xinjiang region of China. Mass digital surveillance is a key component of China’s ongoing brutal human rights crackdown in the region.

This has resulted in a public relations drama that is largely a distraction to the issue at hand. Whatever big-company PR departments have to say on the matter, I have no doubt that the developers working on WebKit recognize the severity of this incident and are grateful to Project Zero, which reported these vulnerabilities and has previously provided numerous other high-quality private vulnerability reports. (Many other organizations deserve credit for similar reports, especially Trend Micro’s Zero Day Initiative.)

WebKit as a project will need to reassess certain software development practices that may have facilitated the abuse of these vulnerabilities. The practice of committing security fixes to open source long in advance of corresponding Safari releases may need to be reconsidered.

Sadly, Uighurs should assume their personal computing devices have been compromised by state-sponsored attackers, and that their private communications are not private. Even if not compromised in this particular incident, similar successful attacks are overwhelmingly likely in the future.

by Michael Catanzaro at September 08, 2019 05:32 PM



September 03, 2019

WebKitGTK 2.25.92 released!

by The WebKitGTK Project

This is a development release leading toward 2.26 series.

What’s new in the WebKitGTK 2.25.92 release?

  • 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.
  • Fix building without unified sources.
  • Fix several crashes and rendering issues.
  • Translation updates: Polish, Ukrainian.

Thanks to all the contributors who made possible this release.

September 03, 2019 12:00 AM



August 29, 2019

WebKitGTK and WPE WebKit Security Advisory WSA-2019-0004

by The WebKitGTK Project

Several vulnerabilities were discovered in WebKitGTK and WPE WebKit.

  • CVE-2019-8644
    • 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.
  • CVE-2019-8649
    • 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.
  • CVE-2019-8658
    • 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 universal cross site scripting. A logic issue was addressed with improved state management.
  • CVE-2019-8666
    • 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.
  • CVE-2019-8669
    • 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.
  • CVE-2019-8671
    • 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.
  • CVE-2019-8672
    • 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.
  • CVE-2019-8673
    • 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.
  • CVE-2019-8676
    • 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.
  • CVE-2019-8677
    • 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.
  • CVE-2019-8678
    • 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.
  • CVE-2019-8679
    • 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.
  • CVE-2019-8680
    • 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.
  • CVE-2019-8681
    • 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.
  • CVE-2019-8683
    • 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.
  • CVE-2019-8684
    • 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.
  • CVE-2019-8686
    • 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.
  • CVE-2019-8687
    • 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.
  • CVE-2019-8688
    • 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.
  • CVE-2019-8689
    • 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.
  • CVE-2019-8690
    • 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.

Further information about WebKitGTK and WPE WebKit security advisories can be found at: https://webkitgtk.org/security.html or https://wpewebkit.org/security/.

August 29, 2019 12:00 AM



August 28, 2019

WebKitGTK 2.24.4 released!

by The WebKitGTK Project

This is a bug fix release in the stable 2.24 series.

What’s new in the WebKitGTK 2.24.4 release?

  • Updated the user agent string to make happy certain websites which would claim that the browser being used was unsupported.
  • Improve loading of multimedia streams to avoid memory exhaustion due to excessive caching.
  • Fix display of documents with MIME type application/xml in the Web Inspector, when loaded using XmlHttpRequest.
  • Fix a hang while scrolling certain websites which include HLS video content (Twitter, for example).
  • Fix rounding artifacts in volume levels for media playback.
  • Fix several crashes and rendering issues.
  • Fix the build with video track support disabled.
  • Fix the build with OpenGL support disabled.
  • Fix build issue which would cause media controls to disappear when Python 3.x was used during the build process.

Thanks to all the contributors who made possible this release.

August 28, 2019 12:00 AM



August 05, 2019

Review of the Igalia Multimedia team Activities (2019/H1)

by Philippe Normand

This blog post takes a look back at the various Multimedia-related tasks the Igalia Multimedia team was involved in during the first half of 2019.

GStreamer Editing Services

Thibault added support for the OpenTimelineIO open format for editorial timeline information. Having many editorial timeline information formats supported by OpenTimelineIO reduces …

by Philippe Normand at August 05, 2019 01:30 PM



August 02, 2019

WebKitGTK 2.25.4 released!

by The WebKitGTK Project

This is a development release leading toward 2.26 series.

What’s new in the WebKitGTK 2.25.4 release?

  • Switch to use libsoup WebSockets API.
  • Add support for permessage-deflate WebSocket extension.
  • Add support for datalist element in text input fields.
  • Fix a crash with empty video source.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

August 02, 2019 12:00 AM



July 23, 2019

WebKitGTK 2.25.3 released!

by The WebKitGTK Project

This is a development release leading toward 2.26 series.

What’s new in the WebKitGTK 2.25.3 release?

  • Remove support for GTK2 NPAPI plugins.
  • Fix web view updates after swapping web process if accelerated compositing mode is forced.
  • Make kinetic scrolling work again.
  • Fix position of emoji chooser when page is scrolled.
  • Fix web process deadlock when scrolling twitter timeline which contains HLS videos.
  • Make navigation gesture use dark fallback background color color on dark themes.
  • Make Previous/Next gesture work in RTL mode.
  • Support cancelling touchscreen back/forward gesture.
  • Add user agent quirk to make github work in FreeBSD.
  • Fix content disappearing when using CSS transforms.
  • Fix some radio streams that could not be played.
  • Fix video pause that sometimes caused to skip to finish.
  • Fix volume level changes when playing a video.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

July 23, 2019 12:00 AM



July 02, 2019

WebKitGTK 2.24.3 released!

by The WebKitGTK Project

This is a bug fix release in the stable 2.24 series.

What’s new in the WebKitGTK 2.24.3 release?

  • Deprecate WebSQL APIs.
  • Make Previous/Next gesture work in RTL mode.
  • Fix content disappearing when using CSS transforms.
  • Fix rendering artifacts in youtube volume button.
  • Fix trapezoid artifact in github comment box.
  • Fix video pause that sometimes caused to skip to finish.
  • Fix volume level changes when playing a video.
  • Fix HLS streams being slow to start.
  • Fix some radio streams that could not be played.
  • Fix the build with older versions of GStreamer.
  • Fix the build with video and audio disabled.
  • Fix several crashes and rendering issues.
  • Translation updates: Brazilian Portuguese.

Thanks to all the contributors who made possible this release.

July 02, 2019 12:00 AM



June 28, 2019

On Version Numbers

by Michael Catanzaro

I’m excited to announce that Epiphany Tech Preview has reached version 3.33.3-33, as computed by git describe. That is 33 commits after 3.33.3:

Epiphany about dialog displaying the version number

I’m afraid 3.33.4 will arrive long before we  make it to 3.33.3-333, so this is probably the last cool version number Epiphany will ever have.

I might be guilty of using an empty commit to claim the -33 commit.

I might also apologize for wasting your time with a useless blog post, except this was rather fun. I await the controversy of your choice in the comments.

by Michael Catanzaro at June 28, 2019 04:07 PM



June 17, 2019

WebKitGTK 2.25.2 released!

by The WebKitGTK Project

This is a development release leading toward 2.26 series.

What’s new in the WebKitGTK 2.25.2 release?

  • Enable process switch on cross site navigation.
  • Use libwpe with fdo backend to implement accelerated compositing under wayland.
  • Fix rendering artifacts in youtube volume button.
  • Fix trapezoid artifact in github comment box.
  • Ensure web extensions directory is readable when sandbox is enabled.
  • Fix the executable name of WebDriver process, renamed by mistake in 2.25.1.
  • Enable hyperlink auditing setting by default.
  • Remove the option to build without using the redirected XComposite window.
  • Fix HLS streams being slow to start.
  • Make accessibility work when sandbox is enabled.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

June 17, 2019 12:00 AM



June 14, 2019

An OpenJPEG Surprise

by Michael Catanzaro

My previous blog post seems to have resolved most concerns about my requests for Ubuntu stable release updates, but I again received rather a lot of criticism for the choice to make WebKit depend on OpenJPEG, even though my previous post explained clearly why there are are not any good alternatives.

I was surprised to receive a pointer to ffmpeg, which has its own JPEG 2000 decoder that I did not know about. However, we can immediately dismiss this option due to legal problems with depending on ffmpeg. I also received a pointer to a resurrected libjasper, which is interesting, but since libjasper was removed from Ubuntu, its status is not currently better than OpenJPEG.

But there is some good news! I have looked through Ubuntu’s security review of the OpenJPEG code and found some surprising results. Half the reported issues affect the library’s companion tools, not the library itself. And the other half of the issues affect the libmj2 library, a component of OpenJPEG that is not built by Ubuntu and not used by WebKit. So while these are real security issues that raise concerns about the quality of the OpenJPEG codebase, none of them actually affect OpenJPEG as used by WebKit. Yay!

The remaining concern is that huge input sizes might cause problems within the library that we don’t yet know about. We don’t know because OpenJPEG’s fuzzer discards huge images instead of testing them. Ubuntu’s security team thinks there’s a good chance that fixing the fuzzer could uncover currently-unknown multiplication overflow issues, for instance, a class of vulnerability that OpenJPEG has clearly had trouble with in the past. It would be good to see improvement on this front. I don’t think this qualifies as a security vulnerability, but it is certainly a security problem that would facilitate discovering currently-unknown vulnerabilities if fixed.

Still, on the whole, the situation is not anywhere near as bad as I’d thought. Let’s hope OpenJPEG can be included in Ubuntu main sooner rather than later!

by Michael Catanzaro at June 14, 2019 02:43 PM



June 10, 2019

A new terminal-style line breaking with CSS Text

by Javier Fernández

The CSS Text 3 specification defines a module for text manipulation and covers, among a few other features, the line breaking behavior of the browser, including white space handling. I’ve been working lately on some new features and bug fixing for this specification and I’d like to introduce in this posts the last one we made available for the Web Platform users. This is yet another contribution that came out the collaboration between Igalia and Bloomberg, which has been held for several years now and has produced many important new features for the Web, like CSS Grid Layout.

The feature

I guess everybody knows the white-space CSS property, which allows web authors to control two main aspects of the rendering of a text line: collapsing and wrapping. A new value break-spaces has been added to the ones available for this property, which allows web authors to emulate a terminal-like line breaking behavior. This new value operates basically like pre-wrap, but with two key differences:

  • any sequence of preserved white space characters takes up space, even at the end of the line.
  • a preserved white space sequence can be wrapped at any character, moving the rest of the sequence, intact, to the line bellow.

What does this new behavior actually mean ? I’ll try to explain it with a few examples. Lets start with a simple but quite illustrative demo which tries to emulate a meteorology monitoring system which shows relevant changes over time, where the gaps between subsequent changes must be preserved:




    

Another interesting use case for this feature could be a logging system which should preserve the text formatting of the logged information, considering different window sizes. The following demo tries to describe this such scenario:



Hash: 5a2a3d23f88174970ed8 Version: webpack 3.12.0 Time: 22209ms Asset Size Chunks Chunk Names pages/widgets/index.51838abe9967a9e0b5ff.js 1.17 kB 10 [emitted] pages/widgets/index img/icomoon.7f1da5a.svg 5.38 kB [emitted] fonts/icomoon.2d429d6.ttf 2.41 kB [emitted] img/fontawesome-webfont.912ec66.svg 444 kB [emitted] [big] fonts/fontawesome-webfont.b06871f.ttf 166 kB [emitted] img/mobile.8891a7c.png 39.6 kB [emitted] img/play_button.6b15900.png 14.8 kB [emitted] img/keyword-back.f95e10a.jpg 43.4 kB [emitted] . . .

Use cases

In the demo shown before there are several cases that I think it’s worth to analyze in detail.

A breaking opportunity exists after any white space character

The main purpose of this feature is to preserve the white space sequences length even when it has to be wrapped into multiple lines. The following example tries to describe this basic use case:



XX XX

The example above shows how the white space sequence with a length of 15 characters is preserved and wrapped along 3 different lines.

Single leading white space

Before the addition of the break-spaces value this scenario was only possible at the beginning of the line. In any other case, the trailing white spaces were either collapsed or hang, hence the next line couldn’t start with a sequence of white spaces. Lets consider the following example:



XX XX

Like when using pre-wrap, the single leading space is preserved. Since break-spaces allows breaking opportunities after any white space character, we break after the first leading white space (” |XX XX”). The second line can be broken after the first preserved white space, creating another leading white space in the next line (” |XX | XX”).

However, lets consider now a case without such first single leading white space.



XXX XX

Again, it s not allowed to break before the first space, but in this case there isn’t any previous breaking opportunity, so the first space after the word XX should overflow (“XXX | XX”); the next white space character will be moved down to the next line as preserved leading space.

Breaking before the first white space

I mentioned before that the spec states clearly that the break-space feature allows breaking opportunities only after white space characters. However, it’d be possible to break the line just before the first white space character after a word if the feature is used in combination with other line breaking CSS properties, like word-break or overflow-wrap (and other properties too).



XXXX X

The two white spaces between the words are preserved due to the break-spaces feature, but the first space after the XXXX word would overflow. Hence, the overflow-wrap: break-word feature is applied to prevent the line to overflow and introduce an additional breaking opportunity just before the first space after the word. This behavior causes that the trailing spaces are moved down as a leading white space sequence in the next line.

We would get the same rendering if word-break: break-all is used instead overflow-wrap (or even in combination), but this is actualy an incorrect behavior, which has the corresponding bug reports in WebKit (197277) and Blink (952254) according to the discussion in the CSS WG (see issue #3701).

Consider previous breaking opportunities

In the previous example I described a combination of line breaking features that would allow breaking before the first space after a word. However, this should be avoided if there are previous breaking opportunities. The following example is one of the possible scenarios where this may happen:



XX X X

In this case, we could break after the second word (“XX X| X”), since overflow-wrap: break-word would allow us to do that in order to avoid the line to overflow due to the following white space. However, white-space: break-spaces only allows breaking opportunities after a space character, hence, we shouldn’t break before if there are valid previous opportunities, like in this case in the space after the first word (“XX |X X”).

This preference for previous breaking opportunities before breaking the word, honoring the overflow-wrap property, is also part of the behavior defined for the white-space: pre-wrap feature; although in that case, there is no need to deal with the issue of breaking before the first space after a word since trailing space will just hang. The following example uses just the pre-wrap to show how previous opportunities are selected to avoid overflow or breaking a word (unless explicitly requested by word-break property).



XX
overflow-wrap:
break-word
word-break:
break-all

In this case, break-all enables breaking opportunities that are not available otherwise (we can break a word at any letter), which can be used to prevent the line to overflow; hence, the overflow-wrap property doesn’t take any effect. The existence of previous opportunities is not considered now, since break-all mandates to produce the longer line as possible.

This new white-space: break-spaces feature implies a different behavior when used in combination with break-all. Even though the preference of previous opportunities should be ignored if we use the word-break: break-all, this may not be the case for the breaking before the first space after a word scenario. Lets consider the same example but using now the word-break: break-all feature:



XX X X

The example above shows that using word-break: break-all doesn’t produce any effect. It’s debatable whether the use of break-all should force the selection of the breaking opportunity that produces the longest line, like it happened in the pre-wrap case described before. However, the spec states clearly that break-spaces should only allow breaking opportunities after white space characters. Hence, I considered that breaking before the first space should only happen if there is no other choice.

As a matter of fact, specifying break-all we shouldn’t considering only previous white spaces, to avoid breaking before the first white space after a word; the break-all feature creates additional breaking opportunities, indeed, since it allows to break the word at any character. Since break-all is intended to produce the longest line as possible, this new breaking opportunity should be chosen over any previous white space. See the following test case to get a clearer idea of this scenario:



X XX X

Bear in mind that the expected rendering in the above example may not be obtained if your browser’s version is still affected by the bugs 197277(Safari/WebKit) and 952254(Chrome/Blink). In this case, the word is broken despite the opportunity in the previous white space, and also avoiding breaking after the ‘XX’ word, just before the white space.

There is an exception to the rule of avoiding breaking before the first white space after a word if there are previous opportunities, and it’s precisely the behavior the line-break: anywhere feature would provide. As I said, all these assumptions were not, in my opinion, clearly defined in the current spec, so that’s why I filed an issue for the CSS WG so that we can clarify when it’s allowed to break before the first space.

Current status and support

The intent-to-ship request for Chrome has been approved recently, so I’m confident the feature will be enabled by default in Chrome 76. However, it’s possible to try the feature in older versions by enabling the Experimental Web Platform Features flag. More details in the corresponding Chrome Status entry. I want to highlight that I also implemented the feature for LayoutNG, the new layout engine that Chrome will eventually ship; this achievement is very important to ensure the stability of the feature in future versions of Chrome.

In the case of Safari, the patch with the implementation of the feature landed in the WebKit’s trunk in r244036, but since Apple doesn’t announce publicly when a new release of Safari will happen or which features it’ll ship, it’s hard to guess when the break-spaces feature will be available for the web authors using such browser. Meanwhile, It’s possible to try the feature in the Safari Technology Preview 80.

Finally, while I haven’t see any signal of active development in Firefox, some of the Mozilla developers working on this area of the Gecko engine have shown public support for the feature.

The following table summarizes the support of the break-spaces feature in the 3 main browsers:

Chrome Safari Firefox
Experimental M73 STP 80 Public support
Ship M76 Unknown Unknown

Web Platform Tests

At Igalia we believe that the Web Platform Tests project is a key piece to ensure the compatibility and interoperability of any development on the Web Platform. That’s why a substantial part of my work to implement this relatively small feature was the definition of enough tests to cover the new functionality and basic use cases of the feature.

white-space overflow-wrap word-break
pre-wrap-008
pre-wrap-015
pre-wrap-016
break-spaces-003
break-spaces-004
break-spaces-005
break-spaces-006
break-spaces-007
break-spaces-008
break-spaces-009
break-word-004
break-word-005
break-word-006
break-word-007
break-word-008
break-all-010
break-all-011
break-all-012
break-all-013
break-all-014
break-all-015

Implementation in several web engines

During the implementation of a browser feature, even a small one like this, it’s quite usual to find out bugs and interoperability issues. Even though this may slow down the implementation of the feature, it’s also a source of additional Web Platform tests and it may contribute to the robustness of the feature itself and the related CSS properties and values. That’s why I decided to implement the feature in parallel for WebKit (Safari) and Blink (Chrome) engines, which I think it helped to ensure interoperability and code maturity. This approach also helped to get a deeper understanding of the line breaking logic and its design and implementation in different web engines.

I think it’s worth mentioning some of these code architectural differences, to get a better understanding of the work and challenges this feature required until it reached web author’s browser.

Chrome/Blink engine

Lets start with Chrome/Blink, which was especially challenging due to the fact that Blink is implementing a new layout engine (LayoutNG). The implementation for the legacy layout engine was the first step, since it ensures the feature will arrive earlier, even behind an experimental runtime flag.

The legacy layout relies on the BreakingContext class to implement the line breaking logic for the inline layout operations. It has the main characteristic of handling the white space breaking opportunities by its own, instead of using the TextBreakIterator (based on ICU libraries), as it does for determining breaking opportunities between letters and/or symbols. This design implies too much complexity to do even small changes like this, especially because is very sensible in terms of performance impact. In the following diagram I try to show a simplified view of the classes involved and the interactions implemented by this line breaking logic.

The LayoutNG line breaking logic is based on a new concept of fragments, mainly handled by the NGLineBreaker class. This new design simplifies the line breaking logic considerably and it’s highly optimized and adapted to get the most of the TextBreakIterator classes and the ICU features. I tried to show a simplified view of this new design with the following diagram:

In order to describe the work done to implement the feature for this web engine, I’ll list the main bugs and patches landed during this time: CR#956465, CR#952254, CR#944063,CR#900727, CR#767634, CR#922437

Safari/WebKit engine

Although as time passes this is less probable, WebKit and Blink still share some of the layout logic from the ages prior to the fork. Although Blink engineers have applied important changes to the inline layout logic, both code refactoring and optimizations, there are common design patterns that made relatively easy porting to WebKit the patches that implemented the feature for the Blink’s legacy layout. In WebKit, the line breaking logic is also implemented by the BreakingContext class and it has a similar architecture, as it’s described, in a quite simplified way, in the class diagram above (it uses different class names for the render/layout objects, though) .

However, Safari supports for the mac and iOS platforms a different code path for the line breaking logic, implemented in the SimpleLineLayout class. This class provides a different design for the line breaking logic, and, similar to what Blink implements in LayoutNG, is based on a concept of text fragments. It also relies as much as possible into the TextBreakIterator, instead of implementing complex rules to handle white spaces and breaking opportunities. The following diagrams show this alternate design to implement the line breaking process.

This SimpleLineLayout code path in not supported by other WebKit ports (like WebKitGtk+ or WPE) and it’s not available either when using some CSS Text features or specific fonts. There are other limitations to use this SimpleLineLayout codepath, which may lead to render the text using the BreakingContext class.

Again, this is the list of bugs that were solved to implement the feature for the WebKit engine: WK#197277, WK#196169, WK#196353, WK#195361, WK#177327, WK#197278

Conclusion

I hope that at this point these 2 facts are clear now:

  • The white-space: break-spaces feature is a very simple but powerful feature that provides a new line breaking behavior, based on unix-terminal systems.
  • Although it’s a simple feature, on the paper (spec), it implies a considerable amount of work so that it reaches the browser and it’s available for web authors.

In this post I tried to explain in a simple way the main purpose of this new feature and also some interesting corner cases and combinations with other Line Breaking features. The demos I used shown 2 different use cases of this feature, but there are may more. I’m sure the creativity of web authors will push the feature to the limits; by then, I’ll be happy to answer doubts, about the spec or the implementation for the web engines, and of course fix the bugs that may appear once the feature is more used.

Igalia logo
Bloomberg logo

Igalia and Bloomberg working together to build a better web

Finally, I want to thank Bloomberg for supporting the work to implement this feature. It’s another example of how non-browser vendors can influence the Web Platform and contribute with actual features that will be eventually available for web authors. This is the kind of vision that we need if we want to keep a healthy, open and independent Web Platform.

by jfernandez at June 10, 2019 08:11 PM



May 27, 2019

WebKitGTK 2.25.1 released!

by The WebKitGTK Project

This is the first development release leading toward 2.26 series.

What’s new in the WebKitGTK 2.25.1 release?

  • Add support for subprocess sandboxing.
  • Add API to get the web process unique identifier of a WebKitFrame.
  • Add WebKitWebPage::did-associate-form-controls-for-frame signal and deprecate did-associate-form-controls.
  • Implement AtkComponentIface scroll_to methods.
  • Improve rendering of form controls when GTK theme is dark and enable prefers-color-scheme media query.
  • Show the emoji chooser popover for editable content.
  • Fix touch capabilities detection for websites checking touch events properties present in window or pointer media queries.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

May 27, 2019 12:00 AM



May 24, 2019

Dear Ubuntu: Please Stop Packaging Epiphany If You Won’t Do It Properly

by Michael Catanzaro

Dear Ubuntu,

When users try Epiphany on Ubuntu, they receive a sub-par, broken browser. If you’re not willing to do this right, please just remove Epiphany from your repositories. We’d all be happier this way. You are the  most popular distributor of Epiphany by far, and your poor packaging is making the browser look bad.

Epiphany 3.28.1 Is Stupid Old

Currently you’ve packaged Epiphany 3.28.1 for Ubuntu 18.04, your current LTS release. 3.28.1 is a seriously broken version with an overaggressive adblock filters subscription that blocks legitimate resources on a wide variety of websites, resulting in broken page rendering. We obviously don’t want users to ever use 3.28.1. There is a 3.28.2, released on May 22, 2018, which fixes this problem, but after one year you have still not yet updated. Ideally you would update to 3.28.5, which has been available since September 21, 2018. It’s not like I’m expecting you to upgrade to 3.30 or to 3.32 (the current stable series). I’d be happy to release a 3.28.6, except I know that it’s pointless: you would not upgrade to it if I did.

In Ubuntu 19.04, you have packaged Epiphany 3.32.0. The current version is 3.32.2. There are a lot of bugs fixed in between. (Update: Exam has pointed out that your snap package takes precedence over the Debian package in GNOME Software, so most users will actually receive the snap instead. The snap is still using 3.30.4, because Epiphany 3.32 depends on GTK 3.24, and that is not available in snaps yet. All app menu items are unavailable because Ubuntu’s GNOME Shell 3.32 does not display Epiphany 3.30’s app menu, so there’s no way to edit preferences, view history, import/export bookmarks, etc. This is not good.)

Because Epiphany is in your universe repository, rather than main, I understand that Canonical does not provide updates. But this is really not OK. Do I really need to add an xscreensaver-style time bomb to protect the reputation of Epiphany?

You’ve Disabled the JPEG 2000 Support

WebKitGTK is in main and you have been updating it regularly and in a timely manner, which is good. Thanks for this!

But we also need WebKitGTK to be built with OpenJPEG support, so that it can display JPEG 2000 images. Because you build WebKitGTK without OpenJPEG support, lots of popular websites are broken, including all websites using Akamai Image Manager. Because we have “Safari” but not “Chromium” in our user agent, these websites send us lots of JPEG 2000 images, and we need to be prepared to handle them properly to avoid broken websites. (Changing our user agent to avoid receiving JPEG 2000 images is, unfortunately, not practical.)

Here we have a really difficult issue, because you admittedly have a good reason for disabling OpenJPEG use. OpenJPEG has failed your security review for inclusion in main. Seth Arnold from the Ubuntu Security Team has reported 24 issues in OpenJPEG, of which 21 still remain unfixed. (It’s probably too much to ask, but if any readers want to help tackle a couple of these, that would be really great.) WebKitGTK is only as secure as its least-secure image decoder, and it seems likely that that would be OpenJPEG. Exposing the low-quality OpenJPEG library to the entire web is risky.

And yet, a web browser that doesn’t display websites properly is simply not worth delivering to users. We need this image decoder for web compatibility. WebKitGTK 2.26 will (hopefully) ship with a sandbox to mitigate security risks. Perhaps future versions of Epiphany should refuse to start if OpenJPEG support is unavailable?

by Michael Catanzaro at May 24, 2019 03:28 PM



May 20, 2019

WebKitGTK and WPE WebKit Security Advisory WSA-2019-0003

by The WebKitGTK Project

Several vulnerabilities were discovered in WebKitGTK and WPE WebKit.

  • CVE-2019-6237
    • 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.
  • CVE-2019-8571
    • 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.
  • CVE-2019-8583
    • 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.
  • CVE-2019-8584
    • 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.
  • CVE-2019-8586
    • 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.
  • CVE-2019-8587
    • 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.
  • CVE-2019-8594
    • 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.
  • CVE-2019-8595
    • 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.
  • CVE-2019-8596
    • 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.
  • CVE-2019-8597
    • 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.
  • CVE-2019-8601
    • 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.
  • CVE-2019-8607
    • 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.
  • CVE-2019-8608
    • 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.
  • CVE-2019-8609
    • 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.
  • CVE-2019-8610
    • 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.
  • CVE-2019-8615
    • 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.
  • CVE-2019-8611
    • 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.
  • CVE-2019-8619
    • 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.
  • CVE-2019-8622
    • 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.
  • CVE-2019-8623
    • 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.

Further information about WebKitGTK and WPE WebKit security advisories can be found at: https://webkitgtk.org/security.html or https://wpewebkit.org/security/.

May 20, 2019 12:00 AM



May 17, 2019

WebKitGTK 2.24.2 released!

by The WebKitGTK Project

This is a bug fix release in the stable 2.24 series.

What’s new in the WebKitGTK 2.24.2 release?

  • Fix rendering of emojis copy-pasted from GTK emoji chooser.
  • Fix space characters not being rendered with some CJK fonts.
  • Fix adaptive streaming playback with older GStreamer versions.
  • Set a maximum zoom level for pinch zooming gesture.
  • Fix navigation gesture to not interfere with scrolling.
  • Fix SSE2 detection at compile time, ensuring the right flags are passed to the compiler.
  • Fix several crashes and rendering issues.
  • Translation updates: Danish, Spanish, Ukrainian.
  • Security fixes: CVE-2019-8595, CVE-2019-8607, CVE-2019-8615.

Thanks to all the contributors who made possible this release.

May 17, 2019 12:00 AM



April 10, 2019

WebKitGTK and WPE WebKit Security Advisory WSA-2019-0002

by The WebKitGTK Project

Several vulnerabilities were discovered in WebKitGTK and WPE WebKit.

  • CVE-2019-6201
    • 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.
  • CVE-2019-6251
    • 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.
  • CVE-2019-7285
    • 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.
  • CVE-2019-7292
    • Versions affected: WebKitGTK before 2.22.6 and WPE WebKit before 2.22.4.
    • Credit to Zhunki and Zhiyi Zhang of 360 ESG Codesafe Team.
    • Processing maliciously crafted web content may result in the disclosure of process memory. A validation issue was addressed with improved logic.
  • CVE-2019-8503
    • Versions affected: WebKitGTK before 2.22.6 and WPE WebKit before 2.22.4.
    • Credit to Linus Särud of Detectify.
    • A malicious website may be able to execute scripts in the context of another website. A logic issue was addressed with improved validation.
  • CVE-2019-8506
    • 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. A type confusion issue was addressed with improved memory handling.
  • CVE-2019-8515
    • 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.
  • CVE-2019-8518
    • 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.
  • CVE-2019-8523
    • 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.
  • CVE-2019-8524
    • 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.
  • CVE-2019-8535
    • 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.
  • CVE-2019-8536
    • 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.
  • CVE-2019-8544
    • 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.
  • CVE-2019-8551
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.0.
    • Credit to Ryan Pickren, ryanpickren.com.
    • Processing maliciously crafted web content may lead to universal cross site scripting. A logic issue was addressed with improved validation.
  • CVE-2019-8558
    • 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.
  • CVE-2019-8559
    • 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.
  • CVE-2019-8563
    • 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.
  • CVE-2019-11070
    • 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.

Further information about WebKitGTK and WPE WebKit security advisories can be found at: https://webkitgtk.org/security.html or https://wpewebkit.org/security/.

April 10, 2019 12:00 AM



April 09, 2019

WebKitGTK 2.24.1 released!

by The WebKitGTK Project

This is the first bug fix release in the stable 2.24 series.

What’s new in the WebKitGTK 2.24.1 release?

  • Do not allow changes in active URI before provisional load starts for non-API requests.
  • Stop the threaded compositor when the page is not visible or layer tree state is frozen.
  • Use WebKit HTTP source element again for adaptive streaming fragments downloading.
  • Properly handle empty resources in webkit_web_resource_get_data().
  • Add quirk to ensure outlook.live.com uses the modern UI.
  • Fix methods returing GObject or boxed types in JavaScriptCore GLib API.
  • Ensure callback data is passed to functions and constructors with no parameters in JavaScriptCore GLib API.
  • Fix rendering of complex text when the font uses x,y origins.
  • Fix sound loop with Google Hangouts and WhatsApp notifications.
  • Fix the build with GStreamer 1.12.5 and GST GL enabled.
  • Detect SSE2 at compile time.
  • Fix several crashes and rendering issues.
  • Security fixes: CVE-2019-6251.

Thanks to all the contributors who made possible this release.

April 09, 2019 12:00 AM



April 08, 2019

Introducing WPEQt, a WPE API for Qt5

by Philippe Normand

WPEQt provides a QML plugin implementing an API very similar to the QWebView API. This blog post explains the rationale behind this new project aimed for QtWebKit users.

Qt5 already provides multiple WebView APIs, one based on QtWebKit (deprecated) and one based on QWebEngine (aka Chromium). WPEQt aims to provide …

by Philippe Normand at April 08, 2019 10:20 AM



March 27, 2019

Epiphany 3.32 and WebKitGTK 2.24

by Michael Catanzaro

I’m very pleased to (belatedly) announce the release of Epiphany 3.32 and WebKitGTK 2.24. This Epiphany release contains far more changes than usual, while WebKitGTK continues to improve steadily as well. There are a lot of new features to discuss, so let’s dive in.

Dazzling New Address Bar

The most noticeable change is the new address bar, based on libdazzle’s DzlSuggestionEntry. Christian put a lot of effort into designing this search bar to work for both Builder and Epiphany, and Jan-Michael helped integrate it into Epiphany. The result is much nicer than we had before:

The address bar is a central component of the user interface, and this clean design is important to provide a quality user experience. It should also leave a much better first impression than we had before.

Redesigned Tabs Menu

Epiphany 3.24 first added a tab menu at the end of the tab bar. This isn’t very useful if you have only a few tabs open, but if you have a huge number of tabs then it’s useful to help navigate through them. Previously, this menu only showed the page titles of the tabs. For 3.32, Adrien has converted this menu to a nice popover, including favicons, volume indicators, and close buttons. These enhancements were primarily aimed at making the browser easier to use on mobile devices, where there is no tab bar, but they’re nice improvement for desktop users, too.

(On mobile, the tab rows are much larger, to make touch selection easier.)

Touchpad Gestures

Epiphany now supports touchpad gestures. Jan-Michael first added a three-finger swipe to Epiphany, for navigating back and forward. Then Alexander (Exalm) decided to go and rewrite it, pushing the implementation down into WebKit to share as much code as possible with Safari. The end result is a two-finger swipe. This was much more involved than I expected as it required converting a bunch of Apple-specific Objective C++ code into cross-platform C++, but the end result was worth the effort:

Applications that depend on WebKitGTK 2.24 may opt-in to these gestures using webkit_settings_set_enable_back_forward_navigation_gestures().

Alexander also added pinch zoom.

Variable Fonts

Carlos Garcia decided to devote some attention to WebKit’s FreeType font backend, and the result speaks for itself:

Emoji 🦇

WebKit’s FreeType backend has supported emoji for some time, but there were a couple problems:

  • Most emoji combinations were not supported, so while characters like🧟(zombie) would work just fine, characters like 🧟â€�♂ï¸�(man zombie) and 🧟â€�♀ï¸�(woman zombie) were broken. Carlos fixed this. (Technically, only emoji combinations using a certain character code were broken, but that was most of them.)
  • There was no code to prefer emoji fonts for rendering emoji, meaning emoji would almost always be displayed in non-ideal fonts, usually DejaVu, resulting in a black and white glyph rather than color. Carlos fixed this, too. This seems to work properly in Firefox on some websites but not others, and it’s currently WONTFIXed in Chrome. It’s good to see WebKit ahead of the game, for once. Note that you’ll see color on this page regardless of your browser, because WordPress replaces the emoji characters with images, but I believe only WebKit can handle the characters themselves. You can test your browser here.

Improved Adaptive Mode

First introduced in 3.30, Adrien has continued to improve adaptive mode to ensure Epiphany works well on mobile devices. 3.32 is the first release to depend on libhandy. Adrien has converted various portions of the UI to use libhandy widgets.

Reader Mode

Jan-Michael’s reader mode has been available since 3.30, but new to 3.32 are many style improvements and new preferences to choose between dark and light theme, and between sans and serif font, thanks to Adrian (who is, confusingly, not Adrien). The default, sans on light background, still looks the best to me, but if you like serif fonts or dark backgrounds, now you can have them.

JPEG 2000

Wait, JPEG 2000? The obscure image standard not supported by Chrome or Firefox? Why would we add support for this? Simple: websites are using it. A certain piece of popular server-side software is serving JPEG 2000 images in place of normal JPEGs and even in place of PNG images to browsers with Safari-style user agents. (The software in question doesn’t even bother to change the file extensions. We’ve found far too many images in the wild ending in .png that are actually JPEG 2000.) Since this software is used on a fairly large number of websites, and our user agent is too fragile to change, we decided to support JPEG 2000 in order to make these websites work properly. So Carlos has implemented JPEG 2000 support, using the OpenJPEG library.

This isn’t a happy event for the web, because WebKit is only as secure as its least-secure dependency, and adding new obscure image formats is not a step in the right direction. But in this case,  it is necessary.

Mouse Gestures

Experimental mouse gesture support is now available, thanks to Jan-Michael, if you’re willing to use the command line to enable it:

$ gsettings set org.gnome.Epiphany.web:/org/gnome/epiphany/web/ enable-mouse-gestures true

With this, I find myself closing tabs by dragging the mouse down and then to the right. Down and back up will reload the tab. Straight to the left is Back, straight to the right is Forward. Straight down will open a new tab. I had originally hoped to use the right mouse button for this, as in Opera, but turns out there is a difference in context menu behavior: whereas Windows apps normally pop up the context menu on button release, GTK apps open the menu on button press. That means the context menu would appear at the start of every mouse gesture. And that is certainly no good, so we’ve opted to use the middle mouse button instead. We aren’t sure whether this is a good state of things, and need your feedback to decide where to go with this feature.

Improved Fullscreen Mode

A cool side benefit of using libdazzle is that the header bar is now available in fullscreen mode by pressing the mouse towards the top of the screen. There’s even a nice animation to show the header bar sliding up to the top of the screen, so you know it’s there (animation disabled for fullscreen video).

The New Tab Button

Some users were disconcerted that the new tab button would jump from the end of the tab bar (when multiple tabs are open) back up to the end of the header bar (when there is only one tab open). Now this button will remain in one place: the header bar. Since it will no longer appear in the tab bar, Jan-Michael has moved it back to the start of the header bar, where it was from 3.12 through 3.22, rather than the end. This is mostly arbitrary, but makes for a somewhat more balanced layout.

The history of the new tab button is rather fun: when the new tab button was first added in 3.8, it was added at the end of the header bar, but moved to the start in 3.12 to be more consistent with gedit, then moved back to the end in 3.24 to reduce the distance it would need to move to reach the tab bar. So we’ve come full circle here, twice. Only time will tell if this nomadic button will finally be able to stay put.

New Icon

Yes, most GNOME applications have a new icon in 3.32, so Epiphany is not special here. But I just can’t resist the urge to show it off. Thanks, Jakub!

And More…

It’s impossible to mention all the improvements in 3.32 in a single blog post, but I want to squeeze a few more in.

Alexander (Exalm) landed several improvements to Epiphany’s theme, especially the incognito mode theme, which needed work to look good with the new Adwaita in 3.32.

Jan-Michael added an animation for completed downloads, so we don’t need to annoyingly pop open the download popover anymore to let you know that your download has completed.

Carlos Garcia added support for automation mode. This means Epiphany can now be used for running automated tests with WebDriver (e.g. with Selenium). Using the new automation mode, I’ve upstreamed support for running tests with Epiphany to the Web Platform Tests (WPT) project, the test suite used by web engine developers to test standards conformance.

Carlos also reworked the implementation of script dialogs so that they are now modal only to their associated web view, not modal to the entire application. This means you can just close the browser tab if a particular website is abusing script dialogs in a problematic way, e.g. by continuously opening new dialogs.

Patrick has improved the directory layout Epiphany uses to store data on disk to avoid storing non-configuration data under ~/.config, and reworked the internals of the password manager to mitigate Spectre-related concerns. He also implemented Happy Eyeballs support in GLib, so Epiphany will now fall back to an IPv4 connection if IPv6 is available but broken.

Now Contains 100% Less Punctuation!

Did you notice any + signs missing in this blog? Following GTK+’s rename to GTK, WebKitGTK+ has been renamed to WebKitGTK. You’re welcome.

Whither Pop!_OS?

Extra Credit

Although Epiphany 3.32 has been the work of many developers, as you’ve seen, I want to give special credit Epiphany’s newest maintainer, Jan-Michael. He has closed a considerable number of bugs, landed too many improvements to mention here, and has been a tremendous help. Thank you!

Now, onward to 3.34!

by Michael Catanzaro at March 27, 2019 12:41 PM



March 19, 2019

Epiphany Technology Preview Upgrade Requires Manual Intervention

by Michael Catanzaro

Jan-Michael has recently changed Epiphany Technology Preview to use a separate app ID. Instead of org.gnome.Epiphany, it will now be org.gnome.Epiphany.Devel, to avoid clashing with your system version of Epiphany. You can now have separate desktop icons for both system Epiphany and Epiphany Technology Preview at the same time.

Because flatpak doesn’t provide any way to rename an app ID, this means it’s the end of the road for previous installations of Epiphany Technology Preview. Manual intervention is required to upgrade. Fortunately, this is a one-time hurdle, and it is not hard:

$ flatpak uninstall org.gnome.Epiphany

Uninstall the old Epiphany…

$ flatpak install gnome-apps-nightly org.gnome.Epiphany.Devel org.gnome.Epiphany.Devel.Debug

…install the new one, assuming that your remote is named gnome-apps-nightly (the name used locally may differ), and that you also want to install debuginfo to make it possible to debug it…

$ mv ~/.var/app/org.gnome.Epiphany ~/.var/app/org.gnome.Epiphany.Devel

…and move your personal data from the old app to the new one.

Then don’t forget to make it your default web browser under System Settings -> Details -> Default Applications. Thanks for testing Epiphany Technology Preview!

by Michael Catanzaro at March 19, 2019 06:39 PM



March 13, 2019

WebKitGTK 2.24.0 released!

by The WebKitGTK Project

This is the first stable release in the 2.24 series.

Highlights of the WebKitGTK 2.24.0 release

  • Added support for content filtering.
  • Variation fonts support.
  • Fully emoji rendering support.
  • Added navigation and pinch zoom gestures for touchpads.
  • Support for JPEG2000 images.
  • Script dialogs are now modal to the current web view only.
  • New API to convert URI to format for display.

For more details about all the changes included in WebKitGTK 2.24 see the NEWS file that is included in the tarball.

Thanks to all the contributors who made possible this release.

March 13, 2019 12:00 AM



March 06, 2019

WebKitGTK 2.23.92 released!

by The WebKitGTK Project

This is a development release leading toward 2.24 series.

What’s new in the WebKitGTK 2.23.92 release?

  • Fix constructors returning a GObject in JSC GLib API.
  • Do not scan NPAPI plugins when plugins are disabled in settings.
  • Add WebKitUserContentFilterStore to the API docs.
  • Fix several crashes and rendering issues.
  • Translation updates: Polish.

Thanks to all the contributors who made possible this release.

March 06, 2019 12:00 AM



March 01, 2019

WebKitGTK 2.22.7 released!

by The WebKitGTK Project

This is a bug fix release in the stable 2.22 series.

What’s new in the WebKitGTK 2.22.7 release?

  • Fix rendering of glyphs in Hebrew (and possibly other languages) when Unicode NFC normalization is used.
  • Fix several crashes and race conditions.

Thanks to all the contributors who made possible this release.

March 01, 2019 12:00 AM



February 20, 2019

WebKitGTK 2.23.91 released!

by The WebKitGTK Project

This is a development release leading toward 2.24 series.

What’s new in the WebKitGTK 2.23.91 release?

  • Add new API to handle user content filters.
  • Fix a UI process crash while filling selection data during drag and drop.
  • Fix deadlock on Linux/x64 between SamplingProfiler and VMTraps.
  • Fix several crashes and rendering issues.
  • Translation updates: Italian.

Thanks to all the contributors who made possible this release.

February 20, 2019 12:00 AM



February 14, 2019

WebKitGTK 2.23.90 released!

by The WebKitGTK Project

This is a development release leading toward 2.24 series.

What’s new in the WebKitGTK 2.23.90 release?

  • Add a new setting to disable JavaScript elments from documents during parsing.
  • Add new API to expose JavaScriptCore options.
  • Add support for JPEG2000 images.
  • Add support for back/forward touchpad gesture.
  • Add support for pinch zoom on touchpad.
  • Use a scrolled window in alert dialogs to handle long contents.
  • Sleep disabler now inhibits idle when a “System” sleep disabler is requested.
  • Remove experimental sandboxing support, it’s not yet ready for stable release.
  • Fix a web process deadlock when starting the remote inspector.
  • Fix a crash when browsing inspector:// URI without port set.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

February 14, 2019 12:00 AM