April 06, 2017

WebKitGTK+ Security Advisory WSA-2017-0003

by The WebKitGTK+ Project

Several vulnerabilities were discovered in WebKitGTK+.

  • CVE-2016-9642
    • Versions affected: WebKitGTK+ before 2.16.0.
    • Credit to Gustavo Grieco.
    • JavaScriptCore in WebKit allows attackers to cause a denial of service (out-of-bounds heap read) via a crafted Javascript file.
  • CVE-2016-9643
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to Gustavo Grieco.
    • The regex code in WebKit allows remote attackers to cause a denial of service (memory consumption) as demonstrated in a large number of ($ (open parenthesis and dollar) followed by {-2,16} and a large number of +) (plus close parenthesis).
  • CVE-2017-2364
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to lokihardt of Google Project Zero.
    • This issue allows remote attackers to bypass the Same Origin Policy and obtain sensitive information via a crafted web site.
  • CVE-2017-2367
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to lokihardt of Google Project Zero.
    • This issue allows remote attackers to bypass the Same Origin Policy and obtain sensitive information via a crafted web site.
  • CVE-2017-2376
    • Versions affected: WebKitGTK+ before 2.16.0.
    • Credit to an anonymous researcher, Chris Hlady of Google Inc, Yuyang Zhou of Tencent Security Platform Department (security.tencent.com), Muneaki Nishimura (nishimunea) of Recruit Technologies Co., Ltd., Michal Zalewski of Google Inc, an anonymous researcher.
    • This issue allows remote attackers to spoof the address bar by leveraging text input during the loading of a page.
  • CVE-2017-2377
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to Vicki Pfau.
    • This issue involves the “WebKit Web Inspector” component. It allows attackers to cause a denial of service (memory corruption and application crash) by leveraging a window-close action during a debugger-pause state.
  • CVE-2017-2386
    • Versions affected: WebKitGTK+ before 2.16.0.
    • Credit to André Bargull.
    • This issue allows remote attackers to bypass the Same Origin Policy and obtain sensitive information via a crafted web site.
  • CVE-2017-2392
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to Max Bazaliy of Lookout.
    • This issue allows attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted app.
  • CVE-2017-2394
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to Apple.
    • This issue allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted web site.
  • CVE-2017-2395
    • Versions affected: WebKitGTK+ before 2.16.0.
    • Credit to Apple.
    • This issue allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted web site.
  • CVE-2017-2396
    • Versions affected: WebKitGTK+ before 2.16.0.
    • Credit to Apple.
    • This issue allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted web site.
  • CVE-2017-2405
    • Versions affected: WebKitGTK+ before 2.16.0.
    • Credit to Apple.
    • This issue involves the “WebKit Web Inspector” component. It allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted web site.
  • CVE-2017-2415
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to Kai Kang of Tencent’s Xuanwu Lab (tentcent.com).
    • This issue allows remote attackers to execute arbitrary code by leveraging an unspecified “type confusion.”.
  • CVE-2017-2419
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to Nicolai Grødum of Cisco Systems.
    • This issue allows remote attackers to bypass a Content Security Policy protection mechanism via unspecified vectors.
  • CVE-2017-2433
    • Versions affected: WebKitGTK+ before 2.16.0.
    • Credit to Apple.
    • This issue allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted web site.
  • CVE-2017-2442
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to lokihardt of Google Project Zero.
    • This issue involves the “WebKit JavaScript Bindings” component. It allows remote attackers to bypass the Same Origin Policy and obtain sensitive information via a crafted web site.
  • CVE-2017-2445
    • Versions affected: WebKitGTK+ before 2.16.0.
    • Credit to lokihardt of Google Project Zero.
    • This issue allows remote attackers to conduct Universal XSS (UXSS) attacks via crafted frame objects.
  • CVE-2017-2446
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to Natalie Silvanovich of Google Project Zero.
    • This issue allows remote attackers to execute arbitrary code via a crafted web site that leverages the mishandling of strict mode functions.
  • CVE-2017-2447
    • Versions affected: WebKitGTK+ before 2.16.0.
    • Credit to Natalie Silvanovich of Google Project Zero.
    • This issue allows remote attackers to obtain sensitive information or cause a denial of service (memory corruption) via a crafted web site.
  • CVE-2017-2454
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to Ivan Fratric of Google Project Zero.
    • This issue allows allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted web site.
  • CVE-2017-2455
    • Versions affected: WebKitGTK+ before 2.16.0.
    • Credit to Ivan Fratric of Google Project Zero.
    • This issue allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted web site.
  • CVE-2017-2457
    • Versions affected: WebKitGTK+ before 2.16.0.
    • Credit to lokihardt of Google Project Zero.
    • This issue allows allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted web site.
  • CVE-2017-2459
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to Ivan Fratric of Google Project Zero.
    • This issue allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted web site.
  • CVE-2017-2460
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to Ivan Fratric of Google Project Zero.
    • This issue allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted web site.
  • CVE-2017-2464
    • Versions affected: WebKitGTK+ before 2.16.0.
    • Credit to Jeonghoon Shin, Natalie Silvanovich of Google Project Zero.
    • This issue allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted web site.
  • CVE-2017-2465
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to Zheng Huang and Wei Yuan of Baidu Security Lab.
    • This issue allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted web site.
  • CVE-2017-2466
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to Ivan Fratric of Google Project Zero.
    • This issue allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted web site.
  • CVE-2017-2468
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to lokihardt of Google Project Zero.
    • This issue allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted web site.
  • CVE-2017-2469
    • Versions affected: WebKitGTK+ before 2.16.0.
    • Credit to lokihardt of Google Project Zero.
    • This issue allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted web site.
  • CVE-2017-2470
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to lokihardt of Google Project Zero.
    • This issue allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted web site.
  • CVE-2017-2471
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to Ivan Fratric of Google Project Zero.
    • A use-after-free vulnerability allows remote attackers to execute arbitrary code via a crafted web site.
  • CVE-2017-2475
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to lokihardt of Google Project Zero.
    • This issue allows remote attackers to conduct Universal XSS (UXSS) attacks via crafted use of frames on a web site.
  • CVE-2017-2476
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to Ivan Fratric of Google Project Zero.
    • This issue allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted web site.
  • CVE-2017-2481
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to 0011 working with Trend Micro’s Zero Day Initiative.
    • This issue allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted web site.

We recommend updating to the last stable version of WebKitGTK+. It is the best way of ensuring that you are running a safe version of WebKitGTK+. Please check our website for information about the last stable releases.

Further information about WebKitGTK+ Security Advisories can be found at: https://webkitgtk.org/security.html

April 06, 2017 12:00 AM



WebKitGTK+ 2.14.6 released!

by The WebKitGTK+ Project

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

What’s new in the WebKitGTK+ 2.14.6 release?

Thanks to all the contributors who made possible this release.

April 06, 2017 12:00 AM



April 04, 2017

WebKitGTK+ 2.16.1 released!

by The WebKitGTK+ Project

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

What’s new in the WebKitGTK+ 2.16.1 release?

  • Fix no-third-party cookies policy in case of redirections.
  • Keep URL fragments after server redirections.
  • Honor GTK+ font settings.
  • Ensure depth and stencil renderbuffers are created on GLESv2.
  • Prevent new navigations from onbeforeunload handler and document unload.
  • Disallow beforeunload alerts from web pages users have never interacted with.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

April 04, 2017 12:00 AM



March 24, 2017

A Web Browser for Awesome People (Epiphany 3.24)

by Michael Catanzaro

Are you using a sad web browser that integrates poorly with GNOME or elementary OS? Was your sad browser’s GNOME integration theme broken for most of the past year? Does that make you feel sad? Do you wish you were using an awesome web browser that feels right at home in your chosen desktop instead? If so, Epiphany 3.24 might be right for you. It will make you awesome. (Ask your doctor before switching to a new web browser. Results not guaranteed. May cause severe Internet addiction. Some content unsuitable for minors.)

Epiphany was already awesome before, but it just keeps getting better. Let’s look at some of the most-noticeable new features in Epiphany 3.24.

You Can Load Webpages!

Yeah that’s a great start, right? But seriously: some people had trouble with this before, because it was not at all clear how to get to Epiphany’s address bar. If you were in the know, you knew all you had to do was click on the title box, then the address bar would appear. But if you weren’t in the know, you could be stuck. I made the executive decision that the title box would have to go unless we could find a way to solve the discoverability problem, and wound up following through on removing it. Now the address bar is always there at the top of the screen, just like in all those sad browsers. This is without a doubt our biggest user interface change:

Screenshot showing address bar visible
Discover GNOME 3! Discover the address bar!

You Can Set a Homepage!

A very small subset of users have complained that Epiphany did not allow setting a homepage, something we removed several years back since it felt pretty outdated. While I’m confident that not many people want this, there’s not really any good reason not to allow it — it’s not like it’s a huge amount of code to maintain or anything — so you can now set a homepage in the preferences dialog, thanks to some work by Carlos García Campos and myself. Retro! Carlos has even added a home icon to the header bar, which appears when you have a homepage set. I honestly still don’t understand why having a homepage is useful, but I hope this allows a wider audience to enjoy Epiphany.

New Bookmarks Interface

There is now a new star icon in the address bar for bookmarking pages, and another new icon for viewing bookmarks. Iulian Radu gutted our old bookmarks system as part of his Google Summer of Code project last year, replacing our old and seriously-broken bookmarks dialog with something much, much nicer. (He also successfully completed a major refactoring of non-bookmarks code as part of his project. Thanks Iulian!) Take a look:

Manage Tons of Tabs

One of our biggest complaints was that it’s hard to manage a large number of tabs. I spent a few hours throwing together the cheapest-possible solution, and the result is actually pretty decent:

Firefox has an equivalent feature, but Chrome does not. Ours is not perfect, since unfortunately the menu is not scrollable, so it still fails if there is a sufficiently-huge number of tabs. (This is actually surprisingly-difficult to fix while keeping the menu a popover, so I’m considering switching it to a traditional non-popover menu as a workaround. Help welcome.) But it works great up until the point where the popover is too big to fit on your monitor.

Note that the New Tab button has been moved to the right side of the header bar when there is only one tab open, so it has less distance to travel to appear in the tab bar when there are multiple open tabs.

Improved Tracking Protection

I modified our adblocker — which has been enabled by default for years — to subscribe to the EasyPrivacy filters provided by EasyList. You can disable it in preferences if you need to, but I haven’t noticed any problems caused by it, so it’s enabled by default, not just in incognito mode. The goal is to compete with Firefox’s Disconnect feature. How well does it work compared to Disconnect? I have no clue! But EasyPrivacy felt like the natural solution, since we already have an adblocker that supports EasyList filters.

Disclaimer: tracking protection on the Web is probably a losing battle, and you absolutely must use the Tor Browser Bundle if you really need anonymity. (And no, configuring Epiphany to use Tor is not clever, it’s very dumb.) But EasyPrivacy will at least make life harder for trackers.

Insecure Password Form Warning

Recently, Firefox and Chrome have started displaying security warnings  on webpages that contain password forms but do not use HTTPS. Now, we do too:

I had a hard time selecting the text to use for the warning. I wanted to convey the near-certainty that the insecure communication is being intercepted, but I wound up using the word “cybercriminal” when it’s probably more likely that your password is being gobbled up by various  governments. Feel free to suggest changes for 3.26 in the comments.

New Search Engine Manager

Cedric Le Moigne spent a huge amount of time gutting our smart bookmarks code — which allowed adding custom search engines to the address bar dropdown in a convoluted manner that involved creating a bookmark and manually adding %s into its URL — and replacing it with an actual real search engine manager that’s much nicer than trying to add a search engine via bookmarks. Even better, you no longer have to drop down to the command line in order to change the default search engine to something other than DuckDuckGo, Google, or Bing. Yay!

New Icon

Jakub Steiner and Lapo Calamandrei created a great new high-resolution app icon for Epiphany, which makes its debut in 3.24. Take a look.

WebKitGTK+ 2.16

WebKitGTK+ 2.16 improvements are not really an Epiphany 3.24 feature, since users of older versions of Epiphany can and must upgrade to WebKitGTK+ 2.16 as well, but it contains some big improvements that affect Epiphany. (For example, Žan Doberšek landed an important fix for JavaScript garbage collection that has resulted in massive memory reductions in long-running web processes.) But sometimes WebKit improvements are necessary for implementing new Epiphany features. That was true this cycle more than ever. For example:

  • Carlos García added a new ephemeral mode API to WebKitGTK+, and modified Epiphany to use it in order to make incognito mode much more stable and robust, avoiding corner cases where your browsing data could be leaked on disk.
  • Carlos García also added a new website data API to WebKitGTK+, and modified Epiphany to use it in the clear data dialog and cookies dialog. There are no user-visible changes in the cookies dialog, but the clear data dialog now exposes HTTP disk cache, HTML local storage, WebSQL, IndexedDB, and offline web application cache. In particular, local storage and the two databases can be thought of as “supercookies”: methods of storing arbitrary data on your computer for tracking purposes, which persist even when you clear your cookies. Unfortunately it’s still not possible to protect against this tracking, but at least you can view and delete it all now, which is not possible in Chrome or Firefox.
  • Sergio Villar Senin added new API to WebKitGTK+ to improve form detection, and modified Epiphany to use it so that it can now remember passwords on more websites. There’s still room for improvement here, but it’s a big step forward.
  • I added new API to WebKitGTK+ to improve how we handle giving websites permission to display notifications, and hooked it up in Epiphany. This fixes notification requests appearing inappropriately on websites like the https://riot.im/app/.

Notice the pattern? When there’s something we need to do in Epiphany that requires changes in WebKit, we make it happen. This is a lot more work, but it’s better for both Epiphany and WebKit in the long run. Read more about WebKitGTK+ 2.16 on Carlos García’s blog.

Future Features

Unfortunately, a couple exciting Epiphany features we were working on did not make the cut for Epiphany 3.24. The first is Firefox Sync support. This was developed by Gabriel Ivașcu during his Google Summer of Code project last year, and it’s working fairly well, but there are still a few problems. First, our current Firefox Sync code is only able to sync bookmarks, but we really want it to sync much more before releasing the feature: history and open tabs at the least. Also, although it uses Mozilla’s sync server (please thank Mozilla for their quite liberal terms of service allowing this!), it’s not actually compatible with Firefox. You can sync your Epiphany bookmarks between different Epiphany browser instances using your Firefox account, which is great, but we expect users will be quite confused that they do not sync with your Firefox bookmarks, which are stored separately. Some things, like preferences, will never be possible to sync with Firefox, but we can surely share bookmarks. Gabriel is currently working to address these issues while participating in the Igalia Coding Experience program, and we’re hopeful that sync support will be ready for prime time in Epiphany 3.26.

Also missing is HTTPS Everywhere support. It’s mostly working properly, thanks to lots of hard work from Daniel Brendle (grindhold) who created the libhttpseverywhere library we use, but it breaks a few websites and is not really robust yet, so we need more time to get this properly integrated into Epiphany. The goal is to make sure outdated HTTPS Everywhere rulesets do not break websites by falling back automatically to use of plain, insecure HTTP when a load fails. This will be much less secure than upstream HTTPS Everywhere, but websites that care about security ought to be redirecting users to HTTPS automatically (and also enabling HSTS). Our use of HTTPS Everywhere will just be to gain a quick layer of protection against passive attackers. Otherwise, we would not be able to enable it by default, since the HTTPS Everywhere rulesets are just not reliable enough. Expect HTTPS Everywhere to land for Epiphany 3.26.

Help Out

Are you a computer programmer? Found something less-than-perfect about Epiphany? We’re open for contributions, and would really appreciate it if you would try to fix that bug or add that feature instead of slinking back to using a less-awesome web browser. One frequently-requested feature is support for extensions. This is probably not going to happen anytime soon — we’d like to support WebExtensions, but that would be a huge effort — but if there’s some extension you miss from a sadder browser, ask if we’d allow building it into Epiphany as a regular feature. Replacements for popular extensions like NoScript and Greasemonkey would certainly be welcome.

Not a computer programmer? You can still help by reporting bugs on GNOME Bugzilla. If you have a crash to report, learn how to generate a good-quality stack trace so that we can try to fix it. I’ve credited many programmers for their work on Epiphany 3.24 up above, but programming work only gets us so far if we don’t know about bugs. I want to give a shout-out here to Hussam Al-Tayeb, who regularly built the latest code over the course of the 3.24 development cycle and found lots of problems for us to fix. This release would be much less awesome if not for his testing.

OK, I’m done typing stuff now. Onwards to 3.26!

by Michael Catanzaro at March 24, 2017 01:18 AM



March 20, 2017

WebKitGTK+ 2.16

by Carlos García Campos

The Igalia WebKit team is happy to announce WebKitGTK+ 2.16. This new release drastically improves the memory consumption, adds new API as required by applications, includes new debugging tools, and of course fixes a lot of bugs.

Memory consumption

After WebKitGTK+ 2.14 was released, several Epiphany users started to complain about high memory usage of WebKitGTK+ when Epiphany had a lot of tabs open. As we already explained in a previous post, this was because of the switch to the threaded compositor, that made hardware acceleration always enabled. To fix this, we decided to make hardware acceleration optional again, enabled only when websites require it, but still using the threaded compositor. This is by far the major improvement in the memory consumption, but not the only one. Even when in accelerated compositing mode, we managed to reduce the memory required by GL contexts when using GLX, by using OpenGL version 3.2 (core profile) if available. In mesa based drivers that means that software rasterizer fallback is never required, so the context doesn’t need to create the software rasterization part. And finally, an important bug was fixed in the JavaScript garbage collector timers that prevented the garbage collection to happen in some cases.

