October 23, 2020

WebKitGTK 2.30.2 released!

by The WebKitGTK Project

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

What’s new in the WebKitGTK 2.30.2 release?

  • Fix scrolling when smooth scrolling is enabled in async scrolling mode.
  • Fix WebSocket requests with same-site cookies.
  • Fix TLS certificate information for service workers.
  • Handle chassis type when its value is quoted.
  • Fix the build with ENABLE_MEDIA_STREAM enabled and ENABLE_WEB_RTC_DISABLED.
  • Fix the build with ENABLE_GAMEPAD enabled.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

October 23, 2020 12:00 AM



October 01, 2020

Closing the gap (in flexbox 😇)

by Sergio Villar

Flexbox had a lot of early problems, but by mid-May 2020 where our story begins, both Firefox and Chromium had done a lot of work on improving things with this feature. WebKit, however, hadn’t caught up. Prioritizing the incredible amounts of work a web engine requires is difficult. The WebKit implementation was still passable for very many (most) cases of the core features, and it didn’t have problems that caused crashes or something that urgently demanded attention, so engineers dedicated their limited time toward other things. The net result, however, was that as this choice repeated many times, the comparative state of WebKit’s flexbox implementation had fallen behind pretty significantly.
Web Platform Tests (WPT) is a huge ongoing effort from many people to come up with a very extensive list of tests that could help both spec editors and implementors to make sure we have great compatibility. In the case of flexbox, for example, there are currently 773 tests (2926 subtests) and WebKit was failing a good amount of them. This matters a lot because there are things that flexbox is ideal for, and it is exceptionally widely used. In mid-May, Igalia was contracted to improve things here, and in this post, I’ll explain and illustrate how we did that.

The Challenge

The main issues were (in no particular order):
  • min-width:auto and min-height:auto handling
  • Nested flexboxes in column flows
  • Flexboxes inside tables and viceversa
  • Percentages in heights with indefinite sizes
  • WebKit CI not runnning many WPT flexbox tests
  • and of course… lack of gap support in Flexbox
Modifying Flexbox layout code is a challenge by itself. Tiny modifications in the source code could cause huge differences in the final layout. You might even have a patch that passes all the tests and regresses multiple popular web sites.
Good news is that we were able to tackle most of those issues. Let’s review what changes you could eventually expect from future releases of Safari (note that Apple doesn’t disclose information about future products and/or releases) and the other WebKit based browsers (like GNOME Web).

Flexbox gaps 🥳🎉

Probably one of the most awaited features in WebKit by web developers. It’s finally here after Firefox and Chrome landed it not so long ago. The implementation was initially inspired by the one in Chrome but then it diverged a bit in the final version of the patch. The important thing is that the behaviour should be the same, at least all the tests in WPT related to gaps are passing now in WebKit trunk.
<div style="display: flex; flex-wrap: wrap; gap: 1ch">
  <div style="background: magenta; color: white">Lorem</div>
  <div style="background: green; color: white">ipsum</div>
  <div style="background: orange; color: white">dolor</div>
  <div style="background: blue; color: white">sit</div>
  <div style="background: brown; color: white">amet</div>
</div>

Tables as flex items

Tables should obey the flex container sizing whenever they are flex items. As it can be seen in the examples bellow, the tables’ layout code was kicking in and ignoring the constraints set by the flex container. Tables should do what the flex algorithm mandates and thus they should allow being stretched/squeezed as required.
<div style="display:flex; width:100px; background:red;">
  <div style="display:table; width:10px; max-width:10px; height:100px; background:green;">
    <div style="width:100px; height:10px; background:green;"></div>
  </div>
</div>

Tables with items exceeding the 100% of available size

This is the case of tables placed inside flex items. The automatic layout table algorithm was generating tables with unlimited widths when the sum of the sizes of their columns (expressed in percentages) was exceeding the 100%. It was impossible to fulfill at the same time the constraints set by tables and flexbox algorithms.
<div style="display:flex; width:100px; height:100px; align-items:flex-start; background:green;">
  <div style="flex-grow:1; flex-shrink:0;">
    <table style="height:50px; background:green;" cellpadding="0" cellspacing="0">
      <tr>
        <td style="width:100%; background:green;"> </td>
        <td style="background:green;"> </td>
      </tr>
    </table>
  </div>
</div>

Note how the table was growing indefinitely (I cropped the “Before” picture to fit in the post) to the right before the fix.

Alignment in single-line flexboxes

Interesting case. The code was considering that single-line flexboxes were those where all the flex items were placed in a single line after computing the required space for them. Though sensible, that’s not what a single line flexbox is, it’s a flex container with flex-wrap:nowrap. This means that a flex container with flex-wrap:wrap whose children do not need more than 1 flex line to be placed is not a single-line flex container from the specs POV (corolary: implementing specs is hard).
<div style="display: flex; flex-wrap: wrap; align-content: flex-end; width: 425px; height: 70px; border: 2px solid black">
  <div style="height: 20px">This text should be at the bottom of its container</div>
</div>

Percentages in flex items with indefinite sizes

One of the trickiest ones. Although it didn’t involve a lot of code it caused two serious regressions in Youtube’s upload form and when viewing Twitter videos in fullscreen which required some previous fixes and delayed a bit the landing of this patch. Note that this behaviour was really conflictive from the pure specification POV as there were many changes over the time. Defining a good behaviour is really complicated. Without entering in too much details, flexbox has a couple of cases were sizes are considered as definite when they are theoretically indefinite. In this case we consider that if the flex container main size is definite then the post-flexing size of flex items is also treated as definite.
<div style="display: flex; flex-direction: column; height: 150px; width: 150px; border: 2px solid black;">
  <div>
    <div style="height: 50%; overflow: hidden;">
      <div style="width: 50px; height: 50px; background: green;"></div>
    </div>
  <div>
  <div style="flex: none; width: 50px; height: 50px; background: green;"></div>
</div>

Hit testing with overlapping flex items

There were some issues with pointer events passing through overlapping flex items (due to negative margins for example). This was fixed by letting the hit testing code proceed in reverse (the opposite to painting) order-modified document order instead of using the raw order from the DOM.
<div style="display:flex; border: 1px solid black; width: 300px;">
  <a style="width: 200px;" href="#">Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua</a>
  <div style="margin-left: -200px; width: 130px; height: 50px; background: orange;"></div>
</div>

