Gmail | 18 Sep 14:01 2014

error when building javascriptcore without inspector

There are some errors with TypeSet when building javascriptcore with ENABLE_INSPECTOR=0. Could anyone
please fix this?
Aravind Prakash | 16 Sep 03:55 2014

Re: Binary archives

I am working on a research project involving webkit. Is there a repository from which I can retrieve past
versions of precompiled 32 bit binaries for webkit? Thanks!

Thank you,
Martin Robinson | 15 Sep 19:30 2014

Re: Port-specific OpenType support

On Sun, Sep 14, 2014 at 11:22 AM, Tim Horton <thorton <at>> wrote:
> On 2014.09.14, at 01:11, Dirk Schulze <krit <at>> wrote:
>> On Sep 11, 2014, at 11:03 PM, Martin Robinson <mrobinson <at>> wrote:
>>> WebKitGTK+ supports OpenType natively and I as far as I know we have
>>> no problems dropping support for SVG fonts. If SVG fonts are supported
>>> by the Mac port though, we will probably still want to maintain
>>> support for our own port, if possible.
>> SVG Fonts live in the non-platform WebCore space. Dropping support for one platform but keeping the code
around for another wouldn’t be of any benefit for WebCore as a whole.
> Agreed (but I don’t think the original email was suggesting that; pretty sure Myles was just gauging
whether there were any ports that don’t have OT support but need SVG fonts, which would preclude
switching over to the translation approach).

Sorry. I probably should have been less obscure about this, but this
was a gentle request that the work be done using cross-platform
abstractions, so that it can be shared. If that's difficult or
impossible, we'll figure something else out. :)

webkit-dev mailing list
webkit-dev <at>
Timothy Hatcher | 13 Sep 01:26 2014

Brian Burg is now a WebKit reviewer

Howdy folks!

I’m happy to announce that Brian is now a WebKit reviewer. Brian has been working on Web Inspector for a while now — covering both the frontend and the backend. His primary focus is integrating his deterministic replay research into WebKit and Web Inspector. More on his work can be found at Lets hope he has enough time to review all of our patches now that he is a new father.

Congratulations on WebKit reviewer and fatherhood, Brian!

— Timothy Hatcher

webkit-dev mailing list
webkit-dev <at>
Bem Jones-Bey | 12 Sep 17:51 2014

Fall Contributors Meeting?

Hey all,

At the WebKit contributors meeting, it was mentioned that there was a desire to move the meeting to the fall,
and potentially having a meeting this fall to start that off. Given that fall is rapidly approaching, I
figured I'd check in to see if there's still a plan for a fall meeting this year, or if it's going to be the same
plan as usual for 2015.

Myles C. Maxfield | 11 Sep 20:44 2014

Port-specific OpenType support

Hello, Webkittens!

I have started work on an SVG font -> OpenType converter [1] with the intent of eventually getting rid of our code path which lays out and draws text using SVG fonts. The motivation is fourfold:

1) Performance: on OS X the native text libraries are over 1000x faster than our SVG code path.
2) Security: There have been numerous security bugs in the SVG font code path.
3) Code clarity: This would greatly simplify the text rendering code.
4) The next version of SVG is removing SVG fonts completely [2]. Chrome has recently dropped support for SVG fonts [3] and Firefox/IE never had it [4] [5].

My question to WebKit-Dev is: Are there any ports who:
1) Want continued support for SVG fonts, and
2) Whose platforms do not support OpenType fonts natively?

Myles C. Maxfield

webkit-dev mailing list
webkit-dev <at>
Brent Fulgham | 11 Sep 01:31 2014

Planning on Requiring Python 2.7 Soon

Hi Everyone,

Now that I’ve worked through the minor issues that prevented us from using Python 2.7 on our Windows bots,
I’d like to move the goalposts and require Python 2.7 (or newer) for our build and test machines.

Will this cause anyone any problems if this becomes the new law of the land?

I plan on making this change on September 17th if I do not hear from anyone on this topic.


webkit-dev mailing list
webkit-dev <at>
chenhao | 9 Sep 05:49 2014

Re: DOMWindow::isCurrentlyDisplayedInFrame does not forbid PostMessageTimer for subframe

Hi , Alexey,

Thanks for your comment! I am really sorry, what I used source code was 
too older, which still keep the DOMWindow in the Frame, not in the 
Document. That question is OK now.

Best Regards!

