Chris Dumez | 20 Oct 23:28 2014

Transition to is<>() / downcast<>() is complete

Hi all,

I just wanted to let you know that I have just landed the last patch porting the code base to using is<>() / downcast<>().
I have managed to remove the NODE_TYPE_CASTS() / TYPE_CASTS_BASE() macros so there should be no code using it anymore.

If you need to add is<>() / downcast<>() support for a specific class, please use the SPECIALIZE_TYPE_TRAITS_*() macro that is in
wtf/TypeCasts.h. Note however, that the template specializations are already generated for most HTML/SVG/MathML elements by
default so you rarely need manual traits specialization for those.

If you find remaining toXXX() casting functions in the code, please let me know as we don’t want to mix toXXX() and downcast<>().
Do let me know if you have improvement suggestions as well. One that is on my TODO list already is to support is<>(RefPtr), there are
not that many call sites that would benefit from this but it would be nice IMHO.

Chris Dumez - Apple Inc.
Cupertino, CA

webkit-dev mailing list
webkit-dev <at>
Dean Jackson | 18 Oct 01:55 2014

CSS4 Media Queries

Hi floks,

I'm going to start implementing a small part of CSS4 Media Queries. I'll put it behind a feature flag.

I'm starting with because Apple wants to discuss
it at the W3C TPAC meetings. We don't have any intention to ship the feature yet - it's just for
experimentation and evaluation. I suggest other ports disable it if they plan on releasing from trunk.

David Kilzer | 16 Oct 10:48 2014

Downtime for Bugzilla upgrade on Thursday, October 16 from 8-10 AM PDT