CSS Grid Layout

Yes, the future here and now available by default in all WebKitGTK+ based browsers and web applications. This is the result of several years of great work by the Igalia web platform team in collaboration with bloomberg. If you are interested, you have all the details in Manuel’s blog.

New API

The WebKitGTK+ API is quite complete now, but there’s always new things required by our users.

Hardware acceleration policy

Hardware acceleration is now enabled on demand again, when a website requires to use accelerated compositing, the hardware acceleration is enabled automatically. WebKitGTK+ has environment variables to change this behavior, WEBKIT_DISABLE_COMPOSITING_MODE to never enable hardware acceleration and WEBKIT_FORCE_COMPOSITING_MODE to always enabled it. However, those variables were never meant to be used by applications, but only for developers to test the different code paths. The main problem of those variables is that they apply to all web views of the application. Not all of the WebKitGTK+ applications are web browsers, so it can happen that an application knows it will never need hardware acceleration for a particular web view, like for example the evolution composer, while other applications, especially in the embedded world, always want hardware acceleration enabled and don’t want to waste time and resources with the switch between modes. For those cases a new WebKitSetting hardware-acceleration-policy has been added. We encourage everybody to use this setting instead of the environment variables when upgrading to WebKitGTk+ 2.16.

Network proxy settings

Since the switch to WebKit2, where the SoupSession is no longer available from the API, it hasn’t been possible to change the network proxy settings from the API. WebKitGTK+ has always used the default proxy resolver when creating the soup context, and that just works for most of our users. But there are some corner cases in which applications that don’t run under a GNOME environment want to provide their own proxy settings instead of using the proxy environment variables. For those cases WebKitGTK+ 2.16 includes a new UI process API to configure all proxy settings available in GProxyResolver API.

Private browsing

WebKitGTK+ has always had a WebKitSetting to enable or disable the private browsing mode, but it has never worked really well. For that reason, applications like Epiphany has always implemented their own private browsing mode just by using a different profile directory in tmp to write all persistent data. This approach has several issues, for example if the UI process crashes, the profile directory is leaked in tmp with all the personal data there. WebKitGTK+ 2.16 adds a new API that allows to create ephemeral web views which never write any persistent data to disk. It’s possible to create ephemeral web views individually, or create ephemeral web contexts where all web views associated to it will be ephemeral automatically.

Website data

WebKitWebsiteDataManager was added in 2.10 to configure the default paths on which website data should be stored for a web context. In WebKitGTK+ 2.16 the API has been expanded to include methods to retrieve and remove the website data stored on the client side. Not only persistent data like HTTP disk cache, cookies or databases, but also non-persistent data like the memory cache and session cookies. This API is already used by Epiphany to implement the new personal data dialog.

Dynamically added forms

Web browsers normally implement the remember passwords functionality by searching in the DOM tree for authentication form fields when the document loaded signal is emitted. However, some websites add the authentication form fields dynamically after the document has been loaded. In those cases web browsers couldn’t find any form fields to autocomplete. In WebKitGTk+ 2.16 the web extensions API includes a new signal to notify when new forms are added to the DOM. Applications can connect to it, instead of document-loaded to start searching for authentication form fields.

Custom print settings

The GTK+ print dialog allows the user to add a new tab embedding a custom widget, so that applications can include their own print settings UI. Evolution used to do this, but the functionality was lost with the switch to WebKit2. In WebKitGTK+ 2.16 a similar API to the GTK+ one has been added to recover that functionality in evolution.

Notification improvements

Applications can now set the initial notification permissions on the web context to avoid having to ask the user everytime. It’s also possible to get the tag identifier of a WebKitNotification.

Debugging tools

Two new debugged tools are now available in WebKitGTk+ 2.16. The memory sampler and the resource usage overlay.

Memory sampler

This tool allows to monitor the memory consumption of the WebKit processes. It can be enabled by defining the environment variable WEBKIT_SMAPLE_MEMORY. When enabled, the UI process and all web process will automatically take samples of memory usage every second. For every sample a detailed report of the memory used by the process is generated and written to a file in the temp directory.

$ WEBKIT_SAMPLE_MEMORY=1 MiniBrowser 
Started memory sampler for process MiniBrowser 32499; Sampler log file stored at: /tmp/MiniBrowser7ff2246e-406e-4798-bc83-6e525987aace
Started memory sampler for process WebKitWebProces 32512; Sampler log file stored at: /tmp/WebKitWebProces93a10a0f-84bb-4e3c-b257-44528eb8f036

The files contain a list of sample reports like this one:

Timestamp                          1490004807
Total Program Bytes                1960214528
Resident Set Bytes                 84127744
Resident Shared Bytes              68661248
Text Bytes                         4096
Library Bytes                      0
Data + Stack Bytes                 87068672
Dirty Bytes                        0
Fast Malloc In Use                 86466560
Fast Malloc Committed Memory       86466560
JavaScript Heap In Use             0
JavaScript Heap Committed Memory   49152
JavaScript Stack Bytes             2472
JavaScript JIT Bytes               8192
Total Memory In Use                86477224
Total Committed Memory             86526376
System Total Bytes                 16729788416
Available Bytes                    5788946432
Shared Bytes                       1037447168
Buffer Bytes                       844214272
Total Swap Bytes                   1996484608
Available Swap Bytes               1991532544

Resource usage overlay

The resource usage overlay is only available in Linux systems when WebKitGTK+ is built with ENABLE_DEVELOPER_MODE. It allows to show an overlay with information about resources currently in use by the web process like CPU usage, total memory consumption, JavaScript memory and JavaScript garbage collector timers information. The overlay can be shown/hidden by pressing CTRL+Shit+G.

We plan to add more information to the overlay in the future like memory cache status.

by carlos garcia campos at March 20, 2017 03:19 PM



WebKitGTK+ 2.16.0 released!

by The WebKitGTK+ Project

This is the first stable release in the 2.16 series.

Highlights of the WebKitGTK+ 2.16.0 release

  • Hardware acceleration is now enabled on demand to drastically reduce memory consumption.
  • CSS Grid Layout is enabled by default.
  • New WebKitSetting to set the hardware acceleration policy.
  • UI process API to configure network proxy settings.
  • Improved private browsing by adding new API to create ephemeral web views.
  • New API to handle website data.
  • Debug tools: memory sampler and resource usage overlay

For more details about all the changes included in WebKitGTK+ 2.16 see the NEWS file that is included in the tarball, or see:

http://blogs.igalia.com/carlosgc/2017/03/20/webkitgtk-2-16/

Thanks to all the contributors who made possible this release.

March 20, 2017 12:00 AM



March 14, 2017

WebKitGTK+ 2.15.92 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.16 series.

What’s new in the WebKitGTK+ 2.15.92 release?

  • Show the context menu when triggered by the keyboard.
  • Fix web process deadlocks when destroying the media player.
  • Fix web process crashes when loading animated GIFs.
  • Fix several crashes and rendering issues.
  • Translation updates: Polish.

Thanks to all the contributors who made possible this release.

March 14, 2017 12:00 AM



March 01, 2017

WebKitGTK+ 2.15.91 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.16 series.

What’s new in the WebKitGTK+ 2.15.91 release?

  • Fix rendering artifacts when resizing the window in accelerated compositing mode.
  • Remove flickering when leaving accelerated compositing mode.
  • Fix a web process crash when loading duck duck go.
  • Properly handle copy drag and drop operations.
  • Fix a hang when sending an IPC messages fails because socket read buffers are full.
  • Ensure we never try to load GTK2 plugins in Wayland.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

March 01, 2017 12:00 AM



February 20, 2017

WebKitGTK+ 2.15.90 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.16 series.

What’s new in the WebKitGTK+ 2.15.90 release?

  • Add an API to add a custom tab into the print dialog.
  • Update cookie manager API to properly work with ephemeral sessions.
  • Fix rendering issues in long documents with transparent background.
  • Handle extended colors in cairo and texture mapper backends.
  • Release unused UpdateAtlas and reduce the tile coverage on memory pressure.
  • The media backend now stores preloaded media in /var/tmp instead of user cache dir.
  • Fix a deadlock when the media player is destroyed.
  • Fast replay on video hide/unhide on platforms with limited video buffer pools.
  • Fix network process crashes when loading custom URI schemes.
  • Fix video rendering when switching to accelerated compositing mode.
  • Fix several crashes and rendering issues.
  • Translation updates: Brazilian Portuguese.

Thanks to all the contributors who made possible this release.

February 20, 2017 12:00 AM



February 15, 2017

WebKitGTK+ 2.14.5 released!

by The WebKitGTK+ Project

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

What’s new in the WebKitGTK+ 2.14.5 release?

  • Fix rendering of non-accelerated contents with HiDPI.
  • Revert the fix for rendering issues in long documents with transparent background because it caused issues in HiDPI.

Thanks to all the contributors who made possible this release.

February 15, 2017 12:00 AM



February 10, 2017

Accelerated compositing in WebKitGTK+ 2.14.4

by Carlos García Campos

WebKitGTK+ 2.14 release was very exciting for us, it finally introduced the threaded compositor to drastically improve the accelerated compositing performance. However, the threaded compositor imposed the accelerated compositing to be always enabled, even for non-accelerated contents. Unfortunately, this caused different kind of problems to several people, and proved that we are not ready to render everything with OpenGL yet. The most relevant problems reported were:

  • Memory usage increase: OpenGL contexts use a lot of memory, and we have the compositor in the web process, so we have at least one OpenGL context in every web process. The threaded compositor uses the coordinated graphics model, that also requires more memory than the simple mode we previously use. People who use a lot of tabs in epiphany quickly noticed that the amount of memory required was a lot more.
  • Startup and resize slowness: The threaded compositor makes everything smooth and performs quite well, except at startup or when the view is resized. At startup we need to create the OpenGL context, which is also quite slow by itself, but also need to create the compositing thread, so things are expected to be slower. Resizing the viewport is the only threaded compositor task that needs to be done synchronously, to ensure that everything is in sync, the web view in the UI process, the OpenGL viewport and the backing store surface. This means we need to wait until the threaded compositor has updated to the new size.
  • Rendering issues: some people reported rendering artifacts or even nothing rendered at all. In most of the cases they were not issues in WebKit itself, but in the graphic driver or library. It’s quite diffilcult for a general purpose web engine to support and deal with all possible GPUs, drivers and libraries. Chromium has a huge list of hardware exceptions to disable some OpenGL extensions or even hardware acceleration entirely.

Because of these issues people started to use different workarounds. Some people, and even applications like evolution, started to use WEBKIT_DISABLE_COMPOSITING_MODE environment variable, that was never meant for users, but for developers. Other people just started to build their own WebKitGTK+ with the threaded compositor disabled. We didn’t remove the build option because we anticipated some people using old hardware might have problems. However, it’s a code path that is not tested at all and will be removed for sure for 2.18.

All these issues are not really specific to the threaded compositor, but to the fact that it forced the accelerated compositing mode to be always enabled, using OpenGL unconditionally. It looked like a good idea, entering/leaving accelerated compositing mode was a source of bugs in the past, and all other WebKit ports have accelerated compositing mode forced too. Other ports use UI side compositing though, or target a very specific hardware, so the memory problems and the driver issues are not a problem for them. The imposition to force the accelerated compositing mode came from the switch to using coordinated graphics, because as I said other ports using coordinated graphics have accelerated compositing mode always enabled, so they didn’t care about the case of it being disabled.

There are a lot of long-term things we can to to improve all the issues, like moving the compositor to the UI (or a dedicated GPU) process to have a single GL context, implement tab suspension, etc. but we really wanted to fix or at least improve the situation for 2.14 users. Switching back to use accelerated compositing mode on demand is something that we could do in the stable branch and it would improve the things, at least comparable to what we had before 2.14, but with the threaded compositor. Making it happen was a matter of fixing a lot bugs, and the result is this 2.14.4 release. Of course, this will be the default in 2.16 too, where we have also added API to set a hardware acceleration policy.

We recommend all 2.14 users to upgrade to 2.14.4 and stop using the WEBKIT_DISABLE_COMPOSITING_MODE environment variable or building with the threaded compositor disabled. The new API in 2.16 will allow to set a policy for every web view, so if you still need to disable or force hardware acceleration, please use the API instead of WEBKIT_DISABLE_COMPOSITING_MODE and WEBKIT_FORCE_COMPOSITING_MODE.

We really hope this new release and the upcoming 2.16 will work much better for everybody.

by carlos garcia campos at February 10, 2017 05:18 PM



WebKitGTK+ Security Advisory WSA-2017-0002

by The WebKitGTK+ Project

Several vulnerabilities were discovered in WebKitGTK+.

  • CVE-2017-2350
    • Versions affected: WebKitGTK+ before 2.14.4.
    • Credit to Gareth Heyes of Portswigger Web Security.
    • Impact: Processing maliciously crafted web content may exfiltrate data cross-origin. Description: A prototype access issue was addressed through improved exception handling.
  • CVE-2017-2354
    • Versions affected: WebKitGTK+ before 2.14.4.
    • Credit to Neymar of Tencent’s Xuanwu Lab (tencent.com) working with Trend Micro’s Zero Day Initiative.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed through improved memory handling.
  • CVE-2017-2355
    • Versions affected: WebKitGTK+ before 2.14.4.
    • Credit to Team Pangu and lokihardt at PwnFest 2016.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: A memory initialization issue was addressed through improved memory handling.
  • CVE-2017-2356
    • Versions affected: WebKitGTK+ before 2.14.4.
    • Credit to Team Pangu and lokihardt at PwnFest 2016.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed through improved input validation.
  • CVE-2017-2362
    • Versions affected: WebKitGTK+ before 2.14.4.
    • Credit to Ivan Fratric of Google Project Zero.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed through improved memory handling.
  • CVE-2017-2363
    • Versions affected: WebKitGTK+ before 2.14.4.
    • Credit to lokihardt of Google Project Zero.
    • Impact: Processing maliciously crafted web content may exfiltrate data cross-origin. Description: Multiple validation issues existed in the handling of page loading. This issue was addressed through improved logic.
  • CVE-2017-2364
    • Versions affected: WebKitGTK+ before 2.14.4.
    • Credit to lokihardt of Google Project Zero.
    • Impact: Processing maliciously crafted web content may exfiltrate data cross-origin. Description: Multiple validation issues existed in the handling of page loading. This issue was addressed through improved logic.
  • CVE-2017-2365
    • Versions affected: WebKitGTK+ before 2.14.4.
    • Credit to lokihardt of Google Project Zero.
    • Impact: Processing maliciously crafted web content may exfiltrate data cross-origin. Description: A validation issue existed in variable handling. This issue was addressed through improved validation.
  • CVE-2017-2366
    • Versions affected: WebKitGTK+ before 2.14.4.
    • Credit to Kai Kang of Tencent’s Xuanwu Lab (tencent.com).
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed through improved input validation.
  • CVE-2017-2369
    • Versions affected: WebKitGTK+ before 2.14.4.
    • Credit to Ivan Fratric of Google Project Zero.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed through improved input validation.
  • CVE-2017-2371
    • Versions affected: WebKitGTK+ before 2.14.4.
    • Credit to lokihardt of Google Project Zero.
    • Impact: A malicious website can open popups. Description: An issue existed in the handling of blocking popups. This was addressed through improved input validation.
  • CVE-2017-2373
    • Versions affected: WebKitGTK+ before 2.14.4.
    • Credit to Ivan Fratric of Google Project Zero.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed through improved memory handling.

We recommend updating to the last stable version of WebKitGTK+. It is the best way of ensuring that you are running a safe version of WebKitGTK+. Please check our website for information about the last stable releases.

Further information about WebKitGTK+ Security Advisories can be found at: https://webkitgtk.org/security.html

February 10, 2017 12:00 AM



WebKitGTK+ 2.14.4 released!

by The WebKitGTK+ Project

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

What’s new in the WebKitGTK+ 2.14.4 release?

  • Make accelerating compositing mode on-demand again. By default it will only be used for websites that require it, saving a lot of memory on websites that don’t need it.
  • Fix rendering issues in long documents with transparent background.
  • Release unused UpdateAtlas and reduce the tile coverage on memory pressure.
  • The media backend now stores preloaded media in /var/tmp instead of user cache dir.
  • Make inspector work again when accelerated compositing support is disabled.
  • Fix a deadlock when the media player is destroyed.
  • Fix network process crashes when loading custom URI schemes.
  • Fix overlay scrollbars that are over a subframe.
  • Fix a crash in GraphicsContext3D::drawArrays when using OpenGL 3.2 core profile.
  • Fix BadDamage X errors happening when resizing the WebView.
  • Fix several crashes and rendering issues.
  • Security fixes: CVE-2017-2365, CVE-2017-2366, CVE-2017-2373, CVE-2017-2363, CVE-2017-2362, CVE-2017-2350, CVE-2017-2350, CVE-2017-2354, CVE-2017-2355, CVE-2017-2356, CVE-2017-2371, CVE-2017-2364, CVE-2017-2369.

Thanks to all the contributors who made possible this release.

February 10, 2017 12:00 AM



February 08, 2017

An Update on WebKit Security Updates

by Michael Catanzaro

