Koen Bok | 24 Nov 21:23 2014

Disable WebKit2 Security

I'm trying to disable some web security for my Mac desktop app. Currently, if I try to load a local json file I get the error:

[Error] XMLHttpRequest cannot load file:///Users/koen/Desktop/test.json. Cross origin requests are only supported for HTTP.

I tried setting the following two configuration options with the C api:
WKPreferencesSetWebSecurityEnabled(prefsRef, false);
WKPreferencesSetFileAccessFromFileURLsAllowed(prefsRef, true);

But none of these seem to do anything.

What am I missing?
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
Baldeva, Arpit | 24 Nov 16:56 2014

asm.js optimization path?



I was wondering if JavaScriptCore community ever considered adding optimization path for asm.js (http://asmjs.org/ ) ? I searched webkit bugzilla and did not find any relevant discussions.


Any opinions in favor/against it?




webkit-dev mailing list
webkit-dev <at> lists.webkit.org
Daniel Lazarenko | 24 Nov 09:29 2014

Re: webkit-dev Digest, Vol 114, Issue 16

> > On Nov 20, 2014, at 9:26 AM, Alexey Proskuryakov <ap <at> webkit.org (mailto:ap <at> webkit.org)> wrote:
> >  
> >  
> > 19 ????. 2014 ?., ? 14:58, Alexey Proskuryakov <ap <at> webkit.org <mailto:ap <at> webkit.org>> ???????(?):
> >  
> > > These and related uses are all over the place - see also Vectors in FormDataBuilder, data returned from
FrameLoader::loadResourceSynchronously, plug-in code that loads from network, SharedBuffer etc.
> >  
> > Another way to say this is: we need to deal with large data arrays throughout loading code. We do not really
need full size vectors in most other code - it's sort of OK for HTML parser or for image decoder to fail
catastrophically when there is too much data fed to it.
> >  
> > This is somewhat questionable design, but if we are going to stick to it, then magnitude checks should be
centralized, not sprinkled throughout the code. We should not make this check explicitly when feeding a
network resource to the parser, for example.
> >  
> > A 64-bit API for Vector solves this nearly flawlessly. We do not perform the checks manually every time we
use a Vector, Vector does them for us.
> >  
> > Other options are:
> >  
> > - uint64_t everywhere. This way, we'll solve practical problems with large resources once and for all.
Also, this may prove to be necessary to solve even YouTube/Google Drive uploads, I do not know that yet.
> >  
> > - size_t everywhere. Same effect on 64-bit platforms, while 32-bit ones will still be limited. I like
this option, because it won't make us pay the memory and performance cost on old crippled 32-bit machines,
which are unlikely to be used for manipulating huge volumes of data anyway.
> We probably want YouTube upload of large files to work on 32-bit machines. Though presumably if you want to
upload a file larger than the virtual address space, you need to represent it in some way other than a Vector.
> - Maciej
+1. As a user I don’t want a large file upload to occupy all my memory. Memory is more useful for something
else. The browser should be smart enough to upload large files part by part from the FS directly.

webkit-dev mailing list
webkit-dev <at> lists.webkit.org
Chris Dumez | 19 Nov 21:20 2014

size_t vs unsigned in WTF::Vector API ?

Hi all,

I recently started updating the WTF::Vector API to use unsigned types instead of size_t [1][2], because:
- WTF::Vector is already using unsigned type for size/capacity internally to save memory on 64-bit, causing a mismatch between the API and the internal representation [3]
- Some reviewers have asked me to use unsigned for loop counters iterating over vectors (which looks unsafe as the Vector API, e.g. size(), returns a size_t).
- I heard from Joseph that this type mismatch is forcing us (and other projects using WTF) to disable some build time warnings
- The few people I talked to before making that change said we should do it

However, Alexey recently raised concerns about this change. it doesn't "strike him as the right direction. 4Gb is not much, and we should have more of WebKit work with the right data types, not less.”.
I did not initially realize that this change was controversial, but now that it seems it is, I thought I would raise the question on webkit-dev to see what people think about this.


webkit-dev mailing list
webkit-dev <at> lists.webkit.org
Osztrogonác Csaba | 17 Nov 17:16 2014

Status of WinCairo buildbot?


it seems the WinCairo buildbot is offline since a months:

And it had been continuosly red before it went offline,
at least since 1st October.

Is there anybody maintains / interested in maintaining this bot?
If no, I propose removing it from https://build.webkit.org/ .

Zoltan Herczeg | 13 Nov 08:12 2014

Announcing the TyGL-WebKit port to accelerate 2D web rendering with GPU

Hi All,

We are proud to announce the TyGL port (link:
http://github.com/szeged/TyGL) on the top of EFL-WebKit. TyGL (pronounced
as tigel) is part of WebKit and provides 2D-accelerated GPU rendering on
embedded systems. The engine is purely GPU based. It has been developed on
and tested against ARM-Mali GPU, but it is designed to work on any GPU
conforming to OpenGL ES 2.0 or higher.

The GPU involvement on future graphics is inevitable considering the pixel
growth rate of displays, but harnessing the GPU power requires a different
approach than CPU-based optimizations. 2D graphics is traditionally
software-based however, and 2D APIs are interfaces to these CPU-based
algorithms. WebKit GraphicsContext API is no different, so the key
challenge of our project was and is producing the expected output in a GPU
friendly way.

Key features:

Batching pipeline:

GPU provides the highest performance when a large number of triangles are
drawn with a single draw command without any OpenGL state changes. The
GraphicsContext API in WebKit provides draw operations for single shapes
however, which can result frequent state changes if implemented naively.
TyGL was designed to group these commands to reduce the number of draw

Automatic shader generator:

TyGL can generate complex shaders from multiple shader fragments, which
allows efficient batching but it also takes care to make them fit into the
shader cache of the GPU.

Trapezoid based path rendering:

TyGL uses trapezoid-based tesselation of shapes and the GPU renders them
with high anti-aliasing quality. We are continuously improving this part
of the engine and look forward to make use of new GPU capabilities (like
Pixel Local Storage) to squeeze more performance out of it.

No software fallback:

The whole engine is optimized for GPU without legacy software fallback.
Hence we don't need to sacrifice optimizations for compatibility. There
are enough software based 2D libraries which can be used when GPU is not

TyGL is already capable of rendering many web-sites correctly, but some
features have not been implemented yet. We continue this work and we are
open to contributions from the community. Contact to us if you want more
information about the project.

U-Szeged's web browser team.
youenn fablet | 10 Nov 11:28 2014

Networking process scope


I looked at the Networking process recently and am wondering what is
in scope/out of scope of this process.

Currently, the networking process is used to load resources from:
- URLs resolved using platform specific libraries (CF, libsoup...),
including data URLs
- Blob URLs
The networking process is not used for (at least):
- appcache resources URLs
- archive resources URLs

Two options come to mind:
1. Use networking process for all URLs that require actual networking.
That would mean moving data & blob URL handling within WebProcess,
probably unifying this loading with appcache/archive resource loading.
2. Use networking process for all URLs. That would mean moving
appcache/archive resource loading into Networking process at some

Any thoughts?

Darin Adler | 9 Nov 01:27 2014

GTK EWS bot failing to build (gtkdoc-mkdb can’t find WebKitDOMCustomUnstable.h)

Hi folks.

The GTK EWS bot is failing to build, with this error:

> Can't open
No such file or directory at
/home/rego/checkout/WebKit/WebKitBuild/DependenciesGTK/Root/bin/gtkdoc-mkdb line 3889.
> Generating webkitdomgtk documentation...
> Traceback (most recent call last):
>   File "/home/rego/checkout/WebKit/Tools/gtk/generate-gtkdoc", line 201, in <module>
>     generate_documentation_for_config(common.build_path('gtkdoc-webkitdom.cfg'))
>   File "/home/rego/checkout/WebKit/Tools/gtk/generate-gtkdoc", line 152, in generate_documentation_for_config
>     return generate_doc(generator, arguments.skip_html)
>   File "/home/rego/checkout/WebKit/Tools/gtk/generate-gtkdoc", line 133, in generate_doc
>     generator.generate(not skip_html)
>   File "/home/rego/checkout/WebKit/Tools/gtk/gtkdoc.py", line 145, in generate
>     self._run_gtkdoc_mkdb()
>   File "/home/rego/checkout/WebKit/Tools/gtk/gtkdoc.py", line 361, in _run_gtkdoc_mkdb
>     self._run_command(args, cwd=self.output_dir)
>   File "/home/rego/checkout/WebKit/Tools/gtk/gtkdoc.py", line 210, in _run_command
>     % (args[0], process.returncode))