We’re planning on upgrading Bugzilla ( from 3.2.3 to 4.2.11 on Thursday, October 16 from 8-10 AM PDT.

Sorry for the short notice.  I sent this message from the wrong address, and didn't see he bounce message until now.

Please let me know if you have questions or concerns.  Thanks!


webkit-dev mailing list
webkit-dev <at>
Pascal Jacquemart | 14 Oct 12:25 2014

Removing CUSTOM_PROTOCOLS compile guard?


I was wondering if we could remove the CUSTOM_PROTOCOLS compile guard?

I believe this is the default code path for all ports now since we moved EFL to use it last week

At least, it is mandatory for GTK and EFL builds, I don't know much about other ports
I checked with EWS Bot that it won't break the build (first patch)

Also CUSTOM_PROTOCOLS can be confusing against another real feature called CUSTOM_SCHEME_HANDLER

Do you agree?

webkit-dev mailing list
webkit-dev <at>
Alexey Proskuryakov | 11 Oct 02:01 2014

EWS statistics at dashboard metrics page


There is now a section at with statistics for EWS, style queue and commit queue. I hope that it will be useful for making the queues faster.

Presenting this information in a useful way was tricky, as an interactive nature of EWS makes it challenging to collapse everything down to a single number. So I went to another extreme, trying to explain various groups of results in detail. Hopefully, this will help demystify EWS logic a little bit.

The above screenshot is for October 7th, when we had Windows EWS broken, so it could only produce some results a couple days later. Mac WK2 EWS shows that the majority of patches were processed as quickly as the current hardware allows them to, and there was usually no backlog.

This page relies on some data that we only started storing on the server this week, so historical results are not available.

- Alexey

webkit-dev mailing list
webkit-dev <at>
陈浩 | 10 Oct 17:19 2014

Nesting Level of DOMTimer (non-one-shot timer)

Hi, all,

I am confused about the nesting level of DOMTimer.

First, there is a long story which come from:

Current situation is the timer could forward the gesture state only if 
the nesting level is zero. The problem is the nesting level is managed 
in the Document (ScriptExecutionContext), that means all timers in the 
same document share one nesting level. If one repeat timer was launched, 
all other timers after that could not forward the gesture state, due to 
all of them has a non-zero nesting level.

Below is my testing page, three images at the end of page could delay 
the onload event. You could follow below steps to reproduce what I met:
  1. Click "Start repeating timer" first
  2. After the text change to "Running...", click "Goto next page"
  3. When WebKit page come out, click back button.

What I see is the page before the testing page, because the 
NavigationScheduler::mustLockBackForwardList refused the creation of new 
history item.
   <input type="button" value="Goto next page" onclick="gotoNextPage();">
   <input type="button" value="Start repeating timer" 
   <div id="Timer">Paused</div>
   <script type="text/javascript">

   function gotoNextPage(){

   function startRepeatingTimer(){

width="640" height="480">
width="640" height="480">
width="640" height="480">

According to Web App APIs 
the nesting level of repeating timer will be increased in the loop. I 
doubt that the nesting level should owned by the timer itself, do not 
share with others. Just as described in the defintion, that is task's 
nesting level.

That's appreciate to get your comment!

Thanks & Best Regards!
Dean Jackson | 9 Oct 22:47 2014

Removing ENABLE guard for <at> supports (CSS3_CONDITIONAL_RULES)

We've had support for  <at> supports for a while. I'm planning to remove the compile-time guard for the feature.
(Note: Safari on iOS 8 and the public Yosemite builds currently have it turned off)

Does anyone disagree?

Osztrogonác Csaba | 8 Oct 13:35 2014

Apple Windows EWS bots having issues (again)

Hi All,

it seems the Apple Windows EWS doesn't work at all since 4 days
after , because it can't
find the generated JSInternals.h and cpp. Maybe they aren't
generated, but it's hard to determine without full logs.

I filed a bug report for it 2 days before, but the EWS is
still broken:

Will the bot maintainers have a chance to look into this bug?

Gary Kratkin | 8 Oct 04:26 2014

Determining stable JavaScriptCore revision

Hello, I’m using WebKitGtk 2.4.4. It branched from trunk at r163300 on Feb. 03, 2014. That may not have been a great moment for JavaScriptCore. The jsCStack branch had recently been merged, and 2.4.4 has numerous JSC crashes, especially in DFG. Disabling DFG is a reasonable short-term solution for my use case, but it leaves one crash I’m having trouble debugging. The release build crashes here:

#0 0x00007f1ffd385710 in JSC::JSCell::toBoolean(JSC::ExecState*) const () from
#1 0x00007f1ffd3ac7f0 in ?? () from
#2 0x00007f1ffd3b6de3 in ?? () from
#3 0x00007f1ff7a5d018 in ?? ()
#4 0x00007f1ff7a5d000 in ?? ()
#5 0x00007f1fb40af970 in ?? ()
#6 0x00007f1f7dec6a28 in ?? ()
#7 0x00007f1fac4b0ff8 in ?? ()
#8 0x00007fffe0e09000 in ?? ()
#9 0x00007fffe0e08da0 in ?? ()
#10 0x00007f1ffd36bada in JSC::JITCode::execute(JSC::VM*, JSC::ProtoCallFrame*, JSC::Register*) () from
Backtrace stopped: previous frame inner to this frame (corrupt stack?) 

The debug build asserts:

#0  0x00007f434f2e692f in WTFCrash () at ../../Source/WTF/wtf/Assertions.cpp:333
#1  0x00007f434eefe7ba in JSC::validateCell<JSC::Structure*> (cell=0x3569a30) at ../../Source/JavaScriptCore/runtime/WriteBarrier.h:53
#2  0x00007f434eefe39d in JSC::WriteBarrierBase<JSC::Structure>::operator-> (this=0x7f42fd3bba90) at ../../Source/JavaScriptCore/runtime/WriteBarrier.h:123
#3  0x00007f434ef1d4fc in JSC::JSCell::isString (this=0x7f42fd3bba90) at ../../Source/JavaScriptCore/runtime/JSCellInlines.h:124
#4  0x00007f434ef290e3 in JSC::JSCell::toBoolean (this=0x7f42fd3bba90, exec=0x7f42fd3bb878) at ../../Source/JavaScriptCore/runtime/JSCellInlines.h:188
#5  0x00007f434ef290b5 in JSC::JSValue::toBoolean (this=0x7fff20ff7410, exec=0x7f42fd3bb878) at ../../Source/JavaScriptCore/runtime/JSString.h:521
#6  0x00007f434f085a84 in JSC::operationConvertJSValueToBoolean (exec=0x7f42fd3bb878, encodedOp=0x7f42fd3bba90) at ../../Source/JavaScriptCore/jit/JITOperations.cpp:861
#7  0x00007f43069fc99c in ?? ()
#8  0x00007f43069218e0 in ?? ()
#9  0x000000000274c130 in ?? ()
#10 0x000000000301f740 in ?? ()
#11 0x00000000031e5eb0 in ?? ()
#12 0x0000000003295eb8 in ?? ()
#13 0x00007f434a8eae08 in WebCore::JSDOMWindowBase::supportsProfiling (object=0x7f43069218e0) at ../../Source/WebCore/bindings/js/JSDOMWindowBase.cpp:121
#14 0x00007fff20ff74c0 in ?? ()
#15 0x00007f434f06f74c in JSC::JITCode::execute (this=0xf0458b4832eb0000, vm=0xb8077500f07d, protoCallFrame=0x8348f04589480000, topOfStack=0xdb6e8c7894860c0) at ../../Source/JavaScriptCore/jit/JITCode.cpp:48
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

My question isn’t how to debug this, though any insights would be welcome. Instead I’m hoping to to roll JSC forward or backward to a more stable revision somewhere near 02/2014  (in order to reduce problems merging into WebKitGtk). It seems best to tie it to a contemporaneous Safari release, perhaps from the safari-600.1 branch. I’m wondering if that branch is considered always stable, and therefore safe to pull from at an arbitrary revision. Alternatively, is there a way to discover the revision for a given Safari release?

Thanks for any help,

webkit-dev mailing list
webkit-dev <at>
Benjamin Poulain | 7 Oct 21:47 2014

Re: Upstreaming the Haiku port again

I believe it is better for Haiku to remain out of the main tree until 
the project gains at least 2 reviewers.

Without dedicated reviewers, you will struggle to integrate any patch 
because nobody in the WebKit project is familiar with the Haiku 
platform. To give you an idea of how huge the backlog is, look at the 
list of patches currently waiting for review:

The best way forward is to start making patches for the fixes you have 
made that are independent of any platform. An other kind of patches is 
any refactoring that improve platform abstractions. Cleaning up the code 
this way should make it easier for you to work on a branch.

Those fixes would go toward a nommation as committer, then reviewer. 
Without multiple reviewers, it is just impossible for a port to thrive 
on the main branch.

Note that having reviewers is not a enough to upstream a port, you would 
be expected to contribute to the core. But I believe it is a necessary 
condition for success.

What are the major pain points today of developing Haiku WebKit in a 
branch? The first step is addressing those in the main branch.


On 10/7/14, 6:22 AM, pulkomandy wrote:
> Hello WebKit,
> For about one year now I've been working on updating and improving the
> Haiku port of WebKit. This was upstreamed once in 2010, but then went
> unmaintained for a long time and was dropped from WebKit SVN.
> We have learnt from this failure (I hope) and we are ready to do another
> upstreaming attempt:
>   * We are now using git instead of SVN, making it much easier to track
> changes in WebKit and keep our port up to date (I'm merging changes
> more or less every week)
>   * I'm working full-time on this, as long as our users continue donating
> enough money to the Haiku project to fund my work. So I can spend the
> needed time keeping things working
>   * We have switched from Jam to CMake, and we share most of the build
> files with the other ports using CMake
>   * We have allocated a machine to run a buildbot slave for WebKit
> The current sources can be viewed at (in
> branch "rebased").
> I would like to use the upstreaming as an opportunity to get the code
> reviewed by other WebKit developers, and for this I plan to extract
> patches from this source tree, and cut them in chunks of reasonable size
> for review.
> Do you see any problem with this? Should I start with setting up the
> buildbot, or should I first start submitting patches? In the latter
> case, is starting with Tools/Scripts the right thing to do?
> suggests patches should
> be smaller than "20k". Is that bytes, lines of code, or some other unit?
> Thanks,
youenn fablet | 3 Oct 18:36 2014

Compiling WebKit Windows targets

Hi all,

I tried compiling WebKit on Windows.
I successfully built the Release_WinCairo target :)
But not the Release target...

The build log says that some libs are missing in my current setup
(Windows 7 SP1, VS 2013): LibGLESv2 did not find LIBCMT.lib and WTF
did not find libcpmt.lib.

Any idea on how to fix this?