In the “Before” case hit testing was bypassing the orange block and thus, the cursor was showing a hand because it detected that it was hovering a link. After the fix, the cursor is properly rendered as an arrow because the orange block covers the underneath link.

Computing percentages with scrollbars

In this case the issue was that, in order to compute percentages in heights, we were incorrectly using the size of the scrollbars too.
<div style="display: inline-flex; height: 10em;">
  <div style="overflow-x: scroll;">
    <div style="width: 200px; height: 100%; background: green"></div>
  </div>
</div>

Note that in the “After” picture the horizontal scrollbar background is visible while in the “Before” the wrong height computation made the flex item overlap the scrollbar.

Image items with specific sizes

The flex layout algorithm needs the intrinsic sizes of the flex items to compute their sizes and the size of the flex container. Changes to those intrinsic sizes should trigger new layouts, and the code was not doing that.
<!-- Just to showcase how the img bellow is not properly sized -->
<div style="position: absolute; background-color: red; width: 50px; height: 50px; z-index: -1;"></div>
 
<div style="display: flex; flex-direction: column; width: 100px; height: 5px;">
  <img style="width: 100px; height: 100px;" src="https://wpt.live/css/css-flexbox/support/100x100-green.png">
</div>


Nested flexboxes with ‘min-height: auto’

Another tricky one and another one related to the handling of nested column flexboxes. As in the previous issue with nested column flexboxes the problem was that we were not supporting this case. For those wanting to have a deeper understanding of the issue this bug was about implementing section 4.5 of the specs. This was one of the more complicated ones to fix, Edward Lorenz would love that part of the layout code, the slightest change in one of those source code lines could trigger huge changes in the final rendering.
<div style='display:flex; flex-direction: column; overflow-y: scroll; width: 250px; height: 250px; border: 1px solid black'>
  <div style='display:flex;'>
    <div style="width: 100px; background: blue"></div>
    <div style='width: 120px; background: orange'></div>
    <div style='width: 10px; background: yellow; height: 300px'></div>
  </div>
</div>

As it can be seen, in the “Before” picture the blue and orange blocks are sized differently to the yellow one. That’s fixed in the “After” picture.

Percentages in quirks mode

Another one affecting how percentages are computed in heights, but this one specific to quirks mode. We’re matching now Firefox, Chrome and pre-Chromium Edge, i.e., flexbox should not care much about quirks mode since it was invented many years after quirky browsers dominated the earth.
<!DOCTYPE html PUBLIC>
<div style="width: 100px; height: 50px;">
  <div style="display: flex; flex-direction: column; outline: 2px solid blue;">
    <div style="flex: 0 0 50%"></div>
  </div>
</div>

Percentages in ‘flex-basis’

Percentages were working generally fine inside flex-basis, however there was one particular problematic case. It arose whenever that percentage was refererring to, oh surprise, and indefinite height. And again, we’re talking about nested flexboxes with column flows. Indeed, definite/indefinite sizes is one of the toughest things to get right from the layout POV. In this particular case, the fix was to ignore the percentages and and treat them as height: auto.
<div style="display: flex; flex-direction: column; width: 200px;">
  <div style="flex-basis: 0%; height: 100px; background: red;">
    <div style="background: lime">Here's some text.</div>
  </div>
</div>

Flex containers inside STF tables

Fixing a couple of test cases submitted by an anonymous Opera employee 8! years ago. This is another case of competing layout contexts trying to do things their own way.
<div style="display: table; background:red">
   <div style="display: flex; width: 0px">
      <p style="margin: 1em 1em;width: 50px">Text</p>
      <p style="margin: 1em 1em;width: 50px">Text</p>
      <p style="margin: 1em 1em;width: 50px">Text</p>
   </div>
</div>

After the fix the table is properly sized to 0px width and thus no red is seen.

Conclusions

These examples are just some interesting ones I’ve chosen to highlight. In the end, almost 50 new flexbox tests are passing in WebKit that weren’t back in May!. I wouldn’t like to forget the great job done by my colleague Carlos Lopez who imported tons of WPT flexbox tests into the WebKit source tree. He also performed awesome triage work which made my life a lot easier.
Investing in interoperability is a huge deal for the web. It’s good for everyone, from spec authors to final users, including browser vendors, downstream ports or web authors. So if you care about the web, or your business orbits around web technologies, you should definitely promote and invest on interoperability.

Implementing standards or fixing bugs in web engines is the kind of work we happily do at Igalia on a daily basis. We are the second largest contributor to both WebKit and Chrome/Blink, so if you have an annoying bug on a particular web engine (Gecko and Servo as well) that you want to be fixed, don’t hesitate and contact us, we’d be glad to help. Also, should you want to be part of a workers-owned cooperative with an asambleary decision-making mechanism and a strong focus on free software technologies join us!.

Acknowledgements

Many thanks to WebKit reviewers from Apple and Igalia like Darin Adler, Manuel Rego, Javier Fernández or Daniel Bates who made the process really easy for me, always providing very nice feedback for the patches I submitted.
I’m also really thankful to Googlers like Christian Biesinger, David Grogan and Stephen McGruer who worked on the very same things in Blink and/or provided very nice guidance and support when porting patches.

by svillar at October 01, 2020 11:34 AM



September 21, 2020

WebKitGTK 2.30.1 released!

by The WebKitGTK Project

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

What’s new in the WebKitGTK 2.30.1 release?

  • Bring back the environment variable to force single process mode when PSON is disabled.
  • Fix downloads started by an ephemeral web context.
  • Translation updates: Brazilian Portuguese.

Thanks to all the contributors who made possible this release.

September 21, 2020 12:00 AM



September 16, 2020

Epiphany 3.38 and WebKitGTK 2.30

by Michael Catanzaro

It’s that time of year again: a new GNOME release, and with it, a new Epiphany. The pace of Epiphany development has increased significantly over the last few years thanks to an increase in the number of active contributors. Most notably, Jan-Michael Brummer has solved dozens of bugs and landed many new enhancements, Alexander Mikhaylenko has polished numerous rough edges throughout the browser, and Andrei Lisita has landed several significant improvements to various Epiphany dialogs. That doesn’t count the work that Igalia is doing to maintain WebKitGTK, the WPE graphics stack, and libsoup, all of which is essential to delivering quality Epiphany releases, nor the work of the GNOME localization teams to translate it to your native language. Even if Epiphany itself is only the topmost layer of this technology stack, having more developers working on Epiphany itself allows us to deliver increased polish throughout the user interface layer, and I’m pretty happy with the result. Let’s take a look at what’s new.