On 2014年09月04日 15:49, Alexey Proskuryakov wrote:
> Hi!
> Could you please file a bug at If you have a reproducible test case where any bad behavior
happens, that would be most useful.
> I think that the proposed fix would break a case where we currently match Firefox:
> main.html:
> ---------------------
> <button onclick="f()">Click</button>
> <script>
> function f()
> {
>      var child ="child.html");
> = "bar";
>      child.onload = function() {
>          setTimeout(function() {
>              var w = child.frames[0];
>     = "bar"
>              child.location = "about:blank";
>              setTimeout(function() {
>                  alert(" " + +
>                  "\ " + +
>                  "\ " +;
>              }, 100);
>          }, 100);
>      }
> }
> </script>
> ---------------------
> child.html:
> ---------------------
> <iframe src="child2.html"></iframe>
> ---------------------
> child2.html:
> ---------------------
> <p>Hello, world!</p>
> ---------------------
> In this test, we successfully access window.navigator of both main frame and subframe, even though they
are in page cache, and DOMWindow::navigator() has an isCurrentlyDisplayedInFrame() check.
> There was some unfinished work to make this code more reasonable, but it stopped long ago:
<>, <>.
> The name "isCurrentlyDisplayedInFrame" is clearly inaccurate, however it's not clear to me whether we
should be trying to make this function better match what it claims to do, given the above. It seems that we
should instead rename it, and inspect call sites like DOMWindow::postMessageTimerFired for whether
they are doing the right thing.
> - Alexey
> 03 сент. 2014 г., в 5:29, chenhao <chenhao <at>> написал(а):
>> Hi,
>> We met one issue related with PostMessageTimer, it may launched while the Page had been moved in Page
Cache. After checking the implementation, we doubt this situation should be forbid as below:
>> void DOMWindow::postMessageTimerFired(PostMessageTimer& timer)
>> {
>>     if (!document() || !isCurrentlyDisplayedInFrame())
>>         return;
>> But, unfortunately, isCurrentlyDisplayedInFrame() could not work well with sub-frame, because of
the sub-frame and its document would be kept same as before moving in Page Cache, that means the judgement
return true always for sub-frame.
>> So, what I want to do is to judge inPageCache() additionally. Just like below:
>> bool DOMWindow::isCurrentlyDisplayedInFrame() const
>> {
>>     return m_frame && m_frame->domWindow() == this && !m_frame->document()->inPageCache();
>> }
>> That's appreciate to get your comments!
>> Thanks & Best Regards!
>> Hao
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev <at>

webkit-dev mailing list
webkit-dev <at>
D.J. Barrow | 8 Sep 22:33 2014

Apologies this is off topic

If anybody is interested in Carpool websites since google valued Uber at 17 billion dollars
I have a carpool website open sourced at

Also if interested in artificial intelligence have a look at fundamental my god inspired masterpeice.

Sorry again for bothering you.
D.J. Barrow Linux kernel developer
email: dj_barrow <at>
Mobile Ireland: +353-86-1715438, everyones favourite carpool website, works beautifully on the apple iphone, & you thought ebay was good, See my GPL contributions
webkit-dev mailing list
webkit-dev <at>
Bem Jones-Bey | 8 Sep 19:32 2014
Picon redirector broken?

What happened to It's giving me 403 Forbidden (for example:

- Bem
Vienneau, Christopher | 6 Sep 00:23 2014

Using OfflineAsm



I’m looking for some information about the Java script interpreter ASM backend, aka OfflineAsm.  


First a bit of background information; the code I have been using is about a year old, on several platforms we don’t run with JIT and won’t be able to enable it.  This means that we’ve been using the LLINT_C_LOOP path in these cases.  It was considered that the ASM backend may be able to improve performance in this case, currently I’m taking a look at how things are done in a more recent snapshot of the trunk to be sure this development effort will be going in the right direction on what is done there.  As a side note I see that LLINT_C_LOOP has been replaced with #if !ENABLE(JIT) which I guess is pretty much how it has always behaved.


So my questions are:

1)      How is the ASM backend intended to be used? Is there a doc that covers this?

2)      Can I essentially move from the “C LOOP” to neither “C LOOP” nor “JIT”? or is the ASM backend dependent on JIT itself?  It appears this would be handled by the defines in Source\JavaScriptCore\llint\LLIntOfflineAsmConfig.h

3)      If JIT is expected to use the ASM backend is there a way this can be worked around?

4)      Should I actually expect a performance increase compared to the “C LOOP”?

5)      Are there any other suggestions on how to improve performance of Java script code in a non-JIT port?


Thanks for any feedback


Chris Vienneau

webkit-dev mailing list
webkit-dev <at>