One year ago, I wrote a blog post about WebKit security updates that attracted a fair amount of attention at the time. For a full understanding of the situation, you really have to read the whole thing, but the most important point was that, while WebKitGTK+ — one of the two WebKit ports present in Linux distributions — was regularly releasing upstream security updates, most Linux distributions were ignoring the updates, leaving users vulnerable to various security bugs, mainly of the remote code execution variety. At the time of that blog post, only Arch Linux and Fedora were regularly releasing WebKitGTK+ updates, and Fedora had only very recently begun doing so comprehensively.

Progress report!

So how have things changed in the past year? The best way to see this is to look at the versions of WebKitGTK+ in currently-supported distributions. The latest version of WebKitGTK+ is 2.14.3, which fixes 13 known security issues present in 2.14.2. Do users of the most popular Linux operating systems have the fixes?

  • Fedora users are good. Both Fedora 24 and Fedora 25 have the latest version, 2.14.3.
  • If you use Arch, you know you always have the latest stuff.
  • Ubuntu users rejoice: 2.14.3 updates have been released to users of both Ubuntu 16.04 and 16.10. I’m very  pleased that Ubuntu has decided to take my advice and make an exception to its usual stable release update policy to ensure its users have a secure version of WebKit. I can’t give Ubuntu an A grade here because the updates tend to lag behind upstream by several months, but slow updates are much better than no updates, so this is undoubtedly a huge improvement. (Anyway, it’s hardly a bad idea to be cautious when releasing a big update with high regression potential, as is unfortunately the case with even stable WebKit updates.) But if you use the still-supported Ubuntu 14.04 or 12.04, be aware that these versions of Ubuntu cannot ever update WebKit, as it would require a switch to WebKit2, a major API change.
  • Debian does not update WebKit as a matter of policy. The latest release, Debian 8.7, is still shipping WebKitGTK+ 2.6.2. I count 184 known vulnerabilities affecting it, though that’s an overcount as we did not exclude some Mac-specific security issues from the 2015 security advisories. (Shipping ancient WebKit is not just a security problem, but a user experience problem too. Actually attempting to browse the web with WebKitGTK+ 2.6.2 is quite painful due to bugs that were fixed years ago, so please don’t try to pretend it’s “stable.”) Note that a secure version of WebKitGTK+ is available for those in the know via the backports repository, but this does no good for users who trust Debian to provide them with security updates by default without requiring difficult configuration. Debian testing users also currently have the latest 2.14.3, but you will need to switch to Debian unstable to get security updates for the foreseeable future, as testing is about to freeze.
  • For openSUSE users, only Tumbleweed has the latest version of WebKit. The current stable release, Leap 42.2, ships with WebKitGTK+ 2.12.5, which is coincidentally affected by exactly 42 known vulnerabilities. (I swear I am not making this up.) The previous stable release, Leap 42.1, originally released with WebKitGTK+ 2.8.5 and later updated to 2.10.7, but never past that. It is affected by 65 known vulnerabilities. (Note: I have to disclose that I told openSUSE I’d try to help out with that update, but never actually did. Sorry!) openSUSE has it a bit harder than other distros because it has decided to use SUSE Linux Enterprise as the source for its GCC package, meaning it’s stuck on GCC 4.8 for the foreseeable future, while WebKit requires GCC 4.9. Still, this is only a build-time requirement; it’s not as if it would be impossible to build with Clang instead, or a custom version of GCC. I would expect WebKit updates to be provided to both currently-supported Leap releases.
  • Gentoo has the latest version of WebKitGTK+, but only in testing. The latest version marked stable is 2.12.5, so this is a serious problem if you’re following Gentoo’s stable channel.
  • Mageia has been updating WebKit and released a couple security advisories for Mageia 5, but it seems to be stuck on 2.12.4, which is disappointing, especially since 2.12.5 is a fairly small update. The problem here does not seem to be lack of upstream release monitoring, but rather lack of manpower to prepare the updates, which is a typical problem for small distros.
  • The enterprise distros from Red Hat, Oracle, and SUSE do not provide any WebKit security updates. They suffer from the same problem as Ubuntu’s old LTS releases: the WebKit2 API change  makes updating impossible. See my previous blog post if you want to learn more about that. (SUSE actually does have WebKitGTK+ 2.12.5 as well, but… yeah, 42.)

So results are clearly mixed. Some distros are clearly doing well, and others are struggling, and Debian is Debian. Still, the situation on the whole seems to be much better than it was one year ago. Most importantly, Ubuntu’s decision to start updating WebKitGTK+ means the vast majority of Linux users are now receiving updates. Thanks Ubuntu!

To arrive at the above vulnerability totals, I just counted up the CVEs listed in WebKitGTK+ Security Advisories, so please do double-check my counting if you want. The upstream security advisories themselves are worth mentioning, as we have only been releasing these for two years now, and the first year was pretty rough when we lost our original security contact at Apple shortly after releasing the first advisory: you can see there were only two advisories in all of 2015, and the second one was huge as a result of that. But 2016 seems to have gone decently well. WebKitGTK+ has normally been releasing most security fixes even before Apple does, though the actual advisories and a few remaining fixes normally lag behind Apple by roughly a month or so. Big thanks to my colleagues at Igalia who handle this work.

Challenges ahead

There are still some pretty big problems remaining!

First of all, the distributions that still aren’t releasing regular WebKit updates should start doing so.

Next, we have to do something about QtWebKit, the other big WebKit port for Linux, which stopped receiving security updates in 2013 after the Qt developers decided to abandon the project. The good news is that Konstantin Tokarev has been working on a QtWebKit fork based on WebKitGTK+ 2.12, which is almost (but not quite yet) ready for use in distributions. I hope we are able to switch to use his project as the new upstream for QtWebKit in Fedora 26, and I’d encourage other distros to follow along. WebKitGTK+ 2.12 does still suffer from those 42 vulnerabilities, but this will be a big improvement nevertheless and an important stepping stone for a subsequent release based on the latest version of WebKitGTK+. (Yes, QtWebKit will be a downstream of WebKitGTK+. No, it will not use GTK+. It will work out fine!)

It’s also time to get rid of the old WebKitGTK+ 2.4 (“WebKit1”), which all distributions currently parallel-install alongside modern WebKitGTK+ (“WebKit2”). It’s very unfortunate that a large number of applications still depend on WebKitGTK+ 2.4 — I count 41 such packages in Fedora — but this old version of WebKit is affected by over 200 known vulnerabilities and really has to go sooner rather than later. We’ve agreed to remove WebKitGTK+ 2.4 and its dependencies from Fedora rawhide right after Fedora 26 is branched next month, so they will no longer be present in Fedora 27 (targeted for release in November). That’s bad for you if you use any of the affected applications, but fortunately most of the remaining unported applications are not very important or well-known; the most notable ones that are unlikely to be ported in time are GnuCash (which won’t make our deadline) and Empathy (which is ported in git master, but is not currently in a  releasable state; help wanted!). I encourage other distributions to follow our lead here in setting a deadline for removal. The alternative is to leave WebKitGTK+ 2.4 around until no more applications are using it. Distros that opt for this approach should be prepared to be stuck with it for the next 10 years or so, as the remaining applications are realistically not likely to be ported so long as zombie WebKitGTK+ 2.4 remains available.

These are surmountable problems, but they require action by downstream distributions. No doubt some distributions will be more successful than others, but hopefully many distributions will be able to fix these problems in 2017. We shall see!

by Michael Catanzaro at February 08, 2017 06:32 AM



On Epiphany Security Updates and Stable Branches

by Michael Catanzaro

One of the advantages of maintaining a web browser based on WebKit, like Epiphany, is that the vast majority of complexity is contained within WebKit. Epiphany itself doesn’t have any code for HTML parsing or rendering, multimedia playback, or JavaScript execution, or anything else that’s actually related to displaying web pages: all of the hard stuff is handled by WebKit. That means almost all of the security problems exist in WebKit’s code and not Epiphany’s code. While WebKit has been affected by over 200 CVEs in the past two years, and those issues do affect Epiphany, I believe nobody has reported a security issue in Epiphany’s code during that time. I’m sure a large part of that is simply because only the bad guys are looking, but the attack surface really is much, much smaller than that of WebKit. To my knowledge, the last time we fixed a security issue that affected a stable version of Epiphany was 2014.

Well that streak has unfortunately ended; you need to make sure to update to Epiphany 3.22.6, 3.20.7, or 3.18.11 as soon as possible (or Epiphany 3.23.5 if you’re testing our unstable series). If your distribution is not already preparing an update, insist that it do so. I’m not planning to discuss the embarrassing issue here — you can check the bug report if you’re interested — but rather on why I made new releases on three different branches. That’s quite unlike how we handle WebKitGTK+ updates! Distributions must always update to the very latest version of WebKitGTK+, as it is not practical to backport dozens of WebKit security fixes to older versions of WebKit. This is rarely a problem, because WebKitGTK+ has a strict policy to dictate when it’s acceptable to require new versions of runtime dependencies, designed to ensure roughly three years of WebKit updates without the need to upgrade any of its dependencies. But new major versions of Epiphany are usually incompatible with older releases of system libraries like GTK+, so it’s not practical or expected for distributions to update to new major versions.

My current working policy is to support three stable branches at once: the latest stable release (currently Epiphany 3.22), the previous stable release (currently Epiphany 3.20), and an LTS branch defined by whatever’s currently in Ubuntu LTS and elementary OS (currently Epiphany 3.18). It was nice of elementary OS to make Epiphany its default web browser, and I would hardly want to make it difficult for its users to receive updates.

Three branches can be annoying at times, and it’s a lot more than is typical for a GNOME application, but a web browser is not a typical application. For better or for worse, the majority of our users are going to be stuck on Epiphany 3.18 for a long time, and it would be a shame to leave them completely without updates. That said, the 3.18 and 3.20 branches are very stable and only getting bugfixes and occasional releases for the most serious issues. In contrast, I try to backport all significant bugfixes to the 3.22 branch and do a new release every month or thereabouts.

So that’s why I just released another update for Epiphany 3.18, which was originally released in September 2015. Compare this to the long-term support policies of Chrome (which supports only the latest version of the browser, and only for six weeks) or Firefox (which provides nine months of support for an ESR release), and I think we compare quite favorably. (A stable WebKit series like 2.14 is only supported for six months, but that’s comparable to Firefox.) Not bad?

by Michael Catanzaro at February 08, 2017 05:56 AM



January 31, 2017

WebKitGTK+ 2.15.4 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.16 series.

What’s new in the WebKitGTK+ 2.15.4 release?

  • Make accelerating compositing mode on-demand again. By default it will only be used for websites that require it, saving a lot of memory on websites that don’t need it.
  • Add API to manage hardware acceleration policy.
  • Enable CSS Grid Layout by default.
  • Add API to create ephemeral WebViews to replace the legacy private browsing setting that is now deprecated.
  • Handle HTTP authentication for downloads having a WebView associated.
  • Add API to WebKitWebsiteDataManager to handle websites data.
  • Fix BadDamage X errors happening when resizing the WebView.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

January 31, 2017 12:00 AM



January 20, 2017

WebKitGTK+ 2.15.3 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.16 series.

What’s new in the WebKitGTK+ 2.15.3 release?

  • Add API to set network proxy settings.
  • Add API to set initial notification permissions.
  • Add WebKitSecurityOrigin to the API.
  • Add tag property to WebKitNotification.
  • Create GLX OpenGL contexts using version 3.2 (core profile) when available to reduce the memory consumption on Mesa based drivers.
  • Improve memory pressure handler to reduce the CPU usage on memory pressure situations.
  • Add support for key and code properties on keyboard events.
  • More user agent string improvements to improve compatibility with several websites.
  • Fix network process crashes when loading custom URI schemes.
  • Fix web process crash when closing the web view in X11.
  • Fix several crashes and rendering issues.
  • Translation updates: German.

Thanks to all the contributors who made possible this release.

January 20, 2017 12:00 AM



January 17, 2017

WebKitGTK+ Security Advisory WSA-2017-0001

by The WebKitGTK+ Project

Several vulnerabilities were discovered in WebKitGTK+.

  • CVE-2016-4692
    • Versions affected: WebKitGTK+ before 2.14.1.
    • Credit to Apple.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed through improved memory handling.
  • CVE-2016-4743
    • Versions affected: WebKitGTK+ before 2.14.0.
    • Credit to Alan Cutter.
    • Impact: Processing maliciously crafted web content may result in the disclosure of process memory. Description: A memory corruption issue was addressed through improved input validation.
  • CVE-2016-7586
    • Versions affected: WebKitGTK+ before 2.14.3.
    • Credit to Boris Zbarsky.
    • Impact: Processing maliciously crafted web content may result in the disclosure of user information. Description: A validation issue was addressed through improved state management.
  • CVE-2016-7587
    • Versions affected: WebKitGTK+ before 2.14.0.
    • Credit to Adam Klein.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed through improved state management.
  • CVE-2016-7589
    • Versions affected: WebKitGTK+ before 2.14.3.
    • Credit to Apple.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: A memory corruption issue was addressed through improved state management.
  • CVE-2016-7592
    • Versions affected: WebKitGTK+ before 2.14.3.
    • Credit to xisigr of Tencent’s Xuanwu Lab (tencent.com).
    • Impact: Processing maliciously crafted web content may compromise user information. Description: An issue existed in handling of JavaScript prompts. This was addressed through improved state management.
  • CVE-2016-7598
    • Versions affected: WebKitGTK+ before 2.14.0.
    • Credit to Samuel Groß.
    • Impact: Processing maliciously crafted web content may result in the disclosure of process memory. Description: An uninitialized memory access issue was addressed through improved memory initialization.
  • CVE-2016-7599
    • Versions affected: WebKitGTK+ before 2.14.3.
    • Credit to Muneaki Nishimura (nishimunea) of Recruit Technologies Co., Ltd.
    • Impact: Processing maliciously crafted web content may result in the disclosure of user information. Description: An issue existed in the handling of HTTP redirects. This issue was addressed through improved cross origin validation.
  • CVE-2016-7610
    • Versions affected: WebKitGTK+ before 2.14.1.
    • Credit to Zheng Huang of the Baidu Security Lab working with Trend Micro’s Zero Day Initiative.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed through improved state management.
  • CVE-2016-7611
    • Versions affected: WebKitGTK+ before 2.14.2.
    • Credit to an anonymous researcher working with Trend Micro’s Zero Day Initiative.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed through improved state management.
  • CVE-2016-7623
    • Versions affected: WebKitGTK+ before 2.14.3.
    • Credit to xisigr of Tencent’s Xuanwu Lab (tencent.com).
    • Impact: Visiting a maliciously crafted website may compromise user information. Description: An issue existed in the handling of blob URLs. This issue was addressed through improved URL handling.
  • CVE-2016-7632
    • Versions affected: WebKitGTK+ before 2.14.3.
    • Credit to Jeonghoon Shin.
    • Impact: Visiting a maliciously crafted webpage may lead to an unexpected application termination or arbitrary code execution. Description: A memory corruption issue was addressed through improved state management.
  • CVE-2016-7635
    • Versions affected: WebKitGTK+ before 2.14.3.
    • Credit to Apple.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed through improved memory handling.
  • CVE-2016-7639
    • Versions affected: WebKitGTK+ before 2.14.3.
    • Credit to Tongbo Luo of Palo Alto Networks.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed through improved state management.
  • CVE-2016-7640
    • Versions affected: WebKitGTK+ before 2.14.2.
    • Credit to Kai Kang of Tencent’s Xuanwu Lab (tencent.com).
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed through improved state management.
  • CVE-2016-7641
    • Versions affected: WebKitGTK+ before 2.14.3.
    • Credit to Kai Kang of Tencent’s Xuanwu Lab (tencent.com).
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed through improved state management.
  • CVE-2016-7642
    • Versions affected: WebKitGTK+ before 2.14.2.
    • Credit to Tongbo Luo of Palo Alto Networks.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed through improved state management.
  • CVE-2016-7645
    • Versions affected: WebKitGTK+ before 2.14.3.
    • Credit to Kai Kang of Tencent’s Xuanwu Lab (tencent.com).
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed through improved state management.
  • CVE-2016-7646
    • Versions affected: WebKitGTK+ before 2.14.2.
    • Credit to Kai Kang of Tencent’s Xuanwu Lab (tencent.com).
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed through improved state management.
  • CVE-2016-7648
    • Versions affected: WebKitGTK+ before 2.14.2.
    • Credit to Kai Kang of Tencent’s Xuanwu Lab (tencent.com).
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed through improved state management.
  • CVE-2016-7649
    • Versions affected: WebKitGTK+ before 2.14.2.
    • Credit to Kai Kang of Tencent’s Xuanwu Lab (tencent.com).
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed through improved state management.
  • CVE-2016-7652
    • Versions affected: WebKitGTK+ before 2.14.3.
    • Credit to Apple.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed through improved memory handling.
  • CVE-2016-7654
    • Versions affected: WebKitGTK+ before 2.14.3.
    • Credit to Keen Lab working with Trend Micro’s Zero Day Initiative.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed through improved state management.
  • CVE-2016-7656
    • Versions affected: WebKitGTK+ before 2.14.3.
    • Credit to Keen Lab working with Trend Micro’s Zero Day Initiative.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: A memory corruption issue was addressed through improved state management.

We recommend updating to the last stable version of WebKitGTK+. It is the best way of ensuring that you are running a safe version of WebKitGTK+. Please check our website for information about the last stable releases.

Further information about WebKitGTK+ Security Advisories can be found at: https://webkitgtk.org/security.html

January 17, 2017 12:00 AM



WebKitGTK+ 2.14.3 released!

by The WebKitGTK+ Project

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