Intelligent Tracking Prevention

Intelligent Tracking Prevention (ITP) is the headline feature of this release. Safari has had ITP for several years now, so if you’re familiar with how ITP works to prevent cross-site tracking on macOS or iOS, then you already know what to expect here.  If you’re more familiar with Firefox’s Enhanced Tracking Protection, or Chrome’s nothing (crickets: chirp, chirp!), then WebKit’s ITP is a little different from what you’re used to. ITP relies on heuristics that apply the same to all domains, so there are no blocklists of naughty domains that should be targeted for content blocking like you see in Firefox. Instead, a set of innovative restrictions is applied globally to all web content, and a separate set of stricter restrictions is applied to domains classified as “prevalent” based on your browsing history. Domains are classified as prevalent if ITP decides the domain is capable of tracking your browsing across the web, or non-prevalent otherwise. (The public-friendly terminology for this is “Classification as Having Cross-Site Tracking Capabilities,” but that is a mouthful, so I’ll stick with “prevalent.” It makes sense: domains that are common across many websites can track you across many websites, and domains that are not common cannot.)

ITP is enabled by default in Epiphany 3.38, as it has been for several years now in Safari, because otherwise only a small minority of users would turn it on. ITP protections are designed to be effective without breaking too many websites, so it’s fairly safe to enable by default. (You may encounter a few broken websites that have not been updated to use the Storage Access API to store third-party cookies. If so, you can choose to turn off ITP in the preferences dialog.)

For a detailed discussion covering ITP’s tracking mitigations, see Tracking Prevention in WebKit. I’m not an expert myself, but the short version is this: full third-party cookie blocking across all websites (to store a third-party cookie, websites must use the Storage Access API to prompt the user for permission); cookie-blocking latch mode (“once a request is blocked from using cookies, all redirects of that request are also blocked from using cookies”); downgraded third-party referrers (“all third-party referrers are downgraded to their origins by default”) to avoid exposing the path component of the URL in the referrer; blocked third-party HSTS (“HSTS […] can only be set by the first-party website […]”) to stop abuse by tracker scripts; detection of cross-site tracking via link decoration and 24-hour expiration time for all cookies created by JavaScript on the landing page when detected; a 7-day expiration time for all other cookies created by JavaScript (yes, this applies to first-party cookies); and a 7-day extendable lifetime for all other script-writable storage, extended whenever the user interacts with the website (necessary because tracking companies began using first-party scripts to evade the above restrictions). Additionally, for prevalent domains only, domains engaging in bounce tracking may have cookies forced to SameSite=strict, and Verified Partitioned Cache is enabled (cached resources are re-downloaded after seven days and deleted if they fail certain privacy tests). Whew!

WebKit has many additional privacy protections not tied to the ITP setting and therefore not discussed here — did you know that cached resources are partioned based on the first-party domain? — and there’s more that’s not very well documented which I don’t understand and haven’t mentioned (tracker collusion!), but that should give you the general idea of how sophisticated this is relative to, say, Chrome (chirp!). Thanks to John Wilander from Apple for his work developing and maintaining ITP, and to Carlos Garcia for getting it working on Linux. If you’re interested in the full history of how ITP has evolved over the years to respond to the changing threat landscape (e.g. tracking prevention tracking), see John’s WebKit blog posts. You might also be interested in WebKit’s Tracking Prevention Policy, which I believe is the strictest anti-tracking stance of any major web engine. TL;DR: “we treat circumvention of shipping anti-tracking measures with the same seriousness as exploitation of security vulnerabilities. If a party attempts to circumvent our tracking prevention methods, we may add additional restrictions without prior notice.” No exceptions.

Updated Website Data Preferences

As part of the work on ITP, you’ll notice that Epiphany’s cookie storage preferences have changed a bit. Since ITP enforces full third-party cookie blocking, it no longer makes sense to have a separate cookie storage preference for that, so I replaced the old tri-state cookie storage setting (always accept cookies, block third-party cookies, block all cookies) with two switches: one to toggle ITP, and one to toggle all website data storage.

Previously, it was only possible to block cookies, but this new setting will additionally block localStorage and IndexedDB, web features that allow websites to store arbitrary data in your browser, similar to cookies. It doesn’t really make much sense to block cookies but allow other types of data storage, so the new preferences should better enforce the user’s intent behind disabling cookies. (This preference does not yet block media keys, service workers, or legacy offline web application cache, but it probably should.) I don’t really recommend disabling website data storage, since it will cause compatibility issues on many websites, but this option is there for those who want it. Disabling ITP is also not something I want to recommend, but it might be necessary to access certain broken websites that have not yet been updated to use the Storage Access API.

Accordingly, Andrei has removed the old cookies dialog and moved cookie management into the Clear Personal Data dialog, which is a better place because anyone clearing cookies for a particular website is likely to also want to clear other personal data. (If you want to delete a website’s cookies, then you probably don’t want to leave its SQL databases intact, right?) He had to remove the ability to clear data from a particular point in time, because WebKit doesn’t support this operation for cookies, but that function is probably  rarely-used and I think the benefit of the change should outweigh the cost. (We could bring it back in the future if somebody wants to try implementing that feature in WebKit, but I suspect not many users will notice.) Treating cookies as separate and different from other forms of website data storage no longer makes sense in 2020, and it’s good to have finally moved on from that antiquated practice.

New HTML Theme

Carlos Garcia has added a new Adwaita-based HTML theme to WebKitGTK 2.30, and removed support for rendering HTML elements using the GTK theme (except for scrollbars). Trying to use the GTK theme to render web content was fragile and caused many web compatibility problems that nobody ever managed to solve. The GTK developers were never very fond of us doing this in the first place, and the foreign drawing API required to do so has been removed from GTK 4, so this was also good preparation for getting WebKitGTK ready for GTK 4. Carlos’s new theme is similar to Adwaita, but gradients have been toned down or removed in order to give a flatter, neutral look that should blend in nicely with all pages while still feeling modern.

This should be a fairly minor style change for Adwaita users, but a very large change for anyone using custom themes. I don’t expect everyone will be happy, but please trust that this will at least result in better web compatibility and fewer tricky theme-related bug reports.

