Sylvain Galineau | 25 Feb 00:10 2015

WebKit debugging on OSX and ~/.lldbinit

I’ve recently found myself in the following situation while debugging 
WebKit: the debugger (Xcode) would hit a breakpoint, I would place a new 
breakpoint in a method up the current call stack, re-run my test and 
then…nothing. The new breakpoint would never be hit though the original 
one still was and I could still see that method on the call stack with my 
breakpoint in it.

For instance, I would set a breakpoint in FontCascade::width(), see 
RenderSVGText::layout() on the call stack then set a breakpoint in the 
latter. I’d try my test again and never break into 

I verified I was using a debug build, rebuilt from scratch, tried 
command-line LLDB, stood on my head, no luck.

Until I added:

	settings set target.inline-breakpoint-strategy always

in ~/.lldbinit.

I’m glad it works - yay breakpoints - but am not quite sure why this bit 
of magic is needed. Does anyone else use this/know why it helps?  

webkit-dev mailing list
webkit-dev <at>
(Continue reading)

Darin Adler | 24 Feb 18:27 2015

Move WebKit Objective-C code to ARC?

Hi folks.

I believe that WebKit tip of tree on the Cocoa platforms now supports platforms with a new-enough version of
the Objective-C runtime that we could move our Objective-C code to use ARC instead of manual
retain/release. Does anyone know of a reason we couldn’t start making this change to WebKit? I thought
of this when I saw recent patches Joe did to fix retain/release mistakes with RetainPtr on Objective-C
objects. Those mistakes would be nearly impossible if we moved to ARC.

— Darin
webkit-dev mailing list
webkit-dev <at>
Alex Christensen | 23 Feb 23:43 2015


Last week I switched the iOS and Mac builds to use WEBCORE_EXPORT instead of  This should make maintenance easier, but there are a few quirks everybody should be aware of:

1) Do not use WEBCORE_EXPORT before a function defined in a header.  This will cause check-for-weak-vtables-and-externals to fail sometimes.  See for an example fix.
2) If you need to export the vtable of a class, put WEBCORE_EXPORT between “class" and the class name, but not before method and member variable declarations.  Otherwise Visual Studio will not compile successfully after we get rid of  See for an example fix.

webkit-dev mailing list
webkit-dev <at>
Brent Fulgham | 21 Feb 03:02 2015

Windows Bots Are Green!

Hi Everyone,

Over the past few weeks I’ve spent a considerable amount of time reviewing and correcting a number of problems with the Windows testing infrastructure.

We were skipping thousands of tests, including Accessibility, http tests, and large sections of forms, css, and svg tests. Some tests were skipped because features were supposedly incomplete, but in the years since the skip entry was added to the file, the work had been completed and feature worked perfectly well. Some tests were skipped simply because feature flags had never been enabled on Windows.

Happily, all of this is in the past. Now that this work is complete, we have much more test coverage of many areas of WebKit that had been previously ignored on this platform.

1. We are now using native Windows Apache to run our HTTP tests, and have been doing so for the past couple of weeks. This seems to be quite stable, and is allowing us to make sure SSL and other important features work properly on Windows.
2. Accessibility tests are back up and running.
3. Thanks to Ossy, we now run all JSC stress tests on Windows.
4. Nearly all other tests are now running, with a few notable exceptions below.
5. I have switched to running Windows tests in a single process, because I found that running in parallel introduced inconsistent results. (See <>).

So now that I’ve completed this task, PLEASE help keep the Windows bots green! :-)

If you are at all interested in the various Windows ports, and are looking for something to do, there are a number of bugs I’ve filed that could use some attention:

1. For some reason, running layout tests in parallel introduces inconsistent behavior and spurious failures. There must be some kind of cross-talk between the different shards. <>.
2. There are a number of debug assertions firing that cause Debug test runs to exit early. (see <>, 
4. Accessibility tests have a number of problems:
(a) Several Accessibility tests fail in debug mode because they assert that they are accessing text iterators before layout is complete. The comment with this assertion indicates that this can cause crashes and instability. <>
(b) Some accessibility tests are very flaky with regard to digging down into the DOM. Test will pass one run, fail the next. <>

Feel free to contact me any time if you want to tackle any of these problems!

Otherwise, please just help keep the Windows bots green. I don’t want to have to go through all of this again! :-)

Best regards,


webkit-dev mailing list
webkit-dev <at>
Antti Koivisto | 20 Feb 13:11 2015

virtual and override

We have traditionally marked virtual overrides with the 'virtual' keyword for documentation purposes. Nowadays we also have the compiler checked 'override'. Using both at the same time seems redundant.

Should we change the coding style so that exactly one of the 'virtual' and 'override' must be present for all virtual functions?


webkit-dev mailing list
webkit-dev <at>
Filip Pizlo | 31 Jan 21:40 2015

Request for intuition: should switch statements be faster for the default case, or the explicit cases?

I’m having fun calculating the average performance of different switch implementations, to be used in the DFG JIT and in our inline caching logic.  I’ve got two possible implementations that appear to be very nearly optimal assuming the capabilities of the hardware we care about and other constraints of our JITs.  Both implementations involve a tree of branches, and they both come into play in exactly those cases where a tree of branches is already known to be less expensive than a lookup table.

Here’s the basic switch JIT algorithm:

jitSwitchRecurse(cases) {
    if (cases.size < N) {
        for (C in cases)  {
            emit code that checks, and executes, C
        fall through to default
    } else {
        // Note that this only divides-and-conquers and does not explicitly check and execute the median case; I’ve calculated that this is the superior choice.  You can follow along with this here:
        let M = right-median case in cases // for even sizes of cases, pick the greater of the two medians; for odd cases, pick either the median or the value to the right of the median at random.  the point is to split the list into two equal-sized lists
        lessThanJump = emit lessThan comparison against M
        jitSwitchRecurse(those cases that are >= M)
        jitSwitchRecurse(those cases that are < M)

The two implementations of this algorithm that I’m picking between either have N = 2 or N = 3 - i.e. we either stop divide-and-conquering once we have two remaining cases, or when we have 3 remaining cases. Those two versions are the most optimal for a variety of reasons, but neither is obviously better than the other: N = 3 is more optimal for the case that the switch bottoms out in one of the cases.  N = 2 is more optimal if the switch bottoms out in the default (“fall through”) case.  N = 2 is significantly more optimal for default: it usually results in two fewer comparisons before getting to default.  N = 3 is slightly more optimal for the non-default (i.e. hitting some explicit case) case: it usually results in one fewer comparisons before getting to some case.

We could have a switch emitter that selects the strategy based on profiling (did we hit the default case, or not?), but that isn’t always available and it might be overkill.  We could tune this for benchmarks, and I might do some of that.  But I’m curious what other people’s intuitions and experiences are: do your switch statements usually hit some case, or take default?  If you could control which one was faster, which one of those would you be most likely to make faster in the kind of code that you write?


webkit-dev mailing list
webkit-dev <at>
youenn fablet | 31 Jan 20:57 2015

Running W3C tests using wptserve

Hi all,

W3C wptserve server is now used to serve all tests under

Currently, only two tests are run within that folder:
- web-platform-tests/domparsing/DOMParser-parseFromString-html.html
- web-platform-tests/domparsing/insert-adjacent.html

Should there be any issus with those tests, the problem may be related
to running wptserve.
The wptserve server log is dumped in the the layout-test-results folder.
Please let me know if you see any such issue, particularly on WebKit bots.

Next planned steps in that area are:
1. Update Tools/Scripts/import-w3c-tests according this new set-up
2. Migrate already imported W3C WPT tests within
3. Further improve the tools to make import of new tests and re-import
existing tests as easy as possible

Any suggestion welcome.

ankit srivastav | 31 Jan 05:58 2015

Painting /Drawing mechanism in webkit

Hi All,

I'm new to webkit in context of Painting/Drawing.

I'm trying to use my own algo instead of Webkit defaults Bilenear Interpolation algo for interpolation of images on a webpage.
That is if destImage Size is greater then SrcImage Size my algo will also come into picture alongside Webkit Bilinear.

But the problem is my algo take lots of time to do the interpolation, hence the page load becomes slow.
Specially for large images it takes too much time to load the image and hence the webpage.

I have tried to use my algo in PlatformGraphicsContext.cpp along with Bilinear.

If I'm using a separate thread to for my algo.
I'm not getting the exact result i.e. once the images are drawn by Bilinear it is not been drawn after my algo.

It means I need to fire an event after interpolation is done by my algo, so that images will be drawn using the data from my algo.

Please if someone can tell me the Painting/Drawing mechanism of webkit it would be great.

webkit-dev mailing list
webkit-dev <at>
Chris Dumez | 28 Jan 20:30 2015

Pattern for singleton classes instance getters


I noticed that we are currently not very consistent in WebKit in the way we implement singleton classes instance getters.
- Some classes use free functions (like MemoryCache, and PageCache until I updated it yesterday). e.g. memoryCache().xxx()
- Some classes are using static functions in the class (e.g. DatabaseProcess::shared(), PluginProcess::shared()).

As I said, I landed a patch yesterday so that the global page cache is now accessed via PageCache::shared() because I thought this was the currently preferred pattern (given it seems very common in WebKit2 code).
However, I thought I would email webkit-dev to make sure this is actually the case and make sure we agree on a given pattern (one way or another) for current and future code. We could then maybe document this
as part of our coding style.

Any feedback on this matter?

Chris Dumez - Apple Inc.
Cupertino, CA

webkit-dev mailing list
webkit-dev <at>
Myles C. Maxfield | 28 Jan 20:17 2015

Please try out the SVG -> OTF Font converter!


I’ve been working on a cross-platform converter to translate SVG fonts into OpenType fonts, with the
goal of eventually replacing WebKit support of SVG fonts with platform support of OpenType fonts. This
work has reached a point where we have turned it on in the Mac port.

It would be useful for this feature to hear about the level of support that other platforms have of the
generated OpenType files that this converter outputs. Given that this is the direction that we will be
heading in general, now would be an excellent time for all the ports/platforms to turn on the
ENABLE(SVG_OTF_CONVERTER) flag and provide feedback and bug reports!

Myles C. Maxfield
webkit-dev mailing list
webkit-dev <at>
Adam Bergkvist | 28 Jan 11:28 2015

WebRTC in WebKit


Back in 2011-2012 there was some work done to implement WebRTC in WebKit
by Google and Ericsson [1]. At the time, it was only the chromium port
that had a WebRTC backend implemented ( and a fully testable
implementation. As of late 2014, there is an alternative WebRTC
implementation out there; OpenWebRTC [2] is an open source WebRTC
framework based on GStreamer.

This is an announcement that we are a group of people/companies that
intend to continue the work on WebRTC in WebKit.

What we would like to do is to:
* Get the WebCore interfaces up to date. Quite a lot has changed in the
WebRTC API since the code landed in WebCore. For example, the
MediaStreamTrack has taken over most of the responsibilities previously
owned by MediaStream.

* Use OpenWebRTC as a WebRTC backend on the GTK+ port. Our approach
would be to use a stable platform interface on a lower level than the
W3C API (MediaStream API and RTCPeerConnecion) and implement the API
related details in WebCore. This would allow us to let API related 
objects only exist in WebCore and not having to mirror them across layers.

* Evaluate the feasibility of multiple back-end support (e.g. 
& OpenWebRTC).

This effort will involve quite a few people, including Adam Bergkvist
(Ericsson), Alex Gouaillard (Temasys), Philippe Normand (Igalia) and 
Sebastian Dröge (Centricular).

Feedback and/or help is always appreciated.

Adam, Alex, Philippe and Sebastian