What’s new in the WebKitGTK+ 2.14.3 release?

  • Create GLX OpenGL contexts using version 3.2 (core profile) when available to reduce the memory consumption on Mesa based drivers.
  • Improve memory pressure handler to reduce the CPU usage on memory pressure situations.
  • Fix a regression in WebKitWebView title notify signal emission that caused the signal to be emitted multiple times.
  • Fix high CPU usage in the web process loading hyphenation dictionaries.
  • More user agent string improvements to improve compatibility with several websites.
  • Fix web process crash when closing the web view in X11.
  • Fix the build with OpenGL ES2 enabled.
  • Fix several crashes and rendering issues.
  • Translation updates: German.
  • Security fixes: CVE-2016-7656, CVE-2016-7635, CVE-2016-7654, CVE-2016-7639, CVE-2016-7645, CVE-2016-7652, CVE-2016-7641, CVE-2016-7632, CVE-2016-7599, CVE-2016-7592, CVE-2016-7589, CVE-2016-7623, CVE-2016-7586.

Thanks to all the contributors who made possible this release.

January 17, 2017 12:00 AM



December 15, 2016

Thu 2016/Dec/15

by Claudio Saavedra

Igalia is hiring. We're currently interested in Multimedia and Chromium developers. Check the announcements for details on the positions and our company.

December 15, 2016 05:13 PM



November 21, 2016

A tale of cylinders and shadows

by Gustavo Noronha

Like I wrote before, we at Collabora have been working on improving WebKitGTK+ performance for customer projects, such as Apertis. We took the opportunity brought by recent improvements to WebKitGTK+ and GTK+ itself to make the final leg of drawing contents to screen as efficient as possible. And then we went on investigating why so much CPU was still being used in some of our test cases.

The first weird thing we noticed is performance was actually degraded on Wayland compared to running under X11. After some investigation we found a lot of time was being spent inside GTK+, painting the window’s background.

Here’s the thing: the problem only showed under Wayland because in that case GTK+ is responsible for painting the window decorations, whereas in the X11 case the window manager does it. That means all of that expensive blurring and rendering of shadows fell on GTK+’s lap.

During the web engines hackfest, a couple of months ago, I delved deeper into the problem and noticed, with Carlos Garcia’s help, that it was even worse when HiDPI displays were thrown into the mix. The scaling made things unbearably slower.

You might also be wondering why would painting of window decorations be such a problem, anyway? They should only be repainted when a window changes size or state anyway, which should be pretty rare, right? Right, that is one of the reasons why we had to make it fast, though: the resizing experience was pretty terrible. But we’ll get back to that later.

So I dug into that, made a few tries at understanding the issue and came up with a patch showing how applying the blur was being way too expensive. After a bit of discussion with our own Pekka Paalanen and Benjamin Otte we found the root cause: a fast path was not being hit by pixman due to the difference in scale factors on the shadow mask and the target surface. We made the shadow mask scale the same as the surface’s and voilà, sane performance.

I keep talking about this being a performance problem, but how bad was it? In the following video you can see how huge the impact in performance of this problem was on my very recent laptop with a HiDPI display. The video starts with an Epiphany window running with a patched GTK+ showing a nice demo the WebKit folks cooked for CSS animations and 3D transforms.

After a few seconds I quickly alt-tab to the version running with unpatched GTK+ – I made the window the exact size and position of the other one, so that it is under the same conditions and the difference can be seen more easily. It is massive.

Yes, all of that slow down was caused by repainting window shadows! OK, so that solved the problem for HiDPI displays, made resizing saner, great! But why is GTK+ repainting the window even if only the contents are changing, anyway? Well, that turned out to be an off-by-one bug in the code that checks whether the invalidated area includes part of the window decorations.

If the area being changed spanned the whole window width, say, it would always cause the shadows to be repainted. By fixing that, we now avoid all of the shadow drawing code when we are running full-window animations such as the CSS poster circle or gtk3-demo’s pixbufs demo.

As you can see in the video below, the gtk3-demo running with the patched GTK+ (the one on the right) is using a lot less CPU and has smoother animation than the one running with the unpatched GTK+ (left).

Pretty much all of the overhead caused by window decorations is gone in the patched version. It is still using quite a bit of CPU to animate those pixbufs, though, so some work still remains. Also, the overhead added to integrate cairo and GL rendering in GTK+ is pretty significant in the WebKitGTK+ CSS animation case. Hopefully that’ll get much better from GTK+ 4 onwards.

by kov at November 21, 2016 05:04 PM



WebKitGTK+ 2.15.2 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.16 series.

What’s new in the WebKitGTK+ 2.15.2 release?

  • Add new API to notify about dynamically added forms to Web Extensions.
  • Implement selection interface and states for elements supporting aria-selected and for menu roles.
  • Expose STATE_SINGLE_LINE and STATE_MULTI_LINE for ARIA searchbox role.
  • Enable WebMemorySampler.
  • Downloads started by context menu actions now have a web view associated.
  • Fix a network process crash when main resource load is converted into a download.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

November 21, 2016 12:00 AM



November 10, 2016

Web Engines Hackfest 2016

by Xabier Rodríguez Calvar

From September 26th to 28th we celebrated at the Igalia HQ the 2016 edition of the Web Engines Hackfest. This year we broke all records and got participants from the three main companies behind the three biggest open source web engines, say Mozilla, Google and Apple. Or course, it was not only them, we had some other companies and ourselves. I was active part of the organization and I think we not only did not get any complain but people were comfortable and happy around.

We had several talks (I included the slides and YouTube links):

We had lots and lots of interesting hacking and we also had several breakout sessions:

  • WebKitGTK+ / Epiphany
  • Servo
  • WPE / WebKit for Wayland
  • Layout Models (Grid, Flexbox)
  • WebRTC
  • JavaScript Engines
  • MathML
  • Graphics in WebKit

What I did during the hackfest was working with Enrique and Žan to advance on reviewing our downstream implementation of Media Source Extensions (MSE) in order to land it as soon as possible and I can proudly say that we did already (we didn’t finish at the hackfest but managed to do it after it). We broke the bots and pissed off Michael and Carlos but we managed to deactivate it by default and continue working on it upstream.

So summing up, from my point of view and it is not only because I was part of the organization at Igalia, based also in other people’s opinions, I think the hackfest was a success and I think we will continue as we were or maybe growing a bit (no spoilers!).

Finally I would like to thank our gold sponsors Collabora and Igalia and our silver sponsor Mozilla.

by calvaris at November 10, 2016 08:59 AM



November 04, 2016

WebKitGTK+ Security Advisory WSA-2016-0006

by The WebKitGTK+ Project

Several vulnerabilities were discovered in WebKitGTK+.

  • CVE-2016-4611
    • Versions affected: WebKitGTK+ before 2.12.0.
    • Credit to Apple.
    • WebKit in Apple iOS before 10, Safari before 10, and tvOS before 10 allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site, a different vulnerability than CVE-2016-4730, CVE-2016-4733, CVE-2016-4734, and CVE-2016-4735.
  • CVE-2016-4613
    • Versions affected: WebKitGTK+ before 2.14.0.
    • Credit to Chris Palmer.
    • Impact: Processing maliciously crafted web content may result in the disclosure of user information. Description: An input validation issue was addressed through improved state management.
  • CVE-2016-4657
    • Versions affected: WebKitGTK+ before 2.14.0.
    • Credit to Citizen Lab and Lookout.
    • WebKit in Apple iOS before 9.3.5 allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site.
  • CVE-2016-4666
    • Versions affected: WebKitGTK+ before 2.14.0.
    • Credit to Apple.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed through improved memory handling.
  • CVE-2016-4707
    • Versions affected: WebKitGTK+ before 2.14.0.
    • Credit to Anonymous Researcher.
    • CFNetwork in Apple iOS before 10 and OS X before 10.12 mishandles Local Storage deletion, which allows local users to discover the visited web sites of arbitrary users via unspecified vectors.
  • CVE-2016-4728
    • Versions affected: WebKitGTK+ before 2.14.0.
    • Credit to Daniel Divricean.
    • WebKit in Apple iOS before 10, tvOS before 10, iTunes before 12.5.1 on Windows, and Safari before 10 mishandles error prototypes, which allows remote attackers to execute arbitrary code via a crafted web site.
  • CVE-2016-4729
    • Versions affected: WebKitGTK+ before 2.12.0.
    • Credit to Apple.
    • WebKit in Apple iOS before 10 and Safari before 10 allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site, a different vulnerability than CVE-2016-4731.
  • CVE-2016-4730
    • Versions affected: WebKitGTK+ before 2.12.0.
    • Credit to Apple.
    • WebKit in Apple iOS before 10, Safari before 10, and tvOS before 10 allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site, a different vulnerability than CVE-2016-4611, CVE-2016-4733, CVE-2016-4734, and CVE-2016-4735.
  • CVE-2016-4731
    • Versions affected: WebKitGTK+ before 2.12.0.
    • Credit to Apple.
    • WebKit in Apple iOS before 10 and Safari before 10 allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site, a different vulnerability than CVE-2016-4729.
  • CVE-2016-4733
    • Versions affected: WebKitGTK+ before 2.14.0.
    • Credit to Natalie Silvanovich of Google Project Zero.
    • WebKit in Apple iOS before 10, Safari before 10, and tvOS before 10 allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site, a different vulnerability than CVE-2016-4611, CVE-2016-4730, CVE-2016-4734, and CVE-2016-4735.
  • CVE-2016-4734
    • Versions affected: WebKitGTK+ before 2.14.0.
    • Credit to Natalie Silvanovich of Google Project Zero.
    • WebKit in Apple iOS before 10, Safari before 10, and tvOS before 10 allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site, a different vulnerability than CVE-2016-4611, CVE-2016-4730, CVE-2016-4733, and CVE-2016-4735.
  • CVE-2016-4735
    • Versions affected: WebKitGTK+ before 2.14.0.
    • Credit to André Bargull.
    • WebKit in Apple iOS before 10, Safari before 10, and tvOS before 10 allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site, a different vulnerability than CVE-2016-4611, CVE-2016-4730, CVE-2016-4733, and CVE-2016-4734.
  • CVE-2016-4758
    • Versions affected: WebKitGTK+ before 2.12.1.
    • Credit to Masato Kinugawa of Cure53.
    • WebKit in Apple iOS before 10, iTunes before 12.5.1 on Windows, and Safari before 10 does not properly restrict access to the location variable, which allows remote attackers to obtain sensitive information via a crafted web site.
  • CVE-2016-4759
    • Versions affected: WebKitGTK+ before 2.14.0.
    • Credit to Tongbo Luo of Palo Alto Networks.
    • WebKit in Apple iOS before 10, tvOS before 10, iTunes before 12.5.1 on Windows, and Safari before 10 allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site, a different vulnerability than CVE-2016-4765, CVE-2016-4766, CVE-2016-4767, and CVE-2016-4768.
  • CVE-2016-4760
    • Versions affected: WebKitGTK+ before 2.14.0.
    • Credit to Jordan Milne.
    • WebKit in Apple iOS before 10, iTunes before 12.5.1 on Windows, and Safari before 10 allows remote attackers to conduct DNS rebinding attacks against non-HTTP Safari sessions by leveraging HTTP/0.9 support.
  • CVE-2016-4761
    • Versions affected: WebKitGTK+ before 2.14.0.
    • Credit to Apple.
    • An use-after-free vulnerability allows remote attackers to cause a denial of service or possibly have unspecified other impact via unknown vectors.
  • CVE-2016-4762
    • Versions affected: WebKitGTK+ before 2.14.0.
    • Credit to Zheng Huang of Baidu Security Lab.
    • WebKit in Apple iOS before 10, iTunes before 12.5.1 on Windows, iCloud before 6.0 on Windows, and Safari before 10 allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site.
  • CVE-2016-4764
    • Versions affected: WebKitGTK+ before 2.14.0.
    • Credit to Apple.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed through improved state management.
  • CVE-2016-4765
    • Versions affected: WebKitGTK+ before 2.14.0.
    • Credit to Apple.
    • WebKit in Apple iOS before 10, tvOS before 10, iTunes before 12.5.1 on Windows, and Safari before 10 allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site, a different vulnerability than CVE-2016-4759, CVE-2016-4766, CVE-2016-4767, and CVE-2016-4768.
  • CVE-2016-4766
    • Versions affected: WebKitGTK+ before 2.12.4.
    • Credit to Apple.
    • WebKit in Apple iOS before 10, tvOS before 10, iTunes before 12.5.1 on Windows, and Safari before 10 allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site, a different vulnerability than CVE-2016-4759, CVE-2016-4765, CVE-2016-4767, and CVE-2016-4768.
  • CVE-2016-4767
    • Versions affected: WebKitGTK+ before 2.14.0.
    • Credit to Apple.
    • WebKit in Apple iOS before 10, tvOS before 10, iTunes before 12.5.1 on Windows, and Safari before 10 allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site, a different vulnerability than CVE-2016-4759, CVE-2016-4765, CVE-2016-4766, and CVE-2016-4768.
  • CVE-2016-4768
    • Versions affected: WebKitGTK+ before 2.14.0.
    • Credit to Anonymous working with Trend Micro’s Zero Day Initiative.
    • WebKit in Apple iOS before 10, tvOS before 10, iTunes before 12.5.1 on Windows, and Safari before 10 allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site, a different vulnerability than CVE-2016-4759, CVE-2016-4765, CVE-2016-4766, and CVE-2016-4767.
  • CVE-2016-4769
    • Versions affected: WebKitGTK+ before 2.14.0.
    • Credit to Tongbo Luo of Palo Alto Networks.
    • WebKit in Apple iTunes before 12.5.1 on Windows and Safari before 10 allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted web site.
  • CVE-2016-7578
    • Versions affected: WebKitGTK+ before 2.14.0.
    • Credit to Apple.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed through improved memory handling.

We recommend updating to the last stable version of WebKitGTK+. It is the best way of ensuring that you are running a safe version of WebKitGTK+. Please check our website for information about the last stable releases.

Further information about WebKitGTK+ Security Advisories can be found at: https://webkitgtk.org/security.html

November 04, 2016 12:00 AM



November 03, 2016

WebKitGTK+ 2.14.2 released!

by The WebKitGTK+ Project

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

What’s new in the WebKitGTK+ 2.14.2 release?

  • Expose WebKitDOMHTMLInputElement APIs for form autofill in unstable DOM API.
  • Properly update WebKitWebView and WebKitWebPage URI properties when request is modified by WebKitWebPage:send-request signal.
  • Restore user agent quirk for Yahoo.
  • Dot not leak the default WebKitWebsiteDataManager in WebKitWebContext.
  • Use eglGetPlatformDisplay when available instead of eglGetDisplay.
  • Avoid strstr() when checking (E)GL extensions.
  • Fix several crashes and rendering issues.
  • Fix the build with ENABLE_OPENGL=OFF and allow to build on Wayland without OpenGL again.
  • Translation updates: Hungarian.

Thanks to all the contributors who made possible this release.

November 03, 2016 12:00 AM



October 26, 2016

WebKitGTK+ 2.15.1 released!

by The WebKitGTK+ Project

This is the first development release leading toward 2.16 series.

What’s new in the WebKitGTK+ 2.15.1 release?

  • GObject DOM bindings API marked as unstable has been removed.
  • Expose WebKitDOMHTMLInputElement APIs for form autofill.
  • Properly update WebKitWebView and WebKitWebPage URI properties when request is modified by WebKitWebPage:send-request signal.
  • Switch to use GMenu internally in the context menu implementation.
  • Dot not leak the default WebKitWebsiteDataManager in WebKitWebContext.
  • The network backend now always sniff contents for Downloads.
  • Use eglGetPlatformDisplay when available instead of eglGetDisplay.
  • Avoid strstr() when checking (E)GL extensions.
  • Fix the build with ENABLE_OPENGL=OFF and allow to build on Wayland without OpenGL again.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

October 26, 2016 12:00 AM



October 11, 2016

WebKitGTK+ 2.14.1 released!

by The WebKitGTK+ Project

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

What’s new in the WebKitGTK+ 2.14.1 release?

  • MiniBrowser and jsc binaries are now installed in pkglibexecdir instead of bindir.
  • Improve performance when resizing a window with multiple web views in X11.
  • Check whether GDK can use GL before using gdk_cairo_draw_from_gl() in Wayland.
  • Updated default UserAgent string or better compatibility.
  • Fix a crash on github.com in IntlDateTimeFormat::resolvedOptions when using the C locale.
  • Fix BadDamage X errors when closing the web view in X11.
  • Fix UIProcess crash when using Japanese input method.
  • Fix build with clang due to missing header includes.
  • Fix the build with USE_REDIRECTED_XCOMPOSITE_WINDOW disabled.
  • Fix several crashes and rendering issues.
  • Translation updates: German.

Thanks to all the contributors who made possible this release.

October 11, 2016 12:00 AM



October 09, 2016

Web Engines Hackfest 2016

by Javier Fernández

Last week I attended the Web Engines Hackfest 2016, hosted by Igalia at the HQ premises in A Coruña. For those still unaware, it’s a unconference like event focused on pure hacking and technical discussions about the main Web Engines supporting the Web Platform.

30147116385_9e2737ef4d_o

This year there were a very interesting group of hackers, representing most of the main web engines, like Mozilla’s Gecko and Servo, Google’s Blink, Apple’s WebKit and Igalia’s WebKitGTK+.

Hacking log

This year I was totally focused on hacking Blink web engine to solve some of the most complex issues of the CSS Grid Layout feature. I’d like to start giving thanks to Google to join the hackfest sending Christian Biesinger, specially thanks to him because of the long flight to attend. It was a pleasure to work work with him on-site and have the opportunity to discuss these complex issues face to face.

