Vienneau, Christopher | 20 Nov 07:25 2015

Memory leak tracking in WebKit



I’m currently trying to track a leak in our port of WebKit.  If left to soak in an automated test, looping over 100 websites, visiting each for 10 seconds, for an evening, I’m finding that memory usage goes up to well over a gigabyte (eventually crashing).  I know that a lot of things could remain cached but I’m calling code very similar to MemoryPressureHandler::releaseMemory(Critical::Yes, Synchronous::Yes) before checking the memory counters built into our application.  Manually trying to reproduce the leak, I find that many pages don’t seem to exhibit any identifiable increase in memory when; starting from a simple page, clearing the cache, visiting the test page, returning to the simple page and finally clearing the cache.  I have identified some pages which seem to be causing a problem such as, when visiting this page it appears I can expect to lose 100-500k.


Our current code is based off of 188436:

-Are there any known memory leaks that I should pick up a fix for? (I searched but nothing seemed relevant to the current code I have).

-Are there any tools or techniques that can be recommended for identifying a leak?  I’ve been improving our debug features of our memory system, but I’ve been unable to solidly identify where the memory is going.

-I have the WinCairo sample built at the same revision, are there any memory tools that can be used with it to identify if the leak exists there too?


Thanks for any suggestions


Chris Vienneau

webkit-dev mailing list
webkit-dev <at>
Ryosuke Niwa | 19 Nov 03:35 2015

Prototyping Custom Elements API

Hi all,

