Alex Christensen | 29 Jul 03:03 2015

forwarding headers and CMake

In my work getting CMake working on Windows, I discovered a subtle difference in how forwarding headers are
made.  In the existing build system, a forwarding header contains the entire contents of the original
header.  In the current CMake build, the WEBKIT_CREATE_FORWARDING_HEADERS macro creates lots of one
line files that #include the original file.

For example, my JSBase.h forwarding header contains only this one line:
#include “JavaScriptCore/API/JSBase.h”

In order to switch the Windows build over to use CMake, I’m pretty sure we would need the entire contents of
the headers to be copied to the build directory.  Would changing this build behavior cause a problem for the
GTK or EFL ports?  If so, I would probably make the forwarding headers macros port specific.

webkit-dev mailing list
webkit-dev <at>
Vienneau, Christopher | 29 Jul 01:52 2015

border-radius lost when applying -webkit-filter



I’m on a slightly older pull from WebKit trunk (179714) and I’m seeing this issue where border radius is lost if a css filter is also applied.  My sample page looks like this:

<!DOCTYPE html>



<title>Basic CSS Filters</title>

<head>Basic CSS Filters</head>



#pic {

  border-radius: 10px;

  -webkit-filter: sepia(0.8);






  <img id="pic" src="testImage.jpg">





When I run with the above code the image is rendered with the Sepi filter, but the border radius is not applied.  If I comment out the filter the image is properly rendered with the border radius applied.  By debugging I can see that a different code path is followed in the two cases. 

Without the filter:

>             WebKitd.dll!WebCore::GraphicsContext::clip(const WebCore::Path & path, WebCore::WindRule windRule) Line 951                C++

               WebKitd.dll!WebCore::GraphicsContext::clipRoundedRect(const WebCore::FloatRoundedRect & rect) Line 586         C++

               WebKitd.dll!WebCore::RenderBoxModelObject::clipRoundedInnerRect(WebCore::GraphicsContext * context, const WebCore::FloatRect & rect, const WebCore::FloatRoundedRect & clipRect) Line 540          C++

               WebKitd.dll!WebCore::RenderReplaced::paint(WebCore::PaintInfo & paintInfo, const WebCore::LayoutPoint & paintOffset) Line 180  C++

we get into clipRoundedInnerRect which goes into the code which can perform the clipping operation, and all works as expected.


With the Filter (3 callstacks below):

>             WebKitd.dll!WebCore::GraphicsLayer::setContentsClippingRect(const WebCore::FloatRoundedRect & roundedRect) Line 377  C++

               WebKitd.dll!WebCore::RenderLayerBacking::updateImageContents() Line 1960                C++

               WebKitd.dll!WebCore::RenderLayerBacking::updateConfiguration() Line 595      C++

               WebKitd.dll!WebCore::RenderLayerCompositor::rebuildCompositingLayerTree(WebCore::RenderLayer & layer, WTF::Vector<WebCore::GraphicsLayer *,0,WTF::CrashOnOverflow> & childLayersOfEnclosingLayer, int depth) Line 1522             C++


>             WebKitd.dll!WebCore::GraphicsLayer::setContentsClippingRect(const WebCore::FloatRoundedRect & roundedRect) Line 377  C++

               WebKitd.dll!WebCore::RenderLayerBacking::resetContentsRect() Line 1124       C++

               WebKitd.dll!WebCore::RenderLayerBacking::updateAfterDescendants() Line 1003          C++

               WebKitd.dll!WebCore::RenderLayerCompositor::rebuildCompositingLayerTree(WebCore::RenderLayer & layer, WTF::Vector<WebCore::GraphicsLayer *,0,WTF::CrashOnOverflow> & childLayersOfEnclosingLayer, int depth) Line 1609             C++

>             WebKitd.dll!WebCore::GraphicsLayer::setContentsClippingRect(const WebCore::FloatRoundedRect & roundedRect) Line 377  C++

               WebKitd.dll!WebCore::RenderLayerBacking::resetContentsRect() Line 1124       C++

               WebKitd.dll!WebCore::RenderLayerBacking::updateAfterDescendants() Line 1003          C++

                WebKitd.dll!WebCore::RenderLayerCompositor::updateCompositingDescendantGeometry(WebCore::RenderLayer & compositingAncestor, WebCore::RenderLayer & layer, bool compositedChildrenOnly) Line 1862           C++