Day 1

During the weeks previous to the hackfest I’ve been working on fixing the bug 628565, reported several months ago but hitting me quite much recently. It’s a very ugly issue, since it shows an unpredictable behavior of Grid layout logic, so I decided that I might fix it once for all. I managed to provide 2 different approaches, which can be analyzed in the following code review issues: Issue 2361373002 and Issue 2333583002. Basically, the root cause of both issues is the same; grid’s container intrinsic size is not computed correctly when there are grid items with orthogonal flows.

There are 2 fundamental concepts that are key for understanding this problem:

  • Intrinsic size computation must be done before layout.
  • Orthogonal flow boxes need to be laid out in order to compute min-content contribution to their container’s intrinsic width.

So, we had as single bug to fix for solving two different problems: unpredictable grid layout logic and incorrect grid’s intrinsic size computation. The first problem is the one reported in bug 628565. I’ll try to describe it here briefly, but further details can be obtained from the bug report. Let’s consider the following code:

<style>
   body { overflow: hidden; }
</style>
<div style="width: fit-content; display: grid; grid-template-rows: 50px; border: 5px solid; font: 25px/1 Ahem;">
   <div style="writing-mode: vertical-lr; color: magenta; background: cyan;">XX X</div>
</div>

The following pictures illustrate the issue when loading the code above with Google Chrome 55.0.2859.0 (Official Build) dev (64-bit) Revision 3f63c614e8c4501b1bfa3f608e32a9d12618b0a0-refs/heads/master@{#418117} under Linux operating system:

Chrome BEFORE resizing
chrome-before-resizing

Chrome AFTER resizing
chrome-after-resizing

Christian and I analyzed carefully Blink’s layout code and how it deals with orthogonal boxes. It’s worth mentioning that there are important issues with orthogonal flows in almost every web engine, but Blink has made lately some improvements on this regard. See how a very basic example works in Blink, Gecko and WebKit engines:

<div style="float: left; border: 5px solid; font: font: 25px/1 Ahem;"></div>
  <div style="writing-mode: vertical-lr; color: magenta; background: cyan;">XX X</div>
</div>

orthogonal-flow-different-engines

Blink has implemented a kind of pre-layout logic which is executed for any orthogonal flow box even before doing the actual layout, when box’s intrinsic size computation takes place. This solution allows using a more precise info about an orthogonal box’s height when computing its container’s intrinsic width; otherwise zero width would be assumed, as it’s the case of WebKit and Gecko engines. However, this approach leads to an incorrect behavior when using Grid Layout as I’ll explain later.

My first approach to solve these two issues was to update grid container’s intrinsic size after its orthogonal children were laid out. Hence, we could use the actual size of the children to compute their container’s intrinsic size. However, this violates the first rule of the two assertions defined before: no layout should be done for intrinsic size computation.

Layout Breakout Session

During the evening we held the Layout Breakout Session, where we had a nice discussion about the future of Layout in the different web engines. Christian Biesinger, one of the members of the Google’s Blink Layout team, talked about the new LayoutNG project; an experiment to implement a new Layout from scratch, cleaning up quite old code paths and solving some problems that were not possible to address with the current legacy code. This new LayoutNG idea is related to the new Layout API and the Houdini project, a new mechanism for defining new layout models without the requirement of a native support inside the browser. We had also some discussions about the current state of the Flexible Box specification in Blink and how WebKit’s implementation is quite abandoned and unmaintained nowadays.

In addition, we discussed about the current state of CSS Grid Layout implementation in the different engines. The implementation is almost complete in most of the main engines. Thanks to the collaboration between Igalia and Bloomberg we can confirm that WebKit and Blink’s implementations are almost completed. We have been evaluating Mozilla’s Gecko implementation of Grid and we verified it’s in a similar status. We talked about the recent news from TPAC, which Manuel Rego attended, about the CSS Grid Layout specification becoming Candidate Recommendation. Because of all these reasons, we have agreed with Christian that it’d be good to send the Blink intent-to-ship request as soon as possible; in case it’s accepted, it could be enabled by default in the next Chrome release.

Day 2

The day started with a meeting with Christian for evaluating the different approaches we implemented so far. We have discarded the ones requiring updating intrinsic size. We also decided to avoid solving the issue during the pre-layout of orthogonal items. This approach would have been the one with less impact on performance for grid layout and it would also solve the incorrect intrinsic size issue, however it would add penalties for cases not using grid at all.

Finally, Christian and I agreed on solving first the unpredictable behavior of grid layout logic. We would skip the issue of incorrect intrinsic size, overall because we think the Grid Layout specification is contradictory on this regard. For what is worth, I’ve created a new issue for the CSSWG in the W3C’s github. Even though we should wait for the issue to get clarified, we have already some possible approaches for getting what seems a more natural result for grid’s intrinsic size. The following example could help to understand the problem:

intrinsic-sizes-with-orthogonal

Both test cases were loaded using the same Chrome version commented before. They clearly show that neither min-content or max-content sizes are applied correctly to the grid container. The reason of this weird behavior is how content-sized tracks are handled by the Grid Tracks sizing algorithm in case of rendering grid items with orthogonal flow. From the last draft specification:

Then, if the min-content contribution of any grid items have changed based on the row sizes calculated in step 2, steps 1 and 2 are repeated with the new min-content contribution and max-content contribution (once only).

This, with the fact that orthogonal boxes pre-layout is performed before the tracks have been defined, causes that grid’s container intrinsic size is computed incorrectly. This problem is explained in detail in the W3C’s github issue mentioned before. So if anybody is interested on additional details or, even better, willing to participate in the ongoing discussion, just follow the link above.

Day 3

In addition to the orthogonal flow issues, Baseline Alignment was the other hot topic of my work during the hackfest. Baseline Alignment is the only feature still missing to complete the implementation of the CSS Box Alignment specification for Grid Layout. There is a preliminary approach in this code review issue, but it’s still not complete. The problem is that as it’s stated in the Alignment spec, Baseline Alignment may affect grid’s container intrinsic size:

When specified for align-self/justify-self, these values trigger baseline self-alignment, shifting the entire box within its container, which may affect the sizing of its container.

This fact implies that I should integrate Baseline offset computation inside the Grid Tracks sizing algorithm. Christian and I have been analyzing the sizing algorithm and we designed a possible approach, quite similar to what Flexbox implements in its layout logic.

Finally, we met again with Christian to discuss about the Minimum Implied size for Grid issues. Manuel had the chance to discuss it with the Grid spec editors at TPAC, but it seems there are still unresolved issues. There are an ongoing discussion at W3C’s github about this problem, you can get the details in issues 283 and 523. Christian suggested that he could add some feedback to the discussion, so we can clarify it as soon as possible. This is an important issue that may affect browser interoperability.

The hackfest

The Web Engines Hackfest is an event to share experiences between hackers of different web engines and brainstorming about the future of the Web Platform. This year there were hackers representing most of the main web engines, including Google’s Blink, Mozilla’s Gecko and Servo, Apple’s WebKit and Igalia’s WebKitGTK+.

webengines-1

There were scheduled talks from hackers of each engine so everybody could get an idea of their current state and future plans. In addition, some breakout sessions were scheduled during the kick-off session driven by my colleague Martin Robinson. We embraced everybody to propose new breakout sessions on the fly, every time an ongoing discussion needed a deeper debate or analysis.

ctrbqf6wcaatsvk-jpglarge

I could attend most of the talks and breakout sessions, so I’ll give now my impressions about them. All the talks were recorded (will be available soon) and slides are available in the wiki, so I recommend to watch them if you haven’t already.

30112189436_db06b8fd4b_o

The first speaker in the schedule was Jack Moffitt (Mozilla) “Servo: Today & Tomorrow”. He gave a great overview of the progress they made on the new Servo rendering engine, emphasizing the multi-thread support and showing some performance metrics for different engine’s components, CSS parsing, scripting, layout, … He remarked the technical advantages of using Rust on the development of this new engine.

30032830492_aa442a25b0_o

During Day 1 I attended two breakout sessions. The first one about the WebKitGTK+ engine was mainly focused on the recently published roadmap and specially about the new Threaded Compositor enabled by default. There was an interesting discussion about graphics support in WebKitGTK+ between the Collabora developers and Andrey Fedorov (Huawei).

29851562800_e6b17e78bd_o

The other breakout session I could attend during Day 1 was the one about the Servo engine. There was a nice discussion between Mozilla developers and Christian Biesinger about how both engines handle rendering in a different way. Servo hackers explained with more detail Servos’s threading model and its implication for layout.

30112183886_b4d3836246_o

Day 2 started with the awesome talk by Behdad Esfahbod (Google) “HarfBuzz, the First Ten Years”. He gave an overview of the evolution of the HarfBuff library along the last years, including the past experiences in the Web Engines Hackfest and former events under previous name WebKitGTK+ Hackfest. Clearly, rendering fonts is a huge technical challenge. It was also awesome to have Behdad here to work closely with my colleague Fred Wang on the fonts support for MathML.

30112185606_76ecfb49fe_o

I attended the MathML breakout session, where the hot topic was Fred’s prototype implemented for the Blink engine. The result of this experiment was really promising, so we started to discuss its chances of getting back in Chrome, even behind an experimental flag. Both Christian and Behdad expressed doubts about that being possible nowadays. They suggested that it may be feasible to implement it through Houdini and the new Blink’s Layout API. We have confirmed that the refactoring we have done for WebKit applies perfectly in Blink, since both share a substantial portion of the layout codebase. In addition, after our work for removing the Flexbox dependency and further code clean up, we can be confident on the MathML independence in the layout logic. After some discussion, we have agreed on continue our experiments in Blink, independently of its chances to be integrated in Blink in the future, since I don’t think the Houdini approach makes sense for MathML, at least now.

Later on Youenn Fabler (Apple) gave a talk about the Fetch API, “Fetching Bytes and Words on the Web”. He described the implementation of this specification in WebKit and its relation with the Streams API. The development is still ongoing and there are still quite much work to do.

30147118585_6d5aa818fb_o

I missed the talks of Day 3, so hopefully I’ll watch them as soon as the videos are available. It’s specially interesting the talk about WPE (aka WebKit For Wayland) , by my colleague Žan Doberšek. I’ve spent the day trying to get the most of having Christian Biesinger at our premises. As I commented before, we discussed about the Grid Layout’s Implied Minimum Size issue, one of the most complex problems we’ll have to solve in the short term.

by jfernandez at October 09, 2016 01:59 PM



October 05, 2016

Web Engines Hackfest 2016!

by Gustavo Noronha

I had a great time last week and the web engines hackfest! It was the 7th web hackfest hosted by Igalia and the 7th hackfest I attended. I’m almost a local Galician already. Brazilian Portuguese being so close to Galician certainly helps! Collabora co-sponsored the event and it was great that two colleagues of mine managed to join me in attendance.

It had great talks that will eventually end up in videos uploaded to the web site. We were amazed at the progress being made to Servo, including some performance results that blew our minds. We also discussed the next steps for WebKitGTK+, WebKit for Wayland (or WPE), our own Clutter wrapper to WebKitGTK+ which is used for the Apertis project, and much more.

Zan giving his talk on WPE (former WebKitForWayland)
Zan giving his talk on WPE (former WebKitForWayland)

One thing that drew my attention was how many Dell laptops there were. Many collaborans (myself included) and igalians are now using Dells, it seems. Sure, there were thinkpads and macbooks, but there was plenty of inspirons and xpses as well. It’s interesting how the brand make up shifted over the years since 2009, when the hackfest could easily be mistaken with a thinkpad shop.

Back to the actual hackfest: with the recent release of Gnome 3.22 (and Fedora 25 nearing release), my main focus was on dealing with some regressions suffered by users experienced after a change that made putting the final rendering composited by the nested Wayland compositor we have inside WebKitGTK+ to the GTK+ widget so it is shown on the screen.

One of the main problems people reported was applications that use WebKitGTK+ not showing anything where the content was supposed to appear. It turns out the problem was caused by GTK+ not being able to create a GL context. If the system was simply not able to use GL there would be no problem: WebKit would then just disable accelerated compositing and things would work, albeit slower.

The problem was WebKit being able to use an older GL version than the minimum required by GTK+. We fixed it by testing that GTK+ is able to create GL contexts before using the fast path, falling back to the slow glReadPixels codepath if not. This way we keep accelerated compositing working inside WebKit, which gives us nice 3D transforms and less repainting, but take the performance hit in the final “blit”.

Introducing "WebKitClutterGTK+"
Introducing “WebKitClutterGTK+”

Another issue we hit was GTK+ not properly updating its knowledge of the window’s opaque region when painting a frame with GL, which led to some really interesting issues like a shadow appearing when you tried to shrink the window. There was also an issue where the window would not use all of the screen when fullscreen which was likely related. Both were fixed.

André Magalhães also worked on a couple of patches we wrote for customer projects and are now pushing upstream. One enables the use of more than one frontend to connect to a remote web inspector server at once. This can be used to, for instance, show the regular web inspector on a browser window and also use IDE integration for setting breakpoints and so on.

The other patch was cooked by Philip Withnall and helped us deal with some performance bottlenecks we were hitting. It improves the performance of painting scroll bars. WebKitGTK+ does its own painting of scrollbars (we do not use the GTK+ widgets for various reasons). It turns out painting scrollbars can be quite a hit when the page is being scrolled fast, if not done efficiently.

Emanuele Aina had a great time learning more about meson to figure out a build issue we had when a more recent GStreamer was added to our jhbuild environment. He came out of the experience rather sane, which makes me think meson might indeed be much better than autotools.

Igalia 15 years cake
Igalia 15 years cake

It was a great hackfest, great seeing everyone face to face. We were happy to celebrate Igalia’s 15 years with them. Hope to see everyone again next year =)

by kov at October 05, 2016 12:23 PM



October 03, 2016

WebRTC in WebKit/WPE

by Xabier Rodríguez Calvar

For some time I worked at Igalia to enable WebRTC on WebKitForWayland or WPE for the Raspberry Pi 2.

The goal was to have the WebKit WebRTC tests working for a demo. My fellow Igalian Alex was working on the platform itself in WebKit and assisting with some tuning for the Pi on WebKit but the main work needed to be done in OpenWebRTC.

My other fellow Igalian Phil had begun a branch to work on this that was half way with some workarounds. My first task was getting into combat/workaround mode and make OpenWebRTC work with compressed streams from gst-rpicamsrc. OpenWebRTC supported only raw video streams and that Raspberry Pi Cam module GStreamer element provides only H264 encoded ones. I moved some encoders and parsers around, some caps modifications, removed some elements that didn’t work on the Pi and made it work eventually. You can see the result at:

To make this work by yourselves you needed a custom branch of Buildroot where you could build with the proper plugins enabled also selected the appropriate branches in WPE and OpenWebRTC.

Unfortunately the work was far from being finished so I continued the effort to try to make the arch changes in OpenWebRTC have production quality and that meant do some tasks step by step:

  • Rework the video orientation code: The workaround deactivated it as so far it was being done in GStreamer. In the case of rpicamsrc that can be done by the hardware itself so I cooked a GStreamer interface to enable rotation the same way it was done for the [gl]videoflip elements. The idea would be deprecate the original ones and use the new interface. These landed both in videoflip and glvideoflip. Of course I also implemented it on gst-rpicamsrc here and here and eventually in OpenWebRTC sources.
  • Rework video flip: Once OpenWebRTC sources got orientation support, I could rework the flip both for local and remote feeds.
  • Add gl{down|up}load elements back: There were some issues with the gl elements to upload and download textures, which we had removed. I readded them again.
  • Reworked bins linking: In OpenWebRTC there are some bins that are created to perform some tasks and depending on different circumstances you add or not some elements. I reworked the way those elements are linked so that we don’t have to take into account all the use cases to link them. Now this is easier as the elements are linked as they are the added to the bin.
  • Reworked the renderer_disabled: As in the case for orientation, some elements such as gst-rpicamsrc are able to change color and balance so I added support for that to avoid having that done by GStreamer elements if not necessary. In this case the proper interfaces were already there in GStreamer.
  • Moved the decoding/parsing from the source to the renderer: Before our changes the source was parsing/decoding the remote feeds, local sources were not decoded, just raw was supported. Our workarounds made the local sources decode too but this was not working for all cases. So why decoding at the sources when GStreamer has caps and you can just chain all that to the renderers? So I did eventually, I moved the parsing/decoding to the renderers. This took fixing all the caps negotiation from sources to renderers. Unfortunatelly I think I broke audio on the way, but surely nothing difficult to fix.

This is still a work in progress and now I am changing tasks and handing this over back to my fellow Igalians Phil, who I am sure will do an awesome job together with Alex.

And again, thanks to Igalia for letting me work on this and to Metrological that is sponsoring this work.

by calvaris at October 03, 2016 04:15 PM



September 30, 2016

Cross-compiling WebKit2GTK+ for ARM

by Mario Sánchez Prada

I haven’t blogged in a while -mostly due to lack of time, as usual- but I thought I’d write something today to let the world know about one of the things I’ve worked on a bit during this week, while remotely attending the Web Engines Hackfest from home:

Setting up an environment for cross-compiling WebKit2GTK+ for ARM

I know this is not new, nor ground-breaking news, but the truth is that I could not find any up-to-date documentation on the topic in a any public forum (the only one I found was this pretty old post from the time WebKitGTK+ used autotools), so I thought I would devote some time to it now, so that I could save more in the future.