Screenshot demonstrating new HTML theme vs. GTK theme
Left: Adwaita GTK theme controls rendered by WebKitGTK 2.28. Right: hardcoded Adwaita-based HTML theme with toned down gradients.

Although scrollbars will still use the GTK theme as of WebKitGTK 2.30, that will no longer be possible to do in GTK 4, so themed scrollbars are almost certain to be removed in the future. That will be a noticeable disappointment in every app that uses WebKitGTK, but I don’t see any likely solution to this.

Media Permissions

Jan-Michael added new API in WebKitGTK 2.30 to allow muting individual browser tabs, and hooked it up in Epiphany. This is good when you want to silence just one annoying tab without silencing everything.

Meanwhile, Charlie Turner added WebKitGTK API for managing autoplay policies. Videos with sound are now blocked from autoplaying by default, while videos with no sound are still allowed. Charlie hooked this up to Epiphany’s existing permission manager popover, so you can change the behavior for websites you care about without affecting other websites.

Screenshot displaying new media autoplay permission settings
Configure your preferred media autoplay policy for a website near you today!

Improved Dialogs

In addition to his work on the Clear Data dialog, Andrei has also implemented many improvements and squashed bugs throughout each view of the preferences dialog, the passwords dialog, and the history dialog, and refactored the code to be much more maintainable. Head over to his blog to learn more about his accomplishments. (Thanks to Google for sponsoring Andrei’s work via Google Summer of Code, and to Alexander for help mentoring.)

Additionally, Adrien Plazas has ported the preferences dialog to use HdyPreferencesWindow, bringing a pretty major design change to the view switcher:

Screenshot showing changes to the preferences dialog
Left: Epiphany 3.36 preferences dialog. Right: Epiphany 3.38. Note the download settings are present in the left screenshot but missing from the right screenshot because the right window is using flatpak, and the download settings are unavailable in flatpak.

User Scripts

User scripts (like Greasemonkey) allow you to run custom JavaScript on websites. WebKit has long offered user script functionality alongside user CSS, but previous versions of Epiphany only exposed user CSS. Jan-Michael has added the ability to configure a user script as well. To enable, visit the Appearance tab in the preferences dialog (a somewhat odd place, but it really needs to be located next to user CSS due to the tight relationship there). Besides allowing you to do, well, basically anything, this also significantly enhances the usability of user CSS, since now you can apply certain styles only to particular websites. The UI is a little primitive — your script (like your CSS) has to be one file that will be run on every website, so don’t try to design a complex codebase using your user script — but you can use conditional statements to limit execution to specific websites as you please, so it should work fairly well for anyone who has need of it. I fully expect 99.9% of users will never touch user scripts or user styles, but it’s nice for power users to have these features available if needed.

HTTP Authentication Password Storage

Jan-Michael and Carlos Garcia have worked to ensure HTTP authentication passwords are now stored in Epiphany’s password manager rather than by WebKit, so they can now be viewed and deleted from Epiphany, which required some new WebKitGTK API to do properly. Unfortunately, WebKitGTK saves network passwords using the default network secret schema, meaning its passwords (saved by older versions of Epiphany) are all leaked: we have no way to know which application owns those passwords, so we don’t have any way to know which passwords were stored by WebKit and which can be safely managed by Epiphany going forward. Accordingly, all previously-stored HTTP authentication passwords are no longer accessible; you’ll have to use seahorse to look them up manually if you need to recover them. HTTP authentication is not very commonly-used nowadays except for internal corporate domains, so hopefully this one-time migration snafu will not be a major inconvenience to most users.

New Tab Animation

Jan-Michael has added a new animation when you open a new tab. If the newly-created tab is not visible in the tab bar, then the right arrow will flash to indicate success, letting you know that you actually managed to open the page. Opening tabs out of view happens too often currently, but at least it’s a nice improvement over not knowing whether you actually managed to open the tab or not. This will be improved further next year, because Alexander is working on a completely new tab widget to replace GtkNotebook.

New View Source Theme

Jim Mason changed view source mode to use a highlight.js theme designed to mimic Firefox’s syntax highlighting, and added dark mode support.

Image showing dark mode support in view source mode
Embrace the dark.

And More…

  • WebKitGTK 2.30 now supports video formats in image elements, thanks to Philippe Normand. You’ll notice that short GIF-style videos will now work on several major websites where they previously didn’t.
  • I added a new WebKitGTK 2.30 API to expose the paste as plaintext editor command, which was previously internal but fully-functional. I’ve hooked it up in Epiphany’s context menu as “Paste Text Only.” This is nice when you want to discard markup when pasting into a rich text editor (such as the WordPress editor I’m using to write this post).
  • Jan-Michael has implemented support for reordering pinned tabs. You can now drag to reorder pinned tabs any way you please, subject to the constraint that all pinned tabs stay left of all unpinned tabs.
  • Jan-Michael added a new import/export menu, and the bookmarks import/export features have moved there. He also added a new feature to import passwords from Chrome. Meanwhile, ignapk added support for importing bookmarks from HTML (compatible with Firefox).
  • Jan-Michael added a new preference to web apps to allow running them in the background. When enabled, closing the window will only hide the the window: everything will continue running. This is useful for mail apps, music players, and similar applications.
  • Continuing Jan-Michael’s list of accomplishments, he removed Epiphany’s previous hidden setting to set a mobile user agent header after discovering that it did not work properly, and replaced it by adding support in WebKitGTK 2.30 for automatically setting a mobile user agent header depending on the chassis type detected by logind. This results in a major user experience improvement when using Epiphany as a mobile browser. Beware: this functionality currently does not work in flatpak because it requires the creation of a new desktop portal.
  • Stephan Verbücheln has landed multiple fixes to improve display of favicons on hidpi displays.
  • Zach Harbort fixed a rounding error that caused the zoom level to display oddly when changing zoom levels.
  • Vanadiae landed some improvements to the search engine configuration dialog (with more to come) and helped investigate a crash that occurs when using the “Set as Wallpaper” function under Flatpak. The crash is pretty tricky, so we wound up disabling that function under Flatpak for now. He also updated screenshots throughout the  user help.
  • Sabri Ünal continued his effort to document and standardize keyboard shortcuts throughout GNOME, adding a few missing shortcuts to the keyboard shortcuts dialog.