Is there someone who knows how to fix this?

— Darin
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
Said Abou-Hallawa | 6 Nov 20:19 2014

Tagged assertions...

Recently I ran into an issue where I wanted to find if there is a bug filed against a certain assertion. The only way I was able to use is to search for the name of the function which has the assertion.  The function can be overloaded or the function can have more than one assertion.  So I found it difficult to track the assertion I am interested in.  In future if the function gets renamed, it will be even more difficult.

I have a suggestion for this.

A pre-build tool will tag every new assertion after the change is committed.  For example in the code I will add the following assertion:


The pre-build tool will change it to be:

ASSERT_TAG(condition, “abcde”);

where “abcde” is a unique tag in all the source code.  A database should be maintained by the build process to keep track what tags are available to be assigned.

When the assertion fires, the dump may look like the following:

ASSERTION FAILED (tag: abcde) condition
… rest of the call-stack

In Bugzilla, there should be a field for the assertion tag.  If I want to file an assertion bug, I should be filling this field like the following:

Product: WebKit
Summary: ASSERTION failed in someFunction
Assertion tag: abcde

Later if the assertion fires, from the dump I can know exactly what assertion fired.  And more importantly I can search for it easily.  In the Bugzilla search page, I should see a field for the assertion tag in the simple search page:

Status: All
Product: WebKit
Assertion tag: abcde

This search will bring me all the opened bugs in WebKit which has the assertion tag = “abcde” if there is any.

ID Product Comp Assignee Status Resolution  Assertion tag  Summary
12345 WebKit abcde ASSERTION failed in someFunction


webkit-dev mailing list
webkit-dev <at> lists.webkit.org
Bem Jones-Bey | 4 Nov 18:28 2014

ASAN and WebKit on OS X

Hey folks,

I'd like to get an ASAN build up and running. However, following the 
instructions on the Wiki (https://trac.webkit.org/wiki/ASanWebKit) isn't 
working for me. (And I had to modify them slightly since it looks like 
things are in slightly different places with Xcode 6.1?) Does anyone have 
more recent instructions? I'm still running OS X 10.9, if it matters.

Antti Koivisto | 31 Oct 18:02 2014

Disk cache


I'm planning to add an experimental HTTP cache implementation to WebKit (https://bugs.webkit.org/show_bug.cgi?id=30322). The main motivations are:

- Improving performance by bringing the cache closer. For example we can serialize WebKit response objects directly instead of converting to/from platform types.
- Making future innovation around caching easier. Closer coordination between cache and WebKit opens new optimization possibilities.

The cache lives in the network process. Most of the code is cross-platform. The storage backend uses libdispatch IO though it wouldn't be hard to add a generic posix one too.

The code will be behind NETWORK_CACHE feature flag.

webkit-dev mailing list
webkit-dev <at> lists.webkit.org