Of course, I know for a fact that many people use local recipes to cross-compile WebKit2GTK+ for ARM (or simply build in the target machine, which usually takes a looong time), but those are usually ad-hoc things and hard to reproduce environments locally (or at least hard for me) and, even worse, often bound to downstream projects, so I thought it would be nice to try to have something tested with upstream WebKit2GTK+ and publish it on trac.webkit.org,

So I spent some time working on this with the idea of producing some step-by-step instructions including how to create a reproducible environment from scratch and, after some inefficient flirting with a VM-based approach (which turned out to be insanely slow), I finally settled on creating a chroot + provisioning it with a simple bootstrap script + using a simple CMake Toolchain file, and that worked quite well for me.

In my fast desktop machine I can now get a full build of WebKit2GTK+ 2.14 (or trunk) in less than 1 hour, which is pretty much a productivity bump if you compare it to the approximately 18h that takes if I build it natively in the target ARM device I have 🙂

Of course, I’ve referenced this documentation in trac.webkit.org, but if you want to skip that and go directly to it, I’m hosting it in a git repository here: github.com/mariospr/webkit2gtk-ARM.

Note that I’m not a CMake expert (nor even close) so the toolchain file is far from perfect, but it definitely does the job with both the 2.12.x and 2.14.x releases as well as with the trunk, so hopefully it will be useful as well for someone else out there.

Last, I want to thanks the organizers of this event for making it possible once again (and congrats to Igalia, which just turned 15 years old!) as well as to my employer for supporting me attending the hackfest, even if I could not make it in person this time.

Endless Logo

by mario at September 30, 2016 07:10 PM



September 26, 2016

Epiphany Icon Refresh

by Michael Catanzaro

We have a nice new app icon for Epiphany 3.24, thanks to Jakub Steiner (Update: and also Lapo Calamandrei):

new-icon
Our new icon. Ignore the version numbers, it’s for 3.24.

Wow pretty!

The old icon was not actually specific to Epiphany, but was taken from the system, so it could be totally different depending on your icon theme. Here’s the icon currently used in GNOME, for comparison:

old-icon
The old icon, for comparison

You can view the new icon it in its full 512×512 glory by navigating to about:web:

big-icon
It’s big (click for full size)

(The old GNOME icon was a mere 256×256.)

Thanks Jakub!

by Michael Catanzaro at September 26, 2016 02:00 PM



September 22, 2016

WebKitGTK+ 2.14 and the Web Engines Hackfest

by Gustavo Noronha

Next week our friends at Igalia will be hosting this year’s Web Engines Hackfest. Collabora will be there! We are gold sponsors, and have three developers attending. It will also be an opportunity to celebrate Igalia’s 15th birthday \o/. Looking forward to meet you there! =)

Carlos Garcia has recently released WebKitGTK+ 2.14, the latest stable release. This is a great release that brings a lot of improvements and works much better on Wayland, which is becoming mature enough to be used by default. In particular, it fixes the clipboard, which was one of the main missing features, thanks to Carlos Garnacho! We have also been able to contribute a bit to this release =)

One of the biggest changes this cycle is the threaded compositor, which was implemented by Igalia’s Gwang Yoon Hwang. This work improves performance by not stalling other web engine features while compositing. Earlier this year we contributed fixes to make the threaded compositor work with the web inspector and fixed elements, helping with the goal of enabling it by default for this release.

Wayland was also lacking an accelerated compositing implementation. There was a patch to add a nested Wayland compositor to the UIProcess, with the WebProcesses connecting to it as Wayland clients to share the final rendering so that it can be shown to screen. It was not ready though and there were questions as to whether that was the way to go and alternative proposals were floating around on how to best implement it.

At last year’s hackfest we had discussions about what the best path for that would be where collaborans Emanuele Aina and Daniel Stone (proxied by Emanuele) contributed quite a bit on figuring out how to implement it in a way that was both efficient and platform agnostic.

We later picked up the old patchset, rebased on the then-current master and made it run efficiently as proof of concept for the Apertis project on an i.MX6 board. This was done using the fancy GL support that landed in GTK+ in the meantime, with some API additions and shortcuts to sidestep performance issues. The work was sponsored by Robert Bosch Car Multimedia.

Igalia managed to improve and land a very well designed patch that implements the nested compositor, though it was still not as efficient as it could be, as it was using glReadPixels to get the final rendering of the page to the GTK+ widget through cairo. I have improved that code by ensuring we do not waste memory when using HiDPI.

As part of our proof of concept investigation, we got this WebGL car visualizer running quite well on our sabrelite imx6 boards. Some of it went into the upstream patches or proposals mentioned below, but we have a bunch of potential improvements still in store that we hope to turn into upstreamable patches and advance during next week’s hackfest.

One of the improvements that already landed was an alternate code path that leverages GTK+’s recent GL super powers to render using gdk_cairo_draw_from_gl(), avoiding the expensive copying of pixels from the GPU to the CPU and making it go faster. That improvement exposed a weird bug in GTK+ that causes a black patch to appear when shrinking the window, which I have a tentative fix for.

We originally proposed to add a new gdk_cairo_draw_from_egl() to use an EGLImage instead of a GL texture or renderbuffer. On our proof of concept we noticed it is even more efficient than the texturing currently used by GTK+, and could give us even better performance for WebKitGTK+. Emanuele Bassi thinks it might be better to add EGLImage as another code branch inside from_gl() though, so we will look into that.

Another very interesting igalian addition to this release is support for the MemoryPressureHandler even on systems with no cgroups set up. The memory pressure handler is a WebKit feature which flushes caches and frees resources that are not being used when the operating system notifies it memory is scarce.

We worked with the Raspberry Pi Foundation to add support for that feature to the Raspberry Pi browser and contributed it upstream back in 2014, when Collabora was trying to squeeze as much as possible from the hardware. We had to add a cgroups setup to wrap Epiphany in, back then, so that it would actually benefit from the feature.

With this improvement, it will benefit even without the custom cgroups setups as well, by having the UIProcess monitor memory usage and notify each WebProcess when memory is tight.

Some of these improvements were achieved by developers getting together at the Web Engines Hackfest last year and laying out the ground work or ideas that ended up in the code base. I look forward to another great few days of hackfest next week! See you there o/

by kov at September 22, 2016 05:03 PM



September 20, 2016

WebKitGTK+ 2.14.0 released!

by The WebKitGTK+ Project

This is the first stable release in the 2.14 series.

Highlights of the WebKitGTK+ 2.14.0 release

  • Threaded compositor is enabled by default in both X11 and Wayland.
  • Accelerated compositing is now supported in Wayland.
  • Clipboard works in Wayland too.
  • Memory pressure handler always works even when cgroups is not present or not configured.
  • The HTTP disk cache implements speculative revalidation of resources.
  • DRI3 is no longer a problem when using the modesetting intel driver.
  • The amount of file descriptors that are kept open has been drastically reduced.

For more details about all the changes included in WebKitGTK+ 2.14 see the NEWS file that is included in the tarball, or see:

http://blogs.igalia.com/carlosgc/2016/09/20/webkitgtk-2-14/

Thanks to all the contributors who made possible this release.

September 20, 2016 12:00 AM



September 19, 2016

Epiphany 3.22 (and a couple new stable releases too!)

by Michael Catanzaro

It’s that time of year again! A new major release of Epiphany is out now, representing another six months of incremental progress. That’s a fancy way of saying that not too much has changed (so how did this blog post get so long?). It’s not for lack of development effort, though. There’s actually lot of action in git master and on sidebranches right now, most of it thanks to my awesome Google Summer of Code students, Gabriel Ivascu and Iulian Radu. However, I decided that most of the exciting changes we’re working on would be deferred to Epiphany 3.24, to give them more time to mature and to ensure quality. And since this is a blog post about Epiphany 3.22, that means you’ll have to wait until next time if you want details about the return of the traditional address bar, the brand-new user interface for bookmarks, the new support for syncing data between Epiphany browsers on different computers with Firefox Sync, or Prism source code view, all features that are brewing for 3.24. This blog also does not cover the cool new stuff in WebKitGTK+ 2.14, like new support for copy/paste and accelerated compositing in Wayland.

New stuff

So, what’s new in 3.22?

  • A new Paste and Go context menu option in the address bar, implemented by Iulian. It’s so simple, but it’s also the greatest thing ever. Why did nobody implement this earlier?
  • A new Duplicate Tab context menu option on tabs, implemented by Gabriel. It’s not something I use myself, but it seems some folks who use it in other browsers were disappointed it was missing in Epiphany.
  • A new keyboard shortcuts dialog is available in the app menu, implemented by Gabriel.

Gabriel also redesigned all the error pages. My favorite one is the new TLS error page, based on a mockup from Jakub Steiner:

Web app improvements

Pivoting to web apps, Daniel Aleksandersen turned his attention to the algorithm we use to pick a desktop icon for newly-created web apps. It was, to say the least, subpar; in Epiphany 3.20, it normally always fell back to using the website’s 16×16 favicon, which doesn’t look so great in a desktop environment where all app icons are expected to be at least 256×256. Epiphany 3.22 will try to pick better icons when websites make it possible. Read more on Daniel’s blog, which goes into detail on how to pick good web app icons.

Also new is support for system-installed web apps. Previously, Epiphany could only handle web apps installed in home directories, which meant it was impossible to package a web app in an RPM or Debian package. That limitation has now been removed. (Update: I had forgotten that limitation was actually removed for GNOME 3.20, but the web apps only worked when running in GNOME and not in other desktops, so it wasn’t really usable. That’s fixed now in 3.22.) This was needed to support packaging Fedora Developer Portal, but of course it can be used to package up any website. It’s probably only interesting to distributions that ship Epiphany by default, though. (Epiphany is installed by default in Fedora Workstation as it’s needed by GNOME Software to run web apps, it’s just hidden from the shell overview unless you “install” it.) At least one media outlet has amusingly reported this as Epiphany attempting to compete generally with Electron, something I did write in a commit message, but which is only true in the specific case where you need to just show a website with absolutely no changes in the GNOME desktop. So if you were expecting to see Visual Studio running in Epiphany: haha, no.

Shortcut woes

On another note, I’m pleased to announce that we managed to accidentally stomp on both shortcuts for opening the GTK+ inspector this cycle, by mapping Duplicate Tab to Ctrl+Shift+D, and by adding a new Ctrl+Shift+I shortcut to open the WebKit web inspector (in addition to F12). Go team! We caught the problem with Ctrl+Shift+D and removed the shortcut in time for the release, so at least you can still use that to open the GTK+ inspector, but I didn’t notice the issue with the web inspector until it was too late, and Ctrl+Shift+I will no longer work as expected in GTK+ apps. Suggestions welcome for whether we should leave the clashing Ctrl+Shift+I shortcut or get rid of it. I am leaning towards removing it, because we normally match Epiphany behavior with GTK+, and only match other browsers when it doesn’t conflict with GTK+. That’s called desktop integration, and it’s worked well for us so far. But a case can be made for matching other browsers, too.

Stable releases

On top of Epiphany 3.22, I’ve also rolled new stable releases 3.20.4 and 3.18.8. I don’t normally blog about stable releases since they only include bugfixes and are usually boring, so why are these worth mentioning here? Two reasons. First, one of the fixes in these releases is quite significant: I discovered that a few important features were broken when multiple tabs share the same web process behind the scenes (a somewhat unusual condition): the load anyway button on the unacceptable TLS certificate error page, password storage with GNOME keyring, removing pages from the new tab overview, and deleting web applications. It was one subtle bug that was to blame for breaking all of those features in this odd corner case, which finally explains some difficult-to-reproduce complaints we’d been getting, so it’s good to put out that bug of the way. Of course, that’s also fixed in Epiphany 3.22, but new stable releases ensure users don’t need a full distribution upgrade to pick up a simple bugfix.

Additionally, the new stable releases are compatible with WebKitGTK+ 2.14 (to be released later this week). The Epiphany 3.20.4 and 3.18.8 releases will intentionally no longer build with older versions of WebKitGTK+, as new WebKitGTK+ releases are important and all distributions must upgrade. But wait, if WebKitGTK+ is kept API and ABI stable in order to encourage distributions to release updates, then why is the new release incompatible with older versions of Epiphany? Well, in addition to stable API, there’s also an unstable DOM API that changes willy-nilly without any soname bumps; we don’t normally notice when it changes, since it’s autogenerated from web IDL files. Sounds terrible, right? In practice, no application has (to my knowledge) ever been affected by an unstable DOM API break before now, but that has changed with WebKitGTK+ 2.14, and an Epiphany update is required. Most applications don’t have to worry about this, though; the unstable API is totally undocumented and not available unless you #define a macro to make it visible, so applications that use it know to expect breakage. But unannounced ABI changes without soname bumps are obviously a big a problem for distributions, which is why we’re fixing this problem once and for all in WebKitGTK+ 2.16. Look out for a future blog post about that, probably from Carlos Garcia.

elementary OS

Lastly, I’m pleased to note that elementary OS Loki is out now. elementary is kinda (totally) competing with us GNOME folks, but it’s cool too, and the default browser has changed from Midori to Epiphany in this release due to unfixed security problems with Midori. They’ve shipped Epiphany 3.18.5, so if there are any elementary fans in the audience, it’s worth asking them to upgrade to 3.18.8. elementary does have some downstream patches to improve desktop integration with their OS — notably, they’ve jumped ahead of us in bringing back the traditional address bar — but desktop integration is kinda the whole point of Epiphany, so I can’t complain. Check it out! (But be sure to complain if they are not releasing WebKit security updates when advised to do so.)

by Michael Catanzaro at September 19, 2016 02:00 PM



September 18, 2016

A WebKit Update for Ubuntu

by Michael Catanzaro

I’m pleased to learn that Ubuntu has just updated WebKitGTK+ from 2.10.9 to 2.12.5 in Ubuntu 16.04. To my knowledge, this is the first time Ubuntu has released a major WebKit update. It includes fixes for 16 security vulnerabilities detailed in WSA-2016-0004 and WSA-2016-0005.

This is really great. Of course, it would have been better if it didn’t take three and a half months to respond to WSA-2016-0004, and the week before WebKitGTK+ 2.12 becomes obsolete was not the greatest timing, but late security updates are much better than no security updates. It remains to be seen if Ubuntu will keep up with WebKit updates in the future, but I think I can tentatively stop complaining about Ubuntu for now. Debian is looking increasingly isolated in not offering WebKit security updates to its users.

Thanks, Ubuntu!

by Michael Catanzaro at September 18, 2016 04:34 AM



September 15, 2016

WebKitGTK+ 2.13.92 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.14 series.

What’s new in the WebKitGTK+ 2.13.92 release?

  • Add clipboard support in Wayland.
  • Improve rendering of scrollbars with themes setting a minimum width for the scrollbar CSS gadget.
  • Fix another WebProcess crash when the last WebView is destroyed.
  • Fix the build with GCC 6.

Thanks to all the contributors who made possible this release.

September 15, 2016 12:00 AM



September 09, 2016

WebKitGTK+ 2.13.91 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.14 series.

What’s new in the WebKitGTK+ 2.13.91 release?

  • Improve the performance when resizing the WebView with the threaded compositor.
  • Do not try to use GL_PACK_ROW_LENGTH when compiling with GLES2, since it’s not available.
  • Use a different plugins cache file in Wayland and X11.
  • Fix UI process crash visiting sites protected with HTTP auth when using GTK+ < 3.14.
  • Fix a WebProcess crash when the last WebView is destroyed.
  • Fix build configure without Wayland support.
  • Fix the build when compiling with Clang.
  • Fix several crashes and rendering issues.
  • Translation updates: Polish.

Thanks to all the contributors who made possible this release.

September 09, 2016 12:00 AM



September 05, 2016

WebKitGTK+ 2.12.5 released!

by The WebKitGTK+ Project

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

What’s new in the WebKitGTK+ 2.12.5 release?

  • Fix a regression introduced in 2.12.4 that caused a hang in the network process after a load failure.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

September 05, 2016 12:00 AM



August 31, 2016

WebKitGTK+ 2.13.90 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.14 series.

What’s new in the WebKitGTK+ 2.13.90 release?

  • Add initial implementation of accelerating compositing support under Wayland.
  • Fix performance with the modesetting intel driver and DRI3 enabled.
  • Improved performance when resizing the web view on X11.
  • Fix several crashes and rendering issues.
  • Translation updates: German, Polish.

Thanks to all the contributors who made possible this release.

August 31, 2016 12:00 AM



August 25, 2016

WebKitGTK+ Security Advisory WSA-2016-0005

by The WebKitGTK+ Project