Epiphany 3.38 will be the final Epiphany 3 release, concluding a decade of releases that start with 3. We will match GNOME in following a new version scheme going forward, dropping the leading 3 and the confusing even/odd versioning. Onward to Epiphany 40!

by Michael Catanzaro at September 16, 2020 05:00 PM



September 11, 2020

WebKitGTK 2.30.0 released!

by The WebKitGTK Project

This is the first stable release in the 2.30 series.

Highlights of the WebKitGTK 2.30.0 release

  • Add Intelligent Tracking Prevention (ITP) support.
  • Add support for backdrop filters.
  • Stop using GTK theming to render form controls and add API to disable using GTK to render scrollbars too.
  • Add support for video formats in image 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 paste as plain text option to the context menu for rich editable content.

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

Thanks to all the contributors who made possible this release.

September 11, 2020 12:00 AM



September 07, 2020

Review of Igalia Multimedia activities (2020/H1)

by Víctor Jáquez

This blog post is a review of the various activities the Igalia Multimedia team was involved in during the first half of 2020.

Our previous reports are:

Just before a new virus turned into pandemics we could enjoy our traditional FOSDEM. There, our colleague Phil gave a talk about many of the topics covered in this report.

GstWPE

GstWPE’s wpesrc element, produces a video texture representing a web page rendered off-screen by WPE.

We have worked on a new iteration of the GstWPE demo, focusing on one-to-many, web-augmented overlays, broadcasting with WebRTC and Janus.

Also, since the merge of gstwpe plugin in gst-plugins-bad (staging area for new elements) new users have come along spotting rough areas and improving the element along the way.

Video Editing

GStreamer Editing Services (GES) is a library that simplifies the creation of multimedia editing applications. It is based on the GStreamer multimedia framework and is heavily used by Pitivi video editor.

Implemented frame accuracy in the GStreamer Editing Services (GES)

As required by the industry, it is now possible to reference all time in frame number, providing a precise mapping between frame number and play time. Many issues were fixed in GStreamer to reach the precision enough for make this work. Also intensive regression tests were added.

Implemented time effects support in GES

Important refactoring inside GStreamer Editing Services have happened to allow cleanly and safely change playback speed of individual clips.

Implemented reverse playback in GES

Several issues have been fixed inside GStreamer core elements and base classes in order to support reverse playback. This allows us to implement reliable and frame accurate reverse playback for individual clips.

Implemented ImageSequence support in GStreamer and GES

Since OpenTimelineIO implemented ImageSequence support, many users in the community had said it was really required. We reviewed and finished up imagesequencesrc element, which had been awaiting review for years.

This feature is now also supported in the OpentimelineIO GES adapater.

Optimized nested timelines preroll time by an order of magnitude

Caps negotiation, done while the pipeline transitions from pause state to playing state, testing the whole pipeline functionality, was the bottleneck for nested timelines, so pipelines were reworked to avoid useless negotiations. At the same time, other members of GStreamer community have improved caps negotiation performance in general.

Last but not least, our colleague Thibault gave a talk in The Pipeline Conference about The Motion Picture Industry and Open Source Software: GStreamer as an Alternative, explaining how and why GStreamer could be leveraged in the motion picture industry to allow faster innovation, and solve issues by reusing all the multi-platform infrastructure the community has to offer.

WebKit multimedia

There has been a lot of work on WebKit multimedia, particularly for WebKitGTK and WPE ports which use GStreamer framework as backend.

WebKit Flatpak SDK

But first of all we would like to draw readers attention to the new WebKit Flatpak SDK. It was not a contribution only from the multimedia team, but rather a joint effort among different teams in Igalia.

Before WebKit Flatpak SDK, JHBuild was used for setting up a WebKitGTK/WPE environment for testing and development. Its purpose to is to provide a common set of well defined dependencies instead of relying on the ones available in the different Linux distributions, which might bring different outputs. Nonetheless, Flatpak offers a much more coherent environment for testing and develop, isolated from the rest of the building host, approaching to reproducible outputs.

Another great advantage of WebKit Flatpak SDK, at least for the multimedia team, is the possibility of use gst-build to setup a custom GStreamer environment, with latest master, for example.

Now, for sake of brevity, let us sketch an non-complete list of activities and achievements related with WebKit multimedia.

General multimedia

Media Source Extensions (MSE)

Encrypted Media Extension (EME)

One of the major results of this first half, is the upstream of ThunderCDM, which is an implementation of a Content Decryption Module, providing Widevine decryption support. Recently, our colleague Xabier, published a blog post on this regard.

And it has enabled client-side video rendering support, which ensures video frames remain protected in GPU memory so they can’t be reached by third-party. This is a requirement for DRM/EME.

WebRTC

GStreamer

Though we normally contribute in GStreamer with the activities listed above, there are other tasks not related with WebKit. Among these we can enumerate the following:

GStreamer VAAPI

  • Reviewed a lot of patches.
  • Support for media-driver (iHD), the new VAAPI driver for Intel, mostly for Gen9 onwards. There are a lot of features with this driver.
  • A new vaapioverlay element.
  • Deep code cleanups. Among these we would like to mention:
    • Added quirk mechanism for different backends.
    • Change base classes to GstObject and GstMiniObject of most of classes and buffers types.
  • Enhanced caps negotiation given current driver’s constraints

Conclusions

The multimedia team in Igalia has keep working, along the first half of this strange year, in our three main areas: browsers (mainly on WebKitGTK and WPE), video editing and GStreamer framework.

We worked adding and enhancing WebKitGTK and WPE multimedia features in order to offer a solid platform for media providers.

We have enhanced the Video Editing support in GStreamer.

And, along these tasks, we have contribuited as much in GStreamer framework, particulary in hardware accelerated decoding and encoding and VA-API.

by vjaquez at September 07, 2020 03:12 PM



September 04, 2020

WebKitGTK 2.29.92 released!

by The WebKitGTK Project

This is a development release leading toward 2.30 series.

What’s new in the WebKitGTK 2.29.92 release?

  • Fix user agent header after a redirect when a new quirk is required.
  • Stop using firefox user agent quirk for google docs.
  • Fix rendering frames timeline panel in web inspector.
  • Fix per-thread cpu usage in web inspector.
  • Fix several crashes and rendering issues.
  • Translation updates: Polish

Thanks to all the contributors who made possible this release.

September 04, 2020 12:00 AM



September 02, 2020