I would like to start prototyping custom elements API in WebKit.
Custom elements API allows authors to define a author-defined tag name
associated with its own JS interface.  There is a draft spec proposed
by Google ( but there
has been many open questions regarding the construction timing and

Unfortunately, many of those open questions are hard to answer without
further implementation experience and feedback as well as Web
developer feedback.  As such, I've started prototyping what we've been
discussing at W3C and posted work-in-progress patches on

Since it's troublesome for developers to build trunk WebKit with my
changes, I plan to land my experimental API on trunk WebKit behind a
build flag, enabled it by default for Mac port (as done for shadow DOM

Please let me know if you have any concerns and/or comments.

- R. Niwa
Carlos Alberto Lopez Perez | 18 Nov 13:36 2015

How to deal with 1-pixel differences in reftests ?


Some reference tests give a 1-pixel or very few pixel differences [1].

I'm not sure if this really indicates a problem in the WebKit code, or
it indicates that we are just too strict not allowing even a very small
percentage in pixel differences for this kind of tests.

Should we tolerate a few pixel differences for reftests ?

I have done some tests, and the test in [1] passes for any value of
tolerance >= 0.00001% (with the GTK port).

I'm inclined to allow a very small value, for example a 0.001% (that
would be 100 times stricter than the tolerance value we use for the
other tests)



For example, this is happening in the GTK port:
The diff image normalized (so you can see where is the diff):
Brian Burg | 17 Nov 19:07 2015

OUTAGE: Bugzilla not sending emails properly

Hi all,

We’ve been getting reports that Bugzilla has not sent any mail out in the past 24 hours. :-(
The server admins are investigating what’s up and will send out an email when it’s fixed.

webkit-dev mailing list
webkit-dev <at>
Geoffrey Garen | 13 Nov 02:41 2015

The great commit queue experiment

Hi folks.

A bunch of us at the WebKit Contributors Meeting decided that we will spend the next week landing 100% of our
patches through the commit queue. Please feel free to play along at home.

If we see problems, we’ll document our experiences here:

	This is why I love or hate the commit queue

Hopefully this will help us prioritize improvements in the commit queue, if any are needed.

webkit-dev mailing list
webkit-dev <at>
Xabier Rodríguez Calvar | 12 Nov 20:00 2015

Protect promise capabilities from being vended again


When you create a promise capability, there's nothing preventing you
from calling again  <at> resolve and  <at> reject on the capability to vend the
promise twice. In the case of the Streams implementation to create
capabilities are are already vended, we do it as {  <at> promise:  <at> Promise. <at> 
resolve } or  <at> reject and those capability objects don't have the
 <at> resolve and  <at> reject slots so calling them would obviously fail.

Vending a promise twice means probably an issue in the algorithm that
you are implementing and if it were properly designed that shouldn't
happen. Software and specs can have bugs though and we could end up
hitting those unexpected cases.

For that I think we could change the internal promise capabilities to
use the newly added  <at> assert when they are vended twice and also add two
functions to create those vended capabilities in a single call.

Any comments?


Xabier Rodríguez Calvar
Software Engineer

webkit-dev mailing list
webkit-dev <at>
Yoav Weiss | 11 Nov 15:11 2015

<link rel=preload>


I'm interested in adding support for <link rel=preload> and the corresponding "Link:" headers and wanted to gauge interest for supporting the feature.

The preload relationship provides a declarative fetch primitive that enables developers to initiate a resource fetch and separate fetching from resource execution. As such, preload is a low-level primitive that enables applications to build custom resource loading and execution behaviors without hiding resources from the user agent and incurring delayed resource fetching penalties.

Use cases include:
* Early fetch of lately discovered critical resources - Sites that contain critical resources that aren't discoverable by the preload scanner (e.g. fonts, JS loaded scripts and styles, etc) can use the feature to download these critical resources early
* Separation of download and execution in a declarative, non-hacky way.

All in all, it would enable Web sites to significantly improve loading performance in various common scenarios.


webkit-dev mailing list
webkit-dev <at>
Nikolay Tsenkov | 11 Nov 11:06 2015

OSX: Linking to custom build resorts to system version...


First of all, thanks for the awesome OSS software that WebKit is!

I need some help with linking to a fresh build of WebKit.framework on OS X:
 - I am building a modified version of WebKit.framework (my changes are in WebCore and WebKit projects) on OS X 10.11, but I am not able to use that framework in another project - somehow the project always resorts to the default system WebKit.framework.

 - OS X 10.11.0 (just saw there is 10.11.1 available, but haven’t installed it yet)
 - System Integrity Protection (SIP) disabled (I couldn’t build when ON)

 - (Gist) I am making a version of the WebView (the legacy one, the single-process model) which can be used in DAW plugin, exposing API for rendering the audio, settings the sampling rate, not rendering to the audio hardware directly, etc.
 - (Specific)
 - (WebCore) -Replaced- AudioDestinationMac with AudioDestinationDaw;
 - (WebCore) -Add- DawStateSingleton which exposes the custom destination node to the WebView;
 - (WebKit) -Modify- WebView to include a new constructor and couple of new methods:
- (instancetype)initWithFrame:(NSRect)frame samplingRate:(float)samplingRate frameName:(NSString *)frameName groupName:(NSString *)groupName;
- (void)setDawSamplingRate:(float)samplingRate;
- (void)renderAudio:(int) numberOfFrames bufferList:(AudioBufferList*) bufferList;

In a new project, I am trying to use the new WebView. If I don’t link to WebKit.framework, of course, the build fails because it can’t find the framework. But if I link to the custom build (the WebView header is the new one, I’ve checked) in run time the app breaks with “-[WebView initWithFrame:samplingRate:frameName:groupName:]: unrecognized selector sent to instance” from which I infer it’s using the system version of the WebView.

I’ve tried to inspect how the MiniBrowser project correctly is referring to the new build, but I don’t see how the linking is happening…

Could someone help me out with this?

Please, accept my apologies, if there is something simple that I’ve missed.

Nikolay Tsenkov
webkit-dev mailing list
webkit-dev <at>
Yusuke SUZUKI | 11 Nov 08:04 2015

Thought about Nix JavaScriptCore port

Hello WebKittens,

JavaScriptCore use in non-OSX environment looks emerging[1].
In addition to that, sometimes, people would like to build JavaScriptCore to see what is happning in JavaScriptCore development[2].
However, if you don't have an OSX machine, it is a little bit difficult.
One possible solution is GTK+ port, it is nice way to build JSC in Linux.
But it involves many dependencies (Mesa, glib etc.), that are not necessary for JavaScriptCore and this is a barrier to join JSC development from non OSX world.

While building whole WebKit requires many dependencies, JavaScriptCore does not.
In Nix environment, JavaScriptCore only requires

1. ICU (for WTF unicode libraries and i18n in JSC)
2. LLVM (for FTL!)

That's all. Maintaining the brand new port is tough work.
But maintaining Nix port only for JSC is much much easier since WTF and JSC are well written for Nix.
In fact, I can build JSC in Nix environment with very small effort, essentially just adding CMakeLists.txt. Here is my initial attempt[2].

So, the proposal is, how about adding new port NixJSC?
I think it encourages OSS development for JSC.
Unfortunately I cannot attend Fall WebKit MTG, but this could become a nice topic for the MTG :)

Here is the plan about the NixJSC port.

1. Add new port NixJSC. It provides JavaScriptCore build for Nix environment. Not provide WebCore, WebKit, WebKit2, etc. It will just build WTF, bmalloc, and JSC.
2. This port should be suitable for development. So I think aggressively enabling features is nice for this port; like, enabling FTL!
3. I think this would become a nice playground for OSX guys to enable features in Nix environment. GTK+ and EFL are somewhat production port. But NixJSC is intended to be used for development.

If it is introduced, at least, I can support this port.

webkit-dev mailing list
webkit-dev <at>
Jon Davis | 10 Nov 20:21 2015

Fall WebKit Contributors Meeting

Hi WebKit Contributors!

I have some details for you about the Contributors Meeting starting tomorrow.

We will be starting at 9:30 AM on Wednesday morning to set the agenda. Be sure to add your ideas for discussion
topics at:

When you arrive at 1 Infinite Loop you’ll want to drive around to IL4 and park in the lots in front of the
building. Next head in through the front entrance of IL4. Once inside, take the stairs on the left to the
second floor. Name tags will be available for you there. Find yours and head to conference room Garage I.

Attendees to the meeting There will be a reception after the meeting at BJ’s Brewhouse on Thursday from
6-8 PM. 

If you have any questions, or need help with anything, feel free to reach out to me or ping me on Twitter  <at> jonathandavis.

Thanks for attending being part of the WebKit project. Look forward to seeing all of you tomorrow!

Jon Davis
 Web Technology Evangelist
Attachment (smime.p7s): application/pkcs7-signature, 4814 bytes
webkit-dev mailing list
webkit-dev <at>
Alex Christensen | 9 Nov 20:32 2015


I made new abstractions for loading in WebKit2: NetworkSession and NetworkDataTask.  It is disabled by
default right now, but if you switch USE_NETWORK_SESSION to 1, it mostly works on Mac with features like
authentication challenges not implemented yet.  I believe these new abstractions fit better with
libsoup, but I’d like feedback on what an actual libsoup implementation would need.  I’m planning on
removing the ResourceHandle use in WebKit2 and the async/continue callbacks in ResourceHandleClient
and ResourceHandle once this work is done.


webkit-dev mailing list
webkit-dev <at>