Several vulnerabilities were discovered in WebKitGTK+.

  • CVE-2016-4583
    • Versions affected: WebKitGTK+ before 2.12.2.
    • Credit to Roeland Krak.
    • WebKit in Apple iOS before 9.3.3, Safari before 9.1.2, and tvOS before 9.2.2 allows remote attackers to bypass the Same Origin Policy and obtain image date from an unintended web site via a timing attack involving an SVG document.
  • CVE-2016-4585
    • Versions affected: WebKitGTK+ before 2.12.1.
    • Credit to Takeshi Terada of Mitsui Bussan Secure Directions, Inc. (www.mbsd.jp).
    • Cross-site scripting (XSS) vulnerability in the WebKit Page Loading implementation in Apple iOS before 9.3.3, Safari before 9.1.2, and tvOS before 9.2.2 allows remote attackers to inject arbitrary web script or HTML via an HTTP response specifying redirection that is mishandled by Safari.
  • CVE-2016-4586
    • Versions affected: WebKitGTK+ before 2.12.1.
    • Credit to Apple.
    • WebKit in Apple Safari before 9.1.2 and tvOS before 9.2.2 allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site.
  • CVE-2016-4587
    • Versions affected: WebKitGTK+ before 2.10.1.
    • Credit to Apple.
    • WebKit in Apple iOS before 9.3.3 and tvOS before 9.2.2 allows remote attackers to obtain sensitive information from uninitialized process memory via a crafted web site.
  • CVE-2016-4588
    • Versions affected: WebKitGTK+ before 2.12.3.
    • Credit to Apple.
    • WebKit in Apple tvOS before 9.2.2 allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site.
  • CVE-2016-4589
    • Versions affected: WebKitGTK+ before 2.12.3.
    • Credit to Tongbo Luo and Bo Qu of Palo Alto Networks.
    • WebKit in Apple iOS before 9.3.3, Safari before 9.1.2, and tvOS before 9.2.2 allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site, a different vulnerability than CVE-2016-4622, CVE-2016-4623, and CVE-2016-4624.
  • CVE-2016-4590
    • Versions affected: WebKitGTK+ before 2.12.4.
    • Credit to xisigr of Tencent’s Xuanwu Lab (www.tencent.com).
    • WebKit in Apple iOS before 9.3.3 and Safari before 9.1.2 mishandles about: URLs, which allows remote attackers to bypass the Same Origin Policy via a crafted web site.
  • CVE-2016-4591
    • Versions affected: WebKitGTK+ before 2.12.4.
    • Credit to ma.la of LINE Corporation.
    • WebKit in Apple iOS before 9.3.3, Safari before 9.1.2, and tvOS before 9.2.2 mishandles the location variable, which allows remote attackers to access the local filesystem via unspecified vectors.
  • CVE-2016-4592
    • Versions affected: WebKitGTK+ before 2.10.5.
    • Credit to Mikhail.
    • WebKit in Apple iOS before 9.3.3, Safari before 9.1.2, and tvOS before 9.2.2 allows remote attackers to cause a denial of service (memory consumption) via a crafted web site.
  • CVE-2016-4622
    • Versions affected: WebKitGTK+ before 2.12.4.
    • Credit to Samuel Gross working with Trend Micro’s Zero Day Initiative.
    • WebKit in Apple iOS before 9.3.3, Safari before 9.1.2, and tvOS before 9.2.2 allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site, a different vulnerability than CVE-2016-4589, CVE-2016-4623, and CVE-2016-4624.
  • CVE-2016-4623
    • Versions affected: WebKitGTK+ before 2.12.0.
    • Credit to Apple.
    • WebKit in Apple iOS before 9.3.3, Safari before 9.1.2, and tvOS before 9.2.2 allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site, a different vulnerability than CVE-2016-4589, CVE-2016-4622, and CVE-2016-4624.
  • CVE-2016-4624
    • Versions affected: WebKitGTK+ before 2.12.4.
    • Credit to Apple.
    • WebKit in Apple iOS before 9.3.3, Safari before 9.1.2, and tvOS before 9.2.2 allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site, a different vulnerability than CVE-2016-4589, CVE-2016-4622, and CVE-2016-4623.
  • CVE-2016-4651
    • Versions affected: WebKitGTK+ before 2.12.0.
    • Credit to Obscure.
    • Cross-site scripting (XSS) vulnerability in the WebKit JavaScript bindings in Apple iOS before 9.3.3 and Safari before 9.1.2 allows remote attackers to inject arbitrary web script or HTML via a crafted HTTP/0.9 response, related to a “cross-protocol cross-site scripting (XPXSS)” vulnerability.

We recommend updating to the last stable version of WebKitGTK+. It is the best way of ensuring that you are running a safe version of WebKitGTK+. Please check our website for information about the last stable releases.

Further information about WebKitGTK+ Security Advisories can be found at: https://webkitgtk.org/security.html

August 25, 2016 12:00 AM



August 24, 2016

WebKitGTK+ 2.12.4 released!

by The WebKitGTK+ Project

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

What’s new in the WebKitGTK+ 2.12.4 release?

  • Fix performance in accelerated compositing mode with the modesetting intel driver and DRI3 enabled.
  • Reduce the amount of file descriptors that the Web Process keeps open.
  • Fix Web Process deadlocks when loading HLS videos.
  • Make CSS and SVG animations run at 60fps.
  • Make meter elements accessible.
  • Improve accessibility name and description of elements to make it more compatible with W3C specs and fix several bugs in which the accessible name of objects was missing or broken.
  • Fix a crash when running windowed plugins under Wayland.
  • Fix a crash at process exit under Wayland.
  • Fix several crashes and rendering issues.
  • Translation updates: German.
  • Security fixes: CVE-2016-4622, CVE-2016-4624, CVE-2016-4591, CVE-2016-4590.

Thanks to all the contributors who made possible this release.

August 24, 2016 12:00 AM



July 27, 2016

WebKitGTK+ 2.13.4 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.14 series.

What’s new in the WebKitGTK+ 2.13.4 release?

  • Switched to use the threaded compositor. Accelerated compositing mode is now always enabled by default and happens in a separate thread in the web process.
  • Make web view background colors work in accelerated compositing mode.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

July 27, 2016 12:00 AM



July 18, 2016

WebKitGTK+ 2.13.3 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.14 series.

What’s new in the WebKitGTK+ 2.13.3 release?

  • Fix Web Process deadlocks when loading HLS videos.
  • Make videos work when painted into a canvas when accelerated compositing is enabled.
  • Fix flickering with animated GIFs.
  • Fix a Web Process crash when video repaint is requested with GStreamer GL enabled.
  • Reduce the amount of file descriptors that the Web Process keeps open.
  • Make memory pressure handler work when cgroups are not available.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

July 18, 2016 12:00 AM



June 23, 2016

WebKitGTK+ 2.13.2 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.14 series.

What’s new in the WebKitGTK+ 2.13.2 release?

  • Properly redraw the web view when reparented in force compositing mode.
  • Flip the volume control layout in media controls on RTL.
  • Add support for video orientation to the GStreamer media backend.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

June 23, 2016 12:00 AM



May 31, 2016

WebKitGTK+ 2.13.1 released!

by The WebKitGTK+ Project

This is the first development release leading toward 2.14 series.

What’s new in the WebKitGTK+ 2.13.1 release?

  • CSS Grid Layout has been unprefixed and can be enabled as an experimental feature at runtime.
  • The HTTP disk cache implements speculative resources revalidation.
  • Add a new WebKitSetting to allow universal access from file URLs.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

May 31, 2016 12:00 AM



May 30, 2016

WebKitGTK+ Security Advisory WSA-2016-0004

by The WebKitGTK+ Project

Several vulnerabilities were discovered in WebKitGTK+.

  • CVE-2016-1854
    • Versions affected: WebKitGTK+ before 2.12.1.
    • Credit to Anonymous working with Trend Micro’s Zero Day Initiative.
    • WebKit, as used in Apple iOS before 9.3.2, Safari before 9.1.1, and tvOS before 9.2.1, allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site, a different vulnerability than CVE-2016-1855, CVE-2016-1856, and CVE-2016-1857.
  • CVE-2016-1856
    • Versions affected: WebKitGTK+ before 2.12.1.
    • Credit to lokihardt working with Trend Micro’s Zero Day Initiative.
    • WebKit, as used in Apple iOS before 9.3.2, Safari before 9.1.1, and tvOS before 9.2.1, allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site, a different vulnerability than CVE-2016-1854, CVE-2016-1855, and CVE-2016-1857.
  • CVE-2016-1857
    • Versions affected: WebKitGTK+ before 2.12.3.
    • Credit to Jeonghoon Shin@A.D.D and Liang Chen, Zhen Feng, wushi of KeenLab, Tencent working with Trend Micro’s Zero Day Initiative.
    • WebKit, as used in Apple iOS before 9.3.2, Safari before 9.1.1, and tvOS before 9.2.1, allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site, a different vulnerability than CVE-2016-1854, CVE-2016-1855, and CVE-2016-1856.
  • CVE-2016-1858
    • Versions affected: WebKitGTK+ before 2.12.0.
    • Credit to Anonymous.
    • WebKit, as used in Apple iOS before 9.3.2, Safari before 9.1.1, and tvOS before 9.2.1, improperly tracks taint attributes, which allows remote attackers to obtain sensitive information via a crafted web site.
  • CVE-2016-1859
    • Versions affected: WebKitGTK+ before 2.12.1.
    • Credit to Liang Chen, wushi of KeenLab, Tencent working with Trend Micro’s Zero Day Initiative.
    • The WebKit Canvas implementation in Apple iOS before 9.3.2, Safari before 9.1.1, and tvOS before 9.2.1 allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site.

We recommend updating to the last stable version of WebKitGTK+. It is the best way of ensuring that you are running a safe version of WebKitGTK+. Please check our website for information about the last stable releases.

Further information about WebKitGTK+ Security Advisories can be found at: https://webkitgtk.org/security.html

May 30, 2016 12:00 AM



May 24, 2016

WebKitGTK+ 2.12.3 released!

by The WebKitGTK+ Project

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

What’s new in the WebKitGTK+ 2.12.3 release?

  • Improved the detection of supported MIME types supported by the media player.
  • Fix web process crash when playing adaptive streaming media.
  • Change the volume while thumb slider is dragged, not only when released.
  • Fix leaked thread in network process.
  • Fix several crashes and rendering issues.
  • Translation updates: Hungarian.
  • Security fixes: CVE-2016-1857, CVE-2016-1856.

Thanks to all the contributors who made possible this release.

May 24, 2016 12:00 AM



April 28, 2016

WebKitGTK+ 2.12.2 released!

by The WebKitGTK+ Project

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

What’s new in the WebKitGTK+ 2.12.2 release?

  • Fix rendering of scrollbars with GTK themes using stepper buttons.
  • Fix compatibility issue with 2.12.1 regarding local storage access from file URLs.
  • Make menu list buttons use the text color from the theme.
  • Do not show resize grip in non-resizable text fields.
  • Fix accessibility events causing Orca to echo key presses instead of speaking the inserted characters in password fields.
  • Fix an off by one error in hyphenation.
  • Fix several crashes and rendering issues.
  • Fix the build with libjpeg v9.
  • Translation updates: Bulgarian, Finnish, Greek, Italian, Turkish.

Thanks to all the contributors who made possible this release.

April 28, 2016 12:00 AM



April 14, 2016

WebKitGTK+ 2.12.1 released!

by The WebKitGTK+ Project

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

What’s new in the WebKitGTK+ 2.12.1 release?

  • Fix spotify player.
  • Improve themed control elements rendering to better match GTK+ widgets.
  • Make remote web inspector work again.
  • Fix several crashes and rendering issues.
  • Fix several memory leaks.
  • Fix the build in Linux / PowerPC.
  • Fix detection of S390X and PPC64 architectures.
  • Fix the build in glibc-based BSD systems
  • Translation updates: Brazilian Portuguese.

Thanks to all the contributors who made possible this release.

April 14, 2016 12:00 AM



April 10, 2016

WebKitGTK+ 2.4.11 released!

by The WebKitGTK+ Project

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

What’s new in the WebKitGTK+ 2.4.11 release?

  • Fix a crash when changing elment attributes with DOM bindings.
  • Fix the build on ARM64.
  • Translation updates: Chinese, Japanese.

Thanks to all the contributors who made possible this release.

April 10, 2016 12:00 AM



March 31, 2016

Positive progress on WebKitGTK+ security updates

by Michael Catanzaro

I previously reported that, although WebKitGTK+ releases regular upstream security updates, most Linux distributions are not taking the updates. At the time, only Arch Linux and Fedora were reliably releasing our security updates. So I’m quite pleased that openSUSE recently released a WebKitGTK+ security update, and then Mageia did too. Gentoo currently has an update in the works. It remains to be seen if these distros regularly follow up on updates (expect a follow-up post on this in a few months), but, optimistically, you now have several independent distros to choose from to get an updated version WebKitGTK+, plus any distros that regularly receive updates directly from these distros.

Unfortunately, not all is well yet. It’s still not safe to use WebKitGTK+ on the latest releases of Debian or Ubuntu, or on derivatives like Linux Mint, elementary OS, or Raspbian. (Raspbian is notable because it uses an ancient, insecure version of Epiphany as its default web browser, and Raspberry Pis are kind of popular.)

And of course, no distribution has been able to get rid of old, insecure WebKitGTK+ 2.4 compatibility packages, so many applications on distributions that do provide security updates for modern WebKitGTK+ will still be insecure. (Don’t be fooled by the recent WebKitGTK+ 2.4.10 update; it contains only a few security fixes that were easy to backport, and was spurred by the need to add GTK+ 3.20 compatibility. It is still not safe to use.) Nor have distributions managed to remove QtWebKit, which is also old and insecure. You still need to check individual applications to see if they are running safe versions of WebKit.

But at least there are now several distros providing WebKitGTK+ security updates. That’s good.

Special thanks to Apple and to my colleagues at Igalia for their work on the security advisories that motivate these updates.

by Michael Catanzaro at March 31, 2016 03:00 AM



Epiphany 3.20

by Michael Catanzaro

So, what’s new in Epiphany 3.20?

First off: overlay scrollbars. Because web sites have the ability to style their scrollbars (which you’ve probably noticed on Google sites), WebKit embedders cannot use a normal GtkScrolledWindow to display content; instead, WebKit has to paint the scrollbars itself. Hence, when overlay scrollbars appeared in GTK+ 3.16, WebKit applications were left out. Carlos García Campos spent some time to work on this, and the result speaks for itself (if you fullscreen this video to see it properly):

Overlay scrollbars did not actually require any changes in Epiphany itself — all applications using an up-to-date version of WebKit will immediately benefit — but I mention it here as it’s one of the most noticeable changes. Read about other WebKit improvements, like the new Faster Than Light FTL/B3 JavaScript compilation tier, on Carlos’s blog.

Next up, there is a new downloads manager, also by Carlos García Campos. This replaces the old downloads bar that used to appear at the bottom of the screen:

Screenshot of the new downloads manager in Epiphany 3.20.

I flipped the switch in Epiphany to enable WebGL:

If you watched that video in fullscreen, you might have noticed that page is marked as insecure, even though it doesn’t use HTTPS. Like most browsers, we used to have several confusing security states. Pages with mixed content received a security warning that all users ignored, but pages with no security at all received no such warning. That’s pretty dumb, which is why Firefox and Chrome have been talking about changing this for a year or so now. I went ahead and implemented it. We now have exactly two security states: secure and insecure. If your page loads any content not over HTTPS, it will be marked as insecure. The vast majority of pages will be displayed as insecure, but it’s no less than such sites deserve. I’m not concerned at all about “warning fatigue,” because users are not generally expected to take any action on seeing these warnings. In the future, we will take this further, and use the insecure indicator for sites that use SHA-1 certificates.

Moving on. By popular request, I exposed the previously-hidden setting to disable session restore in the preferences dialog, as “Remember previous tabs on startup:”

Screenshot of the preferences dialog, with the new "Remember previous tabs on startup" setting.

Meanwhile, Carlos worked in both WebKit and Epiphany to greatly improve session restoration. Previously, Epiphany would save the URLs of the pages loaded in each tab, and when started it would load each URL in a new tab, but you wouldn’t have any history for those tabs, for example, and the state of the tab would otherwise be lost. Carlos worked on serializing the WebKit session state and exposing it in the WebKitGTK+ API, allowing us to restore full back/forward history for each tab, plus details like your scroll position on each tab. Thanks to Carlos, we also now make use of this functionality when reopening closed tabs, so your reopened tab will have a full back/forward list of history, and also when opening new tabs, so the new tab will inherit the history of the tab it was opened from (a feature that we had in the past, but lost when we switched to WebKit2).

Interestingly, we found the session restoration was at first too good: it would restore the page really exactly as you last viewed it, without refreshing the content at all. This means that if, for example, you were viewing a page in Bugzilla, then when starting the browser, you would miss any new comments from the last time you loaded the page until you refresh the page manually. This is actually the current behavior in Safari; it’s desirable on iOS to make the browser launch instantly, but questionable for desktop Safari. Carlos decided to always refresh the page content when restoring the session for WebKitGTK+.

Last, and perhaps least, there’s a new empty state displayed for new users, developed by Lorenzo Tilve and polished up by me, so that we don’t greet new users with a completely empty overview (where your most-visited sites are normally displayed):

Empty State

That, plus a bundle of the usual bugfixes, significant code cleanups, and internal architectual improvements (e.g. I converted the communication between the UI process and the web process extension to use private D-Bus connections instead of the session bus). The best things have not changed: it still starts up about 5-20 times faster than Firefox in my unscientific testing; I expect you’ll find similar results.

Enjoy!

by Michael Catanzaro at March 31, 2016 01:54 AM



WebKitGTK+ Security Advisory WSA-2016-0003

by The WebKitGTK+ Project