Serious Encrypted Media Extensions on GStreamer based WebKit ports

by Xabier Rodríguez Calvar

Encrypted Media Extensions (a.k.a. EME) is the W3C standard for encrypted media in the web. This way, media providers such as Hulu, Netflix, HBO, Disney+, Prime Video, etc. can provide their contents with a reasonable amount of confidence that it will make it very complicated for people to “save” their assets without their permission. Why do I use the word “serious” in the title? In WebKit there is already support for Clear Key, which is the W3C EME reference implementation but EME supports more encryption systems, even privative ones (I have my opinion about this, you can ask me privately). No service provider (that I know) supports Clear Key, they usually rely on Widevine, PlayReady or some other.

Three years ago, my colleague Žan Doberšek finished the implementation of what was going to be the shell of WebKit’s modern EME implementation, following latest W3C proposal. We implemented that downstream (at Web Platform for Embedded) as well using Thunder, which includes as a plugin a fork of what was Open Content Decryption Module (a.k.a. OpenCDM). The OpenCDM API changed quite a lot during this journey. It works well and there are millions of set-top-boxes using it currently.

The delta between downstream and the upstream GStreamer based WebKit ports was quite big, testing was difficult and syncing was not always easy, so we decided reverse the situation.

Our first step was done by my colleague Charlie Turner, who made Clear Key work upstream again while adapted some changes the Apple folks had done meanwhile. It was amazing to see Clear Key tests passing again and his work with the CDMProxy related classes was awesome. After having ClearKey working, I had to adapt them a bit to accomodate Thunder. To explain a bit about the WebKit EME architecture, I must say that there are two layers. The first is the crossplatform one, which implements the W3C API (MediaKeys, MediaKeySession, CDM…). These classes rely on the platform ones (CDMPrivate, CDMInstance, CDMInstanceSession) to handle the platform management, message exchange, etc. which would be the second layer. Apple playback system is fully integrated with their DRM system so they don’t need anything else. We do because we need to integrate our own decryptors to defer to Thunder for decryption so in the GStreamer based ports we also need the CDMProxy related classes, which would be CDMProxy, CDMInstanceProxy, CDMInstanceSessionProxy… The last two extend CDMInstance and CDMInstanceSession respectively to be able to deal with the key management, that is abstracted to the KeyHandle and KeyStore.

Once the abstraction is there (let’s remember that the abstranction works both for Clear Key and Thunder), the Thunder implementation is quite simple, just gluing the CDMProxy, CDMInstanceProxy and CDMInstanceSessionProxy classes to the Thunder system and writing a GStreamer decryptor element for it. I might have made a mistake when selecting the files but considering Thunder classes + the GStreamer common decryptor code, cloc says it is just 1198 lines of platform code. I think it is pretty low for what it does. Apart from that, obviously, there are 5760 lines of crossplatform code.

To build and run all this you need to do several things:

  1. Build the dependencies with WEBKIT_JHBUILD=1 JHBUILD_ENABLE_THUNDER="yes" to enable the old fashioned JHBuild build and force it to build the Thunder dependencies. All dependendies are on JHBuild, even Widevine is referenced but to download it you need the proper credentials as it is closed source.
  2. Pass --thunder when calling build-webkit.sh.
  3. Run MiniBrowser with WEBKIT_GST_EME_RANK_PRIORITY="Thunder" and pass parameters --enable-mediasource=TRUE --enable-encrypted-media=TRUE --autoplay-policy=allow. The autoplay policy is usually optional but in this case it is necessary for the YouTube TV tests. We need to give the Thunder decryptor a higher priority because of WebM, that does not specify a key system and without it the Clear Key one can be selected and fail. MP4 does not create trouble because the protection system is specified and the caps negotiation does its magic.

As you could have guessed if you have a closer look at the GStreamer JHBuild moduleset, you’ll see that only Widevine is supported. To support more, you only have to make them build in the Thunder ecosystem and add them to CDMFactoryThunder::supportedKeySystems.

When I coded this, all YouTube TV tests for Widevine were green in the desktop. At the moment of writing this post they aren’t because of some problem with the Widevine installation that will be sorted quickly, I hope.

by calvaris at September 02, 2020 02:59 PM



August 14, 2020

WebKitGTK 2.29.91 released!

by The WebKitGTK Project

This is a development release leading toward 2.30 series.

What’s new in the WebKitGTK 2.29.91 release?

  • Fix a web process crash introduced in 2.29.90.

Thanks to all the contributors who made possible this release.

August 14, 2020 12:00 AM



WebKitGTK 2.29.90 released!

by The WebKitGTK Project

This is a development release leading toward 2.30 series.

What’s new in the WebKitGTK 2.29.90 release?

  • Fix font variation settings when font smoothing setting is also present.
  • Fix HTML drag and drop operations.
  • Fix argument order for clone syscall seccomp filter on s390x.
  • Fix a crash when selecting text.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

August 14, 2020 12:00 AM



August 13, 2020

Improving CSS Custom Properties performance

by Javier Fernández