In this path we never call clipRoundedInnerRect, we do however call setContentsClippingRect with what looks like appropriate parameters to do what we would want.  However upon investigation it appears that this data is not used by anything.  Looking at other ports it seems that GraphicsLayerCA.cpp may be making use of this data in its clipping technique.


Looking for fixes that might already be available I found the two below interesting, however note that I already have these in the change that we last took.  They just sounds extremely similar to what I’m describing.



I’m wondering if it can be confirmed that this issue has been a problem for other ports as well?  Are there any fixes that address my problem that I may have overlooked?  What if anything needs to be done to support this (is something like what is done in the CA port a requirement?)  Any advice on implementing the minimal changes, CA’s changes appear extensive.


Thanks for any advice


Chris  Vienneau

webkit-dev mailing list
webkit-dev <at>
Pascal Jacquemart | 28 Jul 18:09 2015

Infinite JavaScript loop blocks the MiniBrowser


I am trying to protect the MiniBrowser from executing faulty JavaScript code taking too much time / CPU. All browsers normally raise a pop-up allowing the user to stop the script and run away.
But MiniBrowser does not seem to have such feature. It is just stuck forever ;-(

After a little digging I found this JSC API: JSContextGroupSetExecutionTimeLimit()
I had to implement a JSC Watchdog back-end because it is not implemented for EFL, fair enough -> (ongoing)

Now the JSContextGroupSetExecutionTimeLimit() have the expected behaviour.
I can stop the JavaScript execution and run away... Great but the big problem now is that the JavaScript won't restart. Even while loading other pages, the JavaScript remains disabled.

If you have any hints about this, I would be grateful.
How to restart JavaScript execution? Where to look? Is it an EFL bug?

Thanks,                       Pascal Jacquemart

webkit-dev mailing list
webkit-dev <at>
Rodney Dowdall | 27 Jul 17:07 2015

Stack Alignment error in LLINT


I am seeing a SIGTRAP generated in the LLINT code when I try and load up 
a page.  It happens as soon as the page tries to execute JavaScript.  
The target is an 32 bit x86 machine.  The SIGTRAP appears to happen when 
it is checking the stack alignment.  I have tried compiling the code 
with the gcc option -mstackrealign and without it.  The SIGTRAP is 
generated in the same spot with or without the option.  C++ exceptions 
are turned on (they have to be with this particular compiler.  The 
compiler is gcc based).  The version of Webkit that I am building from 
is 184845.

Here is the assembly execution that causes the SIGTRAP:

b9a80ef7:   push %ebp
b9a80ef8:   mov %esp,%ebp
b9a80efa:   push %esi
b9a80efb:   push %edi
b9a80efc:   push %ebx
b9a80efd:   mov 0xc(%ebp),%ebx
b9a80f00:   mov 0x8(%ebp),%edi
b9a80f03:   mov %ebp,%esp
b9a80f05:   sub $0x20,%esp
b9a80f08:   mov %ebx,(%esp)
b9a80f0b:   mov 0x1498(%ebx),%edx
b9a80f11:   mov %edx,0x4(%esp)
b9a80f15:   mov 0x1494(%ebx),%edx
b9a80f1b:   mov %edx,0x8(%esp)
b9a80f1f:   mov 0x10(%ebp),%esi
b9a80f22:   mov 0x20(%esi),%edx
b9a80f25:   add $0x4,%edx
b9a80f28:   shl $0x3,%edx
b9a80f2b:   mov %esp,%eax
b9a80f2d:   sub %edx,%eax
b9a80f2f:   cmp 0x2384(%ebx),%eax
b9a80f35:   jae 0xb9a80f71 <vmEntryToJavaScript+122>

b9a80f71:   mov %eax,%esp
b9a80f73:   mov $0x4,%eax
b9a80f78:   sub $0x1,%eax
b9a80f7b:   mov 0x4(%esi,%eax,8),%ecx
b9a80f7f:   mov %ecx,0xc(%esp,%eax,8)
b9a80f83:   mov (%esi,%eax,8),%ecx
b9a80f86:   mov %ecx,0x8(%esp,%eax,8)
b9a80f8a:   test %eax,%eax
b9a80f8c:   jne 0xb9a80f78 <vmEntryToJavaScript+129>

b9a80f9e:   sub $0x1,%ecx
b9a80fa1:   movl $0xfffffffc,0x2c(%esp,%ecx,8)
b9a80fa9:   movl $0x0,0x28(%esp,%ecx,8)
b9a80fb1:   cmp %ecx,%edx
b9a80fb3:   jne 0xb9a80f9e <vmEntryToJavaScript+167>
b9a80fb5:   mov 0x28(%esi),%eax
b9a80fb8:   test %edx,%edx
b9a80fba:   je 0xb9a80fd0 <vmEntryToJavaScript+217>

b9a80f78:   sub $0x1,%eax
b9a80f7b:   mov 0x4(%esi,%eax,8),%ecx
b9a80f7f:   mov %ecx,0xc(%esp,%eax,8)
b9a80f83:   mov (%esi,%eax,8),%ecx
b9a80f86:   mov %ecx,0x8(%esp,%eax,8)
b9a80f8a:   test %eax,%eax
b9a80f8c:   jne 0xb9a80f78 <vmEntryToJavaScript+129>

b9a80f78:   sub $0x1,%eax
b9a80f7b:   mov 0x4(%esi,%eax,8),%ecx
b9a80f7f:   mov %ecx,0xc(%esp,%eax,8)
b9a80f83:   mov (%esi,%eax,8),%ecx
b9a80f86:   mov %ecx,0x8(%esp,%eax,8)
b9a80f8a:   test %eax,%eax
b9a80f8c:   jne 0xb9a80f78 <vmEntryToJavaScript+129>

b9a80f78:   sub $0x1,%eax
b9a80f7b:   mov 0x4(%esi,%eax,8),%ecx
b9a80f7f:   mov %ecx,0xc(%esp,%eax,8)
b9a80f83:   mov (%esi,%eax,8),%ecx
b9a80f86:   mov %ecx,0x8(%esp,%eax,8)
b9a80f8a:   test %eax,%eax
b9a80f8c:   jne 0xb9a80f78 <vmEntryToJavaScript+129>
b9a80f8e:   mov 0x10(%esi),%edx
b9a80f91:   sub $0x1,%edx
b9a80f94:   mov 0x20(%esi),%ecx
b9a80f97:   sub $0x1,%ecx
b9a80f9a:   cmp %ecx,%edx
b9a80f9c:   je 0xb9a80fb5 <vmEntryToJavaScript+190>

b9a80fd0:   mov %esp,0x1498(%ebx)
b9a80fd6:   mov %ebp,0x1494(%ebx)
b9a80fdc:   add $0x8,%esp
b9a80fdf:   mov %esp,%ecx
b9a80fe1:   and $0xf,%ecx
b9a80fe4:   test %ecx,%ecx
b9a80fe6:   je 0xb9a80fee <vmEntryToJavaScript+247>
b9a80fe8:   mov $0xbad0dc02,%ecx
b9a80fed:   int3

So using the LLintAssembly.h I tracked this too:

     "\tjz " 

Which leads me to believe that the alignment on my stack is wrong. The 
value of esp is 0x7db9284.  The value of ecx after the and is 4, so that 
looks right.

I don't have a lot of experience with the LLINT, so I was wondering if 
there was a specific place I should start to look to see why this error 
is beign generated.

Alex Christensen | 22 Jul 01:29 2015

CMake on Windows

I plan to switch build-webkit --wincairo to use CMake in the near future.  We are not ready to remove the
Visual Studio build system yet and won’t be for a while, but a bot using CMake on Windows will help us
notice if anything breaks as we make more progress.  Building from
Source/WebKit/WebKit.vcxproj/WebKit.sln should be unaffected.  I think I’m the only one with a
WinCairo build bot, but please let me know if this will cause a problem for anyone.


webkit-dev mailing list
webkit-dev <at>
Vienneau, Christopher | 11 Jul 01:05 2015

Compilation issue with VS2015RC



Recently we’ve been attempting to move our code base to build with VS2015 RC since this provides us with some support that we’ll be needing in the future for our products.  The changes for compilation with the new compiler haven’t been too bad, and I have everything building with the exception of one line:


FILE: JSCSSValueCustom.cpp


67           JSValue toJS(ExecState*, JSDOMGlobalObject* globalObject, CSSValue* value)

68           {

69               if (!value)

70                   return jsNull();


72               // Scripts should only ever see cloned CSSValues, never the internal ones.

73               ASSERT(value->isCSSOMSafe());


75               // If we're here under erroneous circumstances, prefer returning null over a potentially insecure value.

76               if (!value->isCSSOMSafe())

77                   return jsNull();


79               JSObject* wrapper = getCachedWrapper(globalObject->world(), value);


81               if (wrapper)

82                   return wrapper;


84               if (value->isWebKitCSSTransformValue())

85                   wrapper = CREATE_DOM_WRAPPER(globalObject, WebKitCSSTransformValue, value);

86               else if (value->isWebKitCSSFilterValue())

87                   wrapper = CREATE_DOM_WRAPPER(globalObject, WebKitCSSFilterValue, value);

88               else if (value->isValueList())

89                   wrapper = CREATE_DOM_WRAPPER(globalObject, CSSValueList, value);

90               else if (value->isSVGPaint())

91                   wrapper = CREATE_DOM_WRAPPER(globalObject, SVGPaint, value);

92               else if (value->isSVGColor())

93                   wrapper = CREATE_DOM_WRAPPER(globalObject, SVGColor, value);

94               else if (value->isPrimitiveValue())

95                   wrapper = CREATE_DOM_WRAPPER(globalObject, CSSPrimitiveValue, value);

96               else

97                   wrapper = CREATE_DOM_WRAPPER(globalObject, CSSValue, value);


99               return wrapper;

100         }


It produces the linker error:

JSBindingsAllInOne.obj : error LNK2019: unresolved external symbol "public: __thiscall WebCore::CSSPrimitiveValue::operator<class WTF::Ref<class WebCore::CSSPrimitiveValue> > class WTF::Ref<class WebCore::CSSPrimitiveValue>(void)const " (??$?BV?$Ref <at> VCSSPrimitiveValue <at> WebCore <at> <at> <at> WTF <at> <at> <at> CSSPrimitiveValue <at> WebCore <at> <at> QBE?AV?$Ref <at> VCSSPrimitiveValue <at> WebCore <at> <at> <at> WTF <at> <at> XZ) referenced in function "class WebCore::JSDOMWrapper * __cdecl WebCore::createWrapper<class WebCore::JSCSSPrimitiveValue,class WebCore::CSSPrimitiveValue>(class WebCore::JSDOMGlobalObject *,class WebCore::CSSPrimitiveValue *)" (??$createWrapper <at> VJSCSSPrimitiveValue <at> WebCore <at> <at> VCSSPrimitiveValue <at> 2 <at> <at> WebCore <at> <at> YAPAVJSDOMWrapper <at> 0 <at> PAVJSDOMGlobalObject <at> 0 <at> PAVCSSPrimitiveValue <at> 0 <at> <at> Z)


As you can see there are many other similar code lines in the area, none of which cause a problem.  Despite my many attempts I can’t seem to satisfy the linker by providing it the definition it needs.

·         I’ve attempted manually adding the copy constructor definition (I believe that is what it is describing):

o   CSSPrimitiveValue::CSSPrimitiveValue(ClassType classType, const CSSPrimitiveValue& cloneFrom)

o   CSSPrimitiveValue::CSSPrimitiveValue(const CSSPrimitiveValue& cloneFrom)

·         I’ve tried removing the usage of the “AllInOne” file, thinking that it may be causing some issue.

·         I’ve attempted to debug the code when the offending line is commented out, hoping to see better how the other lines function.  Though I’m not sure what path would cause it to execute, I haven’t hit it in my limited testing.

·         One of my colleagues reached out the MS on the issue, but it behaves as expect on their end (small sample code does not find a bug in the compiler).



Any suggestions would be much appreciated








webkit-dev mailing list
webkit-dev <at>
Osztrogonác Csaba | 7 Jul 13:42 2015

EWS is down

Hi All,

it seems EWS server is down -

"Error: Not Found
The requested URL / was not found on this server."

It would be great if somebody could check and fix it. Thanks.

Kim, NamHoon | 7 Jul 06:26 2015

maximalOutlineSize inflate all RenderLayers

Hi experts,


While hacking composited layer in WebKit, I realized CSS outline style inflate size of all RenderLayers. Since WebKit has default css of 5px outline for focused element, focusing input in the below sample inflate the cyan box. This can reproduced in WK2 OSX port in r186227.



.box {

  position: fixed;

  top: 50px;

  width: 100px;

  height: 30px;

  border-radius: 10%;

  background-color: cyan;




<input type='text'>

<div class='box'></div>


Through investigation, I found `RenderView::m_maximalOutlineSize` value is set in the RenderElement::setStyle() function. And this cause inflation of layers in RenderLayer::localBoundingBox() function. Since setter of `m_maximalOutlineSize` scheduled rebuild of the whole composited layers, all layers inflated by the value.


Honestly, I don’t know about this value’s purpose. But it seems weird to me that this value does not cleared in the RenderView even after outline style cleared. (i.e. loose focus of the input)


And this behavior makes several problem in our ports, [EAWebKit][1]. Since we uses composited layers backed by DirectX, this makes paint call requests larger size than texture itself in TextureMapperTile::paint() function. This cause rendering of corrupted memory. Steps follow,


a. layer inflated by maximalOutlineSize. Let 100x100 layer increased to 110x110.

b. texture increased in the TextureMapperTiledBackingStore::createOrDestroyTilesIfNeeded() to 110x110.

c. layer’s texture destroyed then reconstructed by display style change.

d. while reconstruct of the layer’s texture, this time texture created with the size of 100x100 instead of 110x110.

e. then painting this texture in TextureMapperTile::paint() request 110x110 rect for 100x100 texture.


While step d. GraphicsLayerTextureMapper::m_needsDisplayRect intersected with TextureMapperTile::m_rect, makes texture smaller then layer’s size. On the other hand, TextureMapperTile::paint() call in the step e. request whole TextureMapperTile::m_rect for draw request.


To escape this problem, I overridden default style of :focus to `outline: none`. I wonder better solution for this. Is it some bug of WebKit? Is there some proper way to handle this? If inflation of the layers inevitable, it seems reasonable shrunken back after outline style cleared.






webkit-dev mailing list
webkit-dev <at>
Yusuke SUZUKI | 6 Jul 19:05 2015

JSC framework API proposal: setting a handler for enqueuing tasks

Hi WebKittens,

I've landed the update of the ES6 Promise implementation.
Through this work, I've experimentally added the internal private function, <at> enqueueJob(JS function, JS array for arguments).
This is corresponding to the ES6 spec EnqueueJob[1].

This EnqueueJob handler is now tightly integrated with WebCore's microtask infrastructure. So in JSC framework side, we cannot use this function.
As a result, current JSC framework disables Promise because there's no event loop abstraction.

So I propose the API configuring euqueueJob handler into JSC VM (That corresponds to the Realm in ECMA spec).


void JSContextGroupSetEnqueueJobCallback(JSContextGroupRef, JSEnqueueJobCallback, void* callbackData);

What do you think about this?

Best Regards,
Yusuke Suzuki
webkit-dev mailing list
webkit-dev <at>
Alex Christensen | 2 Jul 19:58 2015

DirectX SDK

Heads up: my recent updating of ANGLE (r186169, r186172, r186201, and r186220) made it so WinCairo uses the
DirectX SDK that comes with Visual Studio 2013, not the June 2010 DirectX SDK.  Please let me know if this
causes a problem for anyone.

Mario Sanchez Prada | 2 Jul 13:11 2015

Crash on xLarge memory allocation using bmalloc on 32bit systems

Hi all,

As I already reported last week in webkit-gtk[1], I've been reliably seeing
a crash in bmalloc lately in my 32bit Linux system every single time I run a
specific Webkit-based app, after upgrading from WebKitGTK+ 2.6.2 to 2.8.3.

See below and excerpt of the best backtrace I could get (see the full one in

(gdb) bt
#0  allocateXLarge () at
#1  0xb4fc94f5 in allocateXLarge () at
#2  0xb4fc6ac4 in allocateXLarge () at
#3  0xb4fc6b2e in allocateSlowCase () at
#4  0xb4f95de2 in allocate () at
#5  allocate () at
#6  malloc () at
#7  fastMalloc () at
#8  0xb5592815 in allocateBuffer () at

Also, according to Red Hat bugzilla's bug 1225733 [2], it seems I'm not the
only one getting the crash, since it has been reported more than 105 times
in Fedora now (always for 32bit systems too), and I wonder whether this
might be an issue for other ports too, such as Apple or EFL.

For what it's worth, and in case you want to try this out yourself too, I
can now reproduce this bug also simply by loading this URL on Minibrowser:

Last, I initially thought this might be related to WK bug 145385 (integer
overflow), but turned out not to be the case, so I reported a new one:

If you check my last comments in there, you will see that I found out that
passing -fno-tree-sra to gcc while compiling would reliably prevent the
crash from happening, both in my use case and when using the URL above.

Does anyone here have any idea why this could be the case? Any hint?

While passing -fno-tree-sra could be an interesting temporary workaround
(specially if constrained in scope to bmalloc only) for downstream, it does
feel like papering over the real issue, which could still be there in WK.