Several vulnerabilities were discovered in WebKitGTK+.

  • CVE-2016-1778
    • Versions affected: WebKitGTK+ before 2.10.5.
    • Credit to 0x1byte working with Trend Micro’s Zero Day Initiative (ZDI).
    • WebKit in Apple iOS before 9.3 and Safari before 9.1 allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site.
  • CVE-2016-1779
    • Versions affected: WebKitGTK+ before 2.10.5.
    • Credit to xisigr of Tencent’s Xuanwu Lab (http://www.tencent.com).
    • WebKit in Apple iOS before 9.3 and Safari before 9.1 allows remote attackers to bypass the Same Origin Policy and obtain physical- location data via a crafted geolocation request.
  • CVE-2016-1781
    • Versions affected: WebKitGTK+ before 2.10.5.
    • Credit to Devdatta Akhawe of Dropbox, Inc.
    • WebKit in Apple iOS before 9.3 and Safari before 9.1 mishandles attachment URLs, which makes it easier for remote web servers to track users via unspecified vectors.
  • CVE-2016-1782
    • Versions affected: WebKitGTK+ before 2.10.5.
    • Credit to Muneaki Nishimura (nishimunea) of Recruit Technologies Co.,Ltd.
    • WebKit in Apple iOS before 9.3 and Safari before 9.1 does not properly restrict redirects that specify a TCP port number, which allows remote attackers to bypass intended port restrictions via a crafted web site.
  • CVE-2016-1783
    • Versions affected: WebKitGTK+ before 2.10.5.
    • Credit to Mihai Parparita of Google.
    • WebKit in Apple iOS before 9.3, Safari before 9.1, and tvOS before 9.2 allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site.
  • CVE-2016-1785
    • Versions affected: WebKitGTK+ before 2.10.5.
    • Credit to an anonymous researcher.
    • The Page Loading implementation in WebKit in Apple iOS before 9.3 and Safari before 9.1 mishandles character encoding during access to cached data, which allows remote attackers to bypass the Same Origin Policy and obtain sensitive information via a crafted web site.
  • CVE-2016-1786
    • Versions affected: WebKitGTK+ before 2.10.5.
    • Credit to ma.la of LINE Corporation.
    • The Page Loading implementation in WebKit in Apple iOS before 9.3 and Safari before 9.1 mishandles HTTP responses with a 3xx (aka redirection) status code, which allows remote attackers to spoof the displayed URL, bypass the Same Origin Policy, and obtain sensitive cached information via a crafted web site.

We recommend updating to the last stable version of WebKitGTK+. It is the best way of ensuring that you are running a safe version of WebKitGTK+. Please check our website for information about the last stable releases.

Further information about WebKitGTK+ Security Advisories can be found at: https://webkitgtk.org/security.html

March 31, 2016 12:00 AM



March 22, 2016

WebKitGTK+ 2.12

by Carlos García Campos

We did it again, the Igalia WebKit team is pleased to announce a new stable release of WebKitGTK+, with a bunch of bugs fixed, some new API bits and many other improvements. I’m going to talk here about some of the most important changes, but as usual you have more information in the NEWS file.

FTL

FTL JIT is a JavaScriptCore optimizing compiler that was developed using LLVM to do low-level optimizations. It’s been used by the Mac port since 2014 but we hadn’t been able to use it because it required some patches for LLVM to work on x86-64 that were not included in any official LLVM release, and there were also some crashes that only happened in Linux. At the beginning of this release cycle we already had LLVM 3.7 with all the required patches and the crashes had been fixed as well, so we finally enabled FTL for the GTK+ port. But in the middle of the release cycle Apple surprised us announcing that they had the new FTL B3 backend ready. B3 replaces LLVM and it’s entirely developed inside WebKit, so it doesn’t require any external dependency. JavaScriptCore developers quickly managed to make B3 work on Linux based ports and we decided to switch to B3 as soon as possible to avoid making a new release with LLVM to remove it in the next one. I’m not going to enter into the technical details of FTL and B3, because they are very well documented and it’s probably too boring for most of the people, the key point is that it improves the overall JavaScript performance in terms of speed.

Persistent GLib main loop sources

Another performance improvement introduced in WebKitGTK+ 2.12 has to do with main loop sources. WebKitGTK+ makes an extensive use the GLib main loop, it has its own RunLoop abstraction on top of GLib main loop that is used by all secondary processes and most of the secondary threads as well, scheduling main loop sources to send tasks between threads. JavaScript timers, animations, multimedia, the garbage collector, and many other features are based on scheduling main loop sources. In most of the cases we are actually scheduling the same callback all the time, but creating and destroying the GSource each time. We realized that creating and destroying main loop sources caused an overhead with an important impact in the performance. In WebKitGTK+ 2.12 all main loop sources were replaced by persistent sources, which are normal GSources that are never destroyed (unless they are not going to be scheduled anymore). We simply use the GSource ready time to make them active/inactive when we want to schedule/stop them.

Overlay scrollbars

GNOME designers have requested us to implement overlay scrollbars since they were introduced in GTK+, because WebKitGTK+ based applications didn’t look consistent with all other GTK+ applications. Since WebKit2, the web view is no longer a GtkScrollable, but it’s scrollable by itself using native scrollbars appearance or the one defined in the CSS. This means we have our own scrollbars implementation that we try to render as close as possible to the native ones, and that’s why it took us so long to find the time to implement overlay scrollbars. But WebKitGTK+ 2.12 finally implements them and are, of course, enabled by default. There’s no API to disable them, but we honor the GTK_OVERLAY_SCROLLING environment variable, so they can be disabled at runtime.

But the appearance was not the only thing that made our scrollbars inconsistent with the rest of the GTK+ applications, we also had a different behavior regarding the actions performed for mouse buttons, and some other bugs that are all fixed in 2.12.

The NetworkProcess is now mandatory

The network process was introduced in WebKitGTK+ since version 2.4 to be able to use multiple web processes. We had two different paths for loading resources depending on the process model being used. When using the shared secondary process model, resources were loaded by the web process directly, while when using the multiple web process model, the web processes sent the requests to the network process for being loaded. The maintenance of this two different paths was not easy, with some bugs happening only when using one model or the other, and also the network process gained features like the disk cache that were not available in the web process. In WebKitGTK+ 2.12 the non network process path has been removed, and the shared single process model has become the multiple web process model with a limit of 1. In practice it means that a single web process is still used, but the network happens in the network process.

NPAPI plugins in Wayland

I read it in many bug reports and mailing lists that NPAPI plugins will not be supported in wayland, so things like http://extensions.gnome.org will not work. That’s not entirely true. NPAPI plugins can be windowed or windowless. Windowed plugins are those that use their own native window for rendering and handling events, implemented in X11 based systems using XEmbed protocol. Since Wayland doesn’t support XEmbed and doesn’t provide an alternative either, it’s true that windowed plugins will not be supported in Wayland. Windowless plugins don’t require any native window, they use the browser window for rendering and events are handled by the browser as well, using X11 drawable and X events in X11 based systems. So, it’s also true that windowless plugins having a UI will not be supported by Wayland either. However, not all windowless plugins have a UI, and there’s nothing X11 specific in the rest of the NPAPI plugins API, so there’s no reason why those can’t work in Wayland. And that’s exactly the case of http://extensions.gnome.org, for example. In WebKitGTK+ 2.12 the X11 implementation of NPAPI plugins has been factored out, leaving the rest of the API implementation common and available to any window system used. That made it possible to support windowless NPAPI plugins with no UI in Wayland, and any other non X11 system, of course.

New API

And as usual we have completed our API with some new additions:

 

by carlos garcia campos at March 22, 2016 10:36 AM



WebKitGTK+ 2.12.0 released!

by The WebKitGTK+ Project

This is the first stable release in the 2.12 series.

Highlights of the WebKitGTK+ 2.12.0 release

  • Enable FTL by default in JavaScriptCore for x86_64.
  • Network process is now used unconditionally. The shared secondary process model is now the same as using the multiple process model and setting a process limit of 1.
  • Switch to use overlay scrollbars like all other GTK+ widgets and ensure the behavior is consistent with GTK+ too.
  • Support for windowless NPAPI plugins with no UI in non X11 platforms.
  • Enable GSS-Negotiate support when available in libsoup.
  • Improved general performance by better handling glib main loop sources.
  • New API to save and restore a WebView session.

For more details about all the changes included in WebKitGTK+ 2.12 see the NEWS file that is included in the tarball, or see:

http://blogs.igalia.com/carlosgc/2016/03/22/webkitgtk-2-12/

Thanks to all the contributors who made possible this release.

March 22, 2016 12:00 AM



March 17, 2016

WebKitGTK+ 2.10.9 released!

by The WebKitGTK+ Project

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

What’s new in the WebKitGTK+ 2.10.9 release?

  • Revert the patch to limit the number of tiles according to the visible area introduced in 2.10.8, because it caused rendering issues in several popular websites.
  • Fix the build with musl libc library.
  • Fix the build with clang-3.8.

Thanks to all the contributors who made possible this release.

March 17, 2016 12:00 AM



March 13, 2016

Do you trust this application?

by Michael Catanzaro

Much of the software you use is riddled with security vulnerabilities. Anyone who reads Matthew Garrett knows that most proprietary software is a lost cause. Some Linux advocates claim that free software is more secure than proprietary software, but it’s an open secret that tons of popular desktop Linux applications have many known, unfixed vulnerabilities. I rarely see anybody discuss this, as if it’s taboo, but it’s been obvious to me for a long time.

Usually vulnerabilities go unreported simply because nobody cares to look. Here’s an easy game: pick any application that makes HTTP connections — anything stuck on an old version of WebKit is a good place to start — and look for the following basic vulnerabilities:

  • Failure to use TLS when required (GNOME Music, GNOME Weather; note these are the only apps I mention here that do not use WebKit). This means the application has no security.
  • Failure to perform TLS certificate verification (Shotwell and Pantheon Photos). This means the application has no security against active attackers.
  • Failure to perform TLS certificate verification on subresources (Midori and XombreroLiferea). As sites usually send JavaScript in subresources, this means active attackers can get total control of the page by changing the script, without being detected (update: provided JavaScript is enabled). (Regrettably, Epiphany prior to 3.14.0 was also affected by this issue.)
  • Failure to perform TLS certificate verification before sending HTTP headers (private Midori bugBanshee). This leaks secure cookies, usually allowing attackers full access to your user account on a website. It also leaks the page you’re visiting, which HTTPS is supposed to keep private. (Update: Regrettably, Epiphany prior to 3.14.0 was affected by this issue. Also, the WebKit 2 API in WebKitGTK+ prior to 2.6.6, CVE-2015-2330.)

Except where noted, the latest release of all of the applications listed above are still vulnerable at the time of this writing, even though almost all of these bugs were reported long ago. With the exception of Shotwell, nobody has fixed any of these issues. Perhaps nobody working on the project cares to fix it, or perhaps nobody working on the project has the time or expertise to fix it, or perhaps nobody is working on the project anymore at all. This is all common in free software.

In the case of Shotwell, the issue has been fixed in git, but it might never be released because nobody works on Shotwell anymore. I informed distributors of the Shotwell vulnerability three months ago via the GNOME distributor list, our official mechanism for communicating with distributions, and advised them to update to a git snapshot. Most distributions ignored it. This is completely typical; to my knowledge, the stable releases of all Linux distributions except Fedora are still vulnerable.

If you want to play the above game, it should be very easy for you to add to my list by checking only popular desktop software. A good place to start would be to check if Liferea or Xombrero (supposedly a security-focused browser) perform TLS certificate verification before sending HTTP headers, or if Banshee performs verification on subresources, on the principle that vulnerable applications probably have other related vulnerabilities. (I did not bother to check.)

On a related note, many applications use insecure dependencies. Tons of popular GTK+ applications are stuck on an old, deprecated version of WebKitGTK+, for example. Many popular KDE applications use QtWebKit, which is old and deprecated. These deprecated versions of WebKit suffer from well over 100 remote code execution vulnerabilities fixed upstream that will probably never be backported. (100 is a lowball estimate; I would be unsurprised if the real number for QtWebKit was much, much higher.)

I do not claim that proprietary software is generally more secure than free software, because that is absolutely not true. Proprietary software vendors, including big name corporations that you might think would know better, are still churning out consumer products based on QtWebKit, for example. (This is unethical, but most proprietary software vendors do not care about security.) Not that it matters too much, as proprietary software vendors rarely provide comprehensive security updates anyway. (If your Android phone still gets updates, guess what: they’re superficial.) A few prominent proprietary software vendors really do care about security and do good work to keep their users safe, but they are rare exceptions, not the rule.

It’s a shame we’re not able to do better with free software.

by Michael Catanzaro at March 13, 2016 01:39 AM



March 12, 2016

Do you trust this website?

by Michael Catanzaro

TLS certificate validation errors are much less common on today’s Internet than they used to be, but you can still expect to run into them from time to time. Thanks to a decade of poor user interface decisions by web browsers (only very recently fixed in major browsers), users do not understand TLS and think it’s OK to bypass certificate warnings if they trust the site in question.

This is completely backwards. You should only bypass the warning if you do not trust the site.

The TLS certificate does not exist to state that the site is somehow trustworthy. It exists only to state that the site is the site you think it is: to ensure there is no man in the middle (MITM) attacker. If you are visiting https://www.example.com and get a certificate validation error, that means that even though your browser is displaying the URL https://www.example.com, there’s zero reason to believe you’re really visiting https://www.example.com rather than an attack site. Your browser can tell the difference, and it’s warning you. (More often, the site is just broken, or “misconfigured” if you want to be generous, but you and your browser have no way to know that.)

If you do not trust the site in question (e.g. you do not have any user account on the site), then there is not actually any harm in bypassing the warning. You don’t trust the site, so you do not care if a MITM is changing the page, recording your passwords, sending fake data to the site in your name, or whatever else.

But if you do trust the site, this error is cause to freak out and not continue, because it gives you have strong reason to believe there is a MITM attacker. Once you click continue, you should assume the MITM has total control over your interaction with the trusted website.

I will pick on Midori for an example of how bad design can confuse users:

The button label reads "Trust this website," but it should read "I do not trust this website."
The button label reads “Trust this website,” but it should read “I do not trust this website.”

As you can see from the label, Midori has this very wrong. Users are misled into continuing if they trust the website: the very situation in which it is unsafe to continue.

Firefox and Chrome handle this much better nowadays, but not perfectly. Firefox says “Your connection is not secure” while Chrome says “Your connection is not private.” It would be better to say: “This doesn’t look like the real www.example.com.”

by Michael Catanzaro at March 12, 2016 10:55 PM



February 26, 2016

Über latest Media Source Extensions improvements in WebKit with GStreamer

by Xabier Rodríguez Calvar

In this post I am going to talk about the implementation of the Media Source Extensions (known as MSE) in the WebKit ports that use GStreamer. These ports are WebKitGTK+, WebKitEFL and WebKitForWayland, though only the latter has the latest work-in-progress implementation. Of course we hope to upstream WebKitForWayland soon and with it, this backend for MSE and the one for EME.

My colleague Enrique at Igalia wrote a post about this about a week ago. I recommend you read it before continuing with mine to understand the general picture and the some of the issues that I managed to fix on that implementation. Come on, go and read it, I’ll wait.

One of the challenges here is something a bit unnatural in the GStreamer world. We have to process the stream information and then make some metadata available to the JavaScript app before playing instead of just pushing everything to a playing pipeline and being happy. For this we created the AppendPipeline, which processes the data and extracts that information and keeps it under control for the playback later.

The idea of the our AppendPipeline is to put a data stream into it and get it processed at the other side. It has an appsrc, a demuxer (qtdemux currently) and an appsink to pick up the processed data. Something tricky of the spec is that when you append data into the SourceBuffer, that operation has to block it and prevent with errors any other append operation while the current is ongoing, and when it finishes, signal it. Our main issue with this is that the the appends can contain any amount of data from headers and buffers to only headers or just partial headers. Basically, the information can be partial.

First I’ll present again Enrique’s AppendPipeline internal state diagram:

First let me explain the easiest case, which is headers and buffers being appended. As soon as the process is triggered, we move from Not started to Ongoing, then as the headers are processed we get the pads at the demuxer and begin to receive buffers, which makes us move to Sampling. Then we have to detect that the operation has ended and move to Last sample and then again to Not started. If we have received only headers we will not move to Sampling cause we will not receive any buffers but we still have to detect this situation and be able to move to Data starve and then again to Not started.

Our first approach was using two different timeouts, one to detect that we should move from Ongoing to Data starve if we did not receive any buffer and another to move from Sampling to Last sample if we stopped receiving buffers. This solution worked but it was a bit racy and we tried to find a less error prone solution.

We tried then to use custom downstream events injected from the source and at the moment they were received at the sink we could move from Sampling to Last sample or if only headers were injected, the pads were created and we could move from Ongoing to Data starve. It took some time and several iterations to fine tune this but we managed to solve almost all cases but one, which was receiving only partial headers and no buffers.

If the demuxer received partial headers and no buffers it stalled and we were not receiving any pads or any event at the output so we could not tell when the append operation had ended. Tim-Philipp gave me the idea of using the need-data signal on the source that would be fired when the demuxer ran out of useful data. I realized then that the events were not needed anymore and that we could handle all with that signal.

The need-signal is fired sometimes when the pipeline is linked and also when the the demuxer finishes processing data, regardless the stream contains partial headers, complete headers or headers and buffers. It works perfectly once we are able to disregard that first signal we receive sometimes. To solve that we just ensure that at least one buffer left the appsrc with a pad probe so if we receive the signal before any buffer was detected at the probe, it shall be disregarded to consider that the append has finished. Otherwise, if we have seen already a buffer at the probe we can consider already than any need-data signal means that the processing has ended and we can tell the JavaScript app that the append process has ended.

Both need-data signal and probe information come in GStreamer internal threads so we could use mutexes to overcome any race conditions. We thought though that deferring the operations to the main thread through the pipeline bus was a better idea that would create less issues with race conditions or deadlocks.

To finish I prefer to give some good news about performance. We use mainly the YouTube conformance tests to ensure our implementation works and I can proudly say that these changes reduced the time of execution in half!

That’s all folks!

by calvaris at February 26, 2016 12:30 PM