Chrome 84 reached the stable channel a few weeks ago, and there are already several great posts describing the many important additions, interesting new features, security fixes and improvements in privacy policies (([1], [2], [3], [4]) it contains. However, there is a change that I worked on in this release which might have passed unnoticed by most, but I think is very valuable: A change regarding CSS Custom Properties (variables) performance.

The design of CSS, in general, takes great care in considering how features are designed with respect to making it possible for them to perform well. However, implementations may not perform as well as they could, and it takes a considerable amount of time to understand how authors use the features and which cases are more relevant for them.

CSS Custom Properties are an interesting example to look at here: They are a wonderful feature that provides a lot of advantages for web authors. For a whole lot of cases, all of the implementations of CSS Custom Properties perform well enough that most people won’t notice. However, we at Igalia have been analyzing several use cases and looking at some reports around their performance in different implementations.

Let’s consider a fairly straightforward example in which an author sets a single property in a toggleable class in the body, and then uses that property several times deeper in the tree to change the foreground color of some text.


Only about 20% of those actually use this property, 5 elements deep into the tree, and only to change the foreground color.

To evaluate Chromium’s performance in a case like this we can define a new perf tests, using the perf tools the Chromium project has available for browser engineers. In this case, we want a huge tree so that we can evaluate better the impact of the different optimizations.

    

These are the results obtained runing the test in Chrome 83:

avg median stdev min max
163.74 ms 163.79 ms 3.69 ms 158.59 ms 163.74 ms

I admit that it’s difficult to evaluate the results, especially considering the number of nodes of such a huge DOM tree. Lets compare the results of the same test on Firefox, using different number of nodes.

Nodes 50K 20K 10K 5K 1K 500
Chrome 83 163.74 ms 55.05 ms 25.12 ms 14.18 ms 2.74 ms 1.50 ms
FF 78 28.35 ms 12.05 ms 6.10 ms 3.50 ms 1.15 ms 0.55 ms
1/6 1/5 1/4 1/4 1/2 1/3

As I commented before, the data are more accurate when the DOM tree has a lot of nodes; in any case, the difference is quite clear and shows there is plenty room for improvement. WebKit based browsers have results more similar to Chromium as well.

Performance tests like the one above can be added to browsers for tracking improvements and regressions over time, so we’ve added (r763335) that to Chromium’s tree: We’d like to see it get faster over time, and definitely cannot afford regressions (see Chrome Performance Dashboard and the ChangeStyleCustomPropertyDeclaration test for details) .

So… What can we do?

In Chrome 83 and lower, whenever the custom property declaration changed, the new declaration would be inherited by the whole tree. This inheritance implied executing the whole CSS cascade and recalculating the styles of all the nodes in the entire tree, since with this approach, all nodes may be affected.

Chrome had already implemented an optimization on the CSS cascade implementation for regular CSS properties that don’t depend on any other to resolve their value. These subset of CSS properties are defined as Independent Properties in the Chromium codebase. The optimization mentioned before affects how the inheritance mechanism is implemented for these Independent properties. Whenever one of these properties changes, instead of recalculating the styles of the inherited properties, children can just copy the whole parent’s computed style. Blink’s style engine has a component known as Matched Properties Cache responsible of deciding when is possible to avoid the style resolution of an element and instead, performing an efficient copy of the matched computed style. I’ll get back to this concept in the last part of this post.

In the case of CSS Custom Properties, we could apply a similar approach as a good step. We can consider that the nodes with computed styles that don’t have references to custom properties declarations shouldn’t be affected by the new declaration, and we can implement the inheritance directly by copying the parent’s computed style. The patch with the optimization I’ve implemented in r765278 initially landed in Chrome 84.0.4137.0

Let’s look at the result of this one action in the Chrome Performance Dashboard:

That’s a really good improvement!

However, it’s also just a first step. It’s clear that Chrome still has a wide margin for improvement in this case, as well any WebKit based browser – Firefox is still, impressively, markedly faster as it’s been described in the bug report filed to track this issue. The following table shows the result of the different browsers together; even disabling the muti-thread capabilities of Firefox’s Stylo engine (STYLO_THREAD=1), FF is much faster than Chrome with the optimization applied.

Chrome 83 Chrome 84 FF 78 FF 78 th=1
avg
median
stdev
min
max
163.74 ms
163.79 ms
3.69 ms
158.59 ms
163.74 ms
117.37 ms
117.52 ms
1.98 ms
113.66 ms
120.87 ms
28.35 ms
28.50 ms
0.93 ms
26.00 ms
30.00 ms
38.25 ms
38.50 ms
1.86 ms
35.00 ms
41.00 ms

Before continue, I want get back to the Matched Properties Cache (MPC) concept, since it has an important role on these style optimizations. This cache is not a new concept in the Chrome’s engine; as a matter of fact, it’s also used in WebKit, since it was implemented long ago, before the fork that created the new blink engine. However, Google has been working a lot on this area in the last years and some of the most recent changes in the MPC have had an important impact on style resolution performance. As a result of this work, elements with independent and non-independent properties using CSS Variables might produce cache hits in the MPC. The results of the Performance Dashboard show a considerable improvement in the mentioned ChangeStyleCustomPropertyDeclaration test (avg: 108.06 ms)

Additionally, there are several other cases where the use of CSS Variables has a considerable impact on performance, compared with using regular CSS properties. Obviously, resolving CSS Variables has a cost, so it’s clear that we could apply additional optimizations that reduce the impact of the variable resolution, especially for handling specific style changes that might not affect to a substantial portion of the DOM tree. I’ve been experimenting with the MPC to explore the idea an independent CSS Custom Properties cache; nodes with variables referencing the same custom property will produce cache hits in the MPC, even though other properties don’t match. The preliminary approach I’ve been implementing consists on a new matching function, specific for custom properties, and a mechanism to transfer/copy the property’s data to avoid resolving the variable again, since the property’s declaration hasn’t change. We would need to apply the css cascade again, but at least we could save the cost of the variable resolution.

Of course, at the end of the day, improving performance has costs and challenges – and it’s hard to keep performance even once you get it. Bit if we really want performant CSS Custom Properties, this means that we have to decide to prioritize this work. Currently there is reluctance to explore the concept of a new Custom Properties specific cache – the challenge is big and the risks are not non-existent; cache invalidation can get complicated. But, the point is that we have to understand that we aren’t all going to agree what is important enough to warrant attention, or how much investment, or when. Web authors must convince vendors that these use cases are worth being optimized and that the cost and risks of such a complex challenges should be assumed by them.

This work has been sponsored by Bloomberg, which I consider one of the most important contributors of the Web Platform. After several years, the vision of this company and its responsibility as consumer of the platform has lead to many and important contributions that we all enjoy now. Although CSS Grid Layout might be the most remarkable one, there are may other not that big, like this work on CSS Custom Properties, or several other new features of the CSS Text specification. This is a perfect example of an company that tries to change priorities and adapt the web platform to its needs and the use cases they consider more aligned with their business strategy.

I understand that not every user of the web platform can do this kind of investment. This is why I believe that initiatives like Open Priorization could help to move the web platform in a positive direction. By providing a way for us to move past a lot of these conversation and focus on the needs that some web authors and users of the platform consider more important, or higher priority. Improving performance for CSS Custom Properties isn’t currently one of the projects we’ve listed, but perhaps it would be an interesting one we might try in the future if we are successful with these. If you haven’t already, have a look and see if there is something there that is interesting to you or your company – pledges of any size are good – ten thousand $1 donations are every bit as good as ten $1000 donations. Together, we can make a difference, and we all benefit.

Also, we would love to hear about your ideas. Is improving CSS Custom Properties performance important to you? What else is? Share your comments with us on Twitter, either me (@lajava77) or our developer advocate Brian Kardell (@briankardell), or email me at jfernandez@igalia.com. I’d be glad to answer any question about the Open Priorization experiment.

by jfernandez at August 13, 2020 06:16 PM



July 29, 2020

WebKitGTK and WPE WebKit Security Advisory WSA-2020-0007

by The WebKitGTK Project

Several vulnerabilities were discovered in WebKitGTK and WPE WebKit.

  • CVE-2020-9862
    • Versions affected: WebKitGTK before 2.28.4 and WPE WebKit before 2.28.4.
    • Credit to Ophir Lojkine (@lovasoa).
    • Impact: Copying a URL from Web Inspector may lead to command injection. Description: A command injection issue existed in Web Inspector. This issue was addressed with improved escaping.
  • CVE-2020-9893
    • Versions affected: WebKitGTK before 2.28.4 and WPE WebKit before 2.28.4.
    • Credit to 0011 working with Trend Micro Zero Day Initiative.
    • Impact: A remote attacker may be able to cause unexpected application termination or arbitrary code execution. Description: An use-after-free issue was addressed with improved memory management.
  • CVE-2020-9894
    • Versions affected: WebKitGTK before 2.28.4 and WPE WebKit before 2.28.4.
    • Credit to 0011 working with Trend Micro Zero Day Initiative.
    • Impact: A remote attacker may be able to cause unexpected application termination or arbitrary code execution. Description: An out-of-bounds read was addressed with improved input validation.
  • CVE-2020-9895
    • Versions affected: WebKitGTK before 2.28.4 and WPE WebKit before 2.28.4.
    • Credit to Wen Xu of SSLab, Georgia Tech.
    • Impact: A remote attacker may be able to cause unexpected application termination or arbitrary code execution. Description: An use-after-free issue was addressed with improved memory management.
  • CVE-2020-9915
    • Versions affected: WebKitGTK before 2.28.4 and WPE WebKit before 2.28.4.
    • Credit to Ayoub AIT ELMOKHTAR of Noon.
    • Impact: Processing maliciously crafted web content may prevent Content Security Policy from being enforced. Description: An access issue existed in Content Security Policy. This issue was addressed with improved access restrictions.
  • CVE-2020-9925
    • Versions affected: WebKitGTK before 2.28.4 and WPE WebKit before 2.28.4.
    • Credit to an anonymous researcher.
    • Impact: Processing maliciously crafted web content may lead to universal cross site scripting. Description: A logic issue was addressed with improved state management.

We recommend updating to the latest stable versions of WebKitGTK and WPE WebKit. It is the best way to ensure that you are running safe versions of WebKit. Please check our websites for information about the latest stable releases.

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

July 29, 2020 12:00 AM



WebKitGTK 2.29.4 released!

by The WebKitGTK Project

This is a development release leading toward 2.30 series.

What’s new in the WebKitGTK 2.29.4 release?

  • Add support for backdrop filters.
  • Add support for text-underline-offset and text-decoration-thickness.
  • Add OpenCDM and AV1 support to media backend.
  • Add new API to get ITP data summary.
  • Use mobile user-agent on tablets.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

July 29, 2020 12:00 AM



July 28, 2020

WebKitGTK 2.28.4 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.4 release?

  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

July 28, 2020 12:00 AM



July 10, 2020

WebKitGTK and WPE WebKit Security Advisory WSA-2020-0006

by The WebKitGTK Project

Several vulnerabilities were discovered in WebKitGTK and WPE WebKit.

  • CVE-2020-9802
    • Versions affected: WebKitGTK before 2.28.3 and WPE WebKit before 2.28.3.
    • Credit to Samuel Groß of Google Project Zero.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: A logic issue was addressed with improved restrictions.
  • CVE-2020-9803
    • Versions affected: WebKitGTK before 2.28.3 and WPE WebKit before 2.28.3.
    • Credit to Wen Xu of SSLab at Georgia Tech.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: A memory corruption issue was addressed with improved validation.
  • CVE-2020-9805
    • Versions affected: WebKitGTK before 2.28.3 and WPE WebKit before 2.28.3.
    • Credit to an anonymous researcher.
    • Impact: Processing maliciously crafted web content may lead to universal cross site scripting. Description: A logic issue was addressed with improved restrictions.
  • CVE-2020-9806
    • Versions affected: WebKitGTK before 2.28.3 and WPE WebKit before 2.28.3.
    • Credit to Wen Xu of SSLab at Georgia Tech.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: A memory corruption issue was addressed with improved state management.
  • CVE-2020-9807
    • Versions affected: WebKitGTK before 2.28.3 and WPE WebKit before 2.28.3.
    • Credit to Wen Xu of SSLab at Georgia Tech.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: A memory corruption issue was addressed with improved state management.
  • CVE-2020-9843
    • Versions affected: WebKitGTK before 2.28.3 and WPE WebKit before 2.28.3.
    • Credit to Ryan Pickren (ryanpickren.com).
    • Impact: Processing maliciously crafted web content may lead to a cross site scripting attack. Description: An input validation issue was addressed with improved input validation.
  • CVE-2020-9850
    • Versions affected: WebKitGTK before 2.28.3 and WPE WebKit before 2.28.3.
    • Credit to @jinmo123, @setuid0x0_, and @insu_yun_en of @SSLab_Gatech working with Trend Micro’s Zero Day Initiative.
    • Impact: A remote attacker may be able to cause arbitrary code execution. Description: A logic issue was addressed with improved restrictions.
  • CVE-2020-13753
    • Versions affected: WebKitGTK before 2.28.3 and WPE WebKit before 2.28.3.
    • Credit to Milan Crha at Red Hat.
    • The bubblewrap sandbox of WebKitGTK and WPE WebKit, prior to 2.28.3, failed to properly block access to CLONE_NEWUSER and the TIOCSTI ioctl. CLONE_NEWUSER could potentially be used to confuse xdg- desktop-portal, which allows access outside the sandbox. TIOCSTI can be used to directly execute commands outside the sandbox by writing to the controlling terminal’s input buffer, similar to CVE-2017-5226.

We recommend updating to the latest stable versions of WebKitGTK and WPE WebKit. It is the best way to ensure that you are running safe versions of WebKit. Please check our websites for information about the latest stable releases.

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

July 10, 2020 12:00 AM



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