Re: [webkit-dev] FYI: Buildbot monitor extension for Chrome

[Adam Barth]

Cool!  Installed.

Adam


On Tue, Feb 16, 2010 at 7:54 PM, TAMURA, Kent  wrote:
> https://chrome.google.com/extensions/detail/dfomjpbnljkkohdofbhnphphdkaojklg
> I made a Chrome extension to monitor WebKit buildbot status.
> It shows a red badge when any of Leopard/Windows build/Chromium bots is red.
> It is the same rule as our commit-queue, and you can change the set of bots
> with the option view.
>
> --
> TAMURA Kent
> Software Engineer, Google
>
>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Making Webkit compatible with ADS 1.2

[Pritam Nandy]

On Wed, Feb 17, 2010 at 9:17 AM, Pritam Nandy wrote:

> Hi,
>
> Currently, as we all know that Webkit sources are incompatible with ADS
> v1.2 Compiler set from ARM. So, I want to know can we change the Webkit
> sources, especially the C++ files, so as to make it compatible with ADS 1.2?
> What would be the effort needed, according to you experts, to make the
> necessary changes and which are the Modules you think would require most
> changes?
>
> Please let me know the necessary details since you guys are the experts
> whereas I'm a newbie to Webkit just trying to compile it with ADS 1.2.
>
> -Pritam.
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] FYI: Buildbot monitor extension for Chrome

[TAMURA, Kent]

https://chrome.google.com/extensions/detail/dfomjpbnljkkohdofbhnphphdkaojklg

I
made a Chrome extension to monitor WebKit buildbot status.
It shows a red badge when any of Leopard/Windows build/Chromium bots is red.
It is the same rule as our commit-queue, and you can change the set of bots
with the option view.


--
TAMURA Kent
Software Engineer, Google



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] qt-ews down for a while

[Adam Barth]

On Tue, Feb 16, 2010 at 6:34 PM, Ariya Hidayat  wrote:
>> It looks like the Qt build now requires Qt 4.6.  Currently, the qt-ews
>> is using Ubuntu Karmic (which has Qt 4.5).  I'll upgrade the machine
>> to Lucid, but, in the meantime, the qt-ews will be down.
>
> http://trac.webkit.org/changeset/54854 should allow Qt 4.5 again.

Good times.  I'll try bringing the bot up again.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] qt-ews down for a while

[Adam Barth]

It looks like the Qt build now requires Qt 4.6.  Currently, the qt-ews
is using Ubuntu Karmic (which has Qt 4.5).  I'll upgrade the machine
to Lucid, but, in the meantime, the qt-ews will be down.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] adding support for m17n

[Darin Adler]

On Feb 15, 2010, at 11:23 PM, haithem rahmani wrote:

> the m17n seems providing the same features as the icu library.

There is some overlap, but I’m not sure it includes all the ICU features used 
by WebKit.

Folks who don’t want to use ICU have already made ports that use WinCE platform 
functions, glib functions, and Qt functions rather than ICU, but in each case 
it was a lot of work.

> is it possible to support it into webkit ?

Sure. If someone working on WebKit wants to put the time into this, it would 
probably be OK to support yet another configuration here.

I don’t think there’s anyone already working on it.

All the usual difficulties apply for a new code path — the code has to be 
adopted by one of the ports that has active maintenance or a buildbot, 
otherwise the code is highly likely to rot.

-- Darin

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Server Downtime: Tomorrow Feb 16 8am

[William Siegrist]

Everything is back up. Let me know if you have any problems. 

-Bill


On Feb 15, 2010, at 9:13 AM, William Siegrist wrote:

> We need to move our servers to a new data center tomorrow. The move will 
> start around 8am PST tomorrow morning and take several hours. All of 
> webkit.org will be affected.  If all goes well, services could be back up by 
> 11am, but please be patient if it takes longer. 
> 
> Thanks
> -Bill
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] focus property of node

[Darin Adler]

On Feb 12, 2010, at 9:59 PM, jyotigoyal wrote:

> I am new to webkit. I need to set that property of a node which makes a node 
> focusable. which is that property ? how do I access this property of node to 
> find whether it is focussed or not.

This is a mailing list for development of WebKit, not for help using it. See 
 for some other mailing lists, including 
webkit-help, where this question would be on topic.

Further, I think your question is too unclear to get an answer. Your question 
needs to be more specific and answer things like: What programming language are 
you using? Are you developing a web page or a web browser?

But not on this mailing list.

-- Darin

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Implementing WebTiming as a part of HTML5

[Darin Fisher]

On Mon, Feb 15, 2010 at 1:37 AM, Alois Reitbauer <
alois.reitba...@dynatrace.com> wrote:

> As discussed with Richard and Zhiheng here the feedback on the proposal by
> dynaTrace software. We had a look at the new spec draft and have a number of
> questions and proposals:
>
>  -In the NavigationTiming interface you refer to paint events. Do you
> really mean paint here or layouting? Paint events are in our opinion less
> relevant from a performance perspective than layouting (or reflow) events.
>
> - Additionally it would be nice to not only see the pain event count
> but also the paint event time. You can then find out how much time is spent
> layouting. Just having the number of operations does not provide this
> information.
>
> - We are a bit unclear how to access the timing information for the
> HTML elements. Would we have to browse the whole DOM to get them? This could
> result in quite a performance overhead.
>
> - Additionally we wonder if you only want to additionally support
> timings for XHR requests. We think it would be good to support every type of
> network request.
>
> - We are also wondering about what to use the TimingMap respectively
> the ticks property for.  A nice use case would be to store the time of a
> click event and then retrieve it on the next page. However this will not be
> part of the window.timing attribute – right?
>
> On the mailing there was also a note that “… some parts are implemented by
> chromium”.  Are there any more details which parts, so we could try to use
> them and provide feedback as well.
>
>
window.chrome.loadTimes() has the following properties:

requestTime
startLoadTime
commitLoadTime
finishDocumentLoadTime
finishLoadTime
firstPaintTime
firstPaintAfterLoadTime
navigationType

Note: This is not a well documented API, and it is something we may drop in
the future in favor of the WebTiming spec.

-Darin



>
>
> - Alois
>
>
>
> Alois Reitbauer, Technology Strategist, dynaTrace software GmbH
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] css column-break support

[Skull Knife]

I this being actively worked on and/or are there any requirements  
written down for the goals of the re-write?





On Feb 15, 2010, at 8:39 AM, David Hyatt  wrote:


Columns need to be completely re-written.

dave

On Feb 12, 2010, at 3:01 PM, Joseph Zuromski wrote:

I was wondering if there was any plan in the near future to support  
css column-break-before, -after, and -inside in the near future?  I  
noticed https://bugs.webkit.org/show_bug.cgi?id=15552 but that  
looks like it hasn't been looked at in a long time...


Joseph
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Webkit mipsel crashing in arenaDelete

[Zoltan Horvath]

Hey,

if you just simply leave -DUSE_SYSTEM_MALLOC from g++'s parameters it will 
compile with TCmalloc (as Stephan wrote TCSystemAlloc.cpp needs to be added to 
the project). /release mode/

Zoltan

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Webkit mipsel crashing in arenaDelete

[Stephan Assmus]

Hi,

On 2010-02-16 at 09:31:32 [+0100], İsmail Dönmez  wrote:
> On Tue, Feb 16, 2010 at 10:22 AM, Stephan Assmus  wrote:
> > Hi,
> >
> > On 2010-02-16 at 08:50:21 [+0100], Bharathwaaj S 
> > wrote:
> >> I could port webkit to mipsel architechture using DirectFB Backend.
> >>
> >> I've taken svn WebKitGtk release 1.1.8 present
> >> here
> >> .
> >>
> >> I could get google.com homepage when I run GtkLauncher. But when I press 
> >> any
> >> the Google Search button, it crashes.
> >>
> >> I added printfs in the code and I found that it is crashing in File
> >> WebCore/rendering/RenderObject.cpp Function arenaDelete in the line
> >>
> >> delete this
> >>
> >> It also crashes when I reload the google page by pressing right click and
> >> reload.
> >>
> >> The same release when built for x86 runs fine.
> >>
> >> Kindly help me in solving this issue.
> >
> > No idea if this is helpful or even applies to your problem, but during the
> > Haiku porting effort, we found out that when using USE_SYSTEM_MALLOC=1,
> > WebCore makes some assumptions about alignment of allocations that are not
> > guarenteed when using malloc() (should use memalign()). When we switched 
> > to
> > using the built-in TCSystemMalloc, those problems went away.
> 
> Thats interesting. How did you force TCSystemMalloc for Haiku port?

I could send you a diff for just this change, but the Haiku port uses it's 
own buildsystem which is not (yet?) part of WebKit trunk. All that seemed 
necessary to enable it was to

1) not define "USE_SYSTEM_MALLOC=1"
2) include TCSystemAlloc.cpp into the libjavascriptcore.so build.

For debug builds, we also force the use of system malloc to OFF:

Index: JavaScriptCore/wtf/FastMalloc.cpp
===
--- JavaScriptCore/wtf/FastMalloc.cpp   (revision 47)
+++ JavaScriptCore/wtf/FastMalloc.cpp   (revision 49)
@@ -92,7 +92,7 @@
 #if !(defined(USE_SYSTEM_MALLOC) && USE_SYSTEM_MALLOC) && defined(NDEBUG)
 #define FORCE_SYSTEM_MALLOC 0
 #else
-#define FORCE_SYSTEM_MALLOC 1
+#define FORCE_SYSTEM_MALLOC 0 // TODO: hacked to off also in debug build
 #endif
 
 // Use a background thread to periodically scavenge memory to release back 
to the system

This was necessary for some reason I cannot remember right now.

Best regards,
-Stephan
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Webkit mipsel crashing in arenaDelete

[İsmail Dönmez]

Hi;

On Tue, Feb 16, 2010 at 10:22 AM, Stephan Assmus  wrote:
> Hi,
>
> On 2010-02-16 at 08:50:21 [+0100], Bharathwaaj S 
> wrote:
>> I could port webkit to mipsel architechture using DirectFB Backend.
>>
>> I've taken svn WebKitGtk release 1.1.8 present
>> here
>> .
>>
>> I could get google.com homepage when I run GtkLauncher. But when I press any
>> the Google Search button, it crashes.
>>
>> I added printfs in the code and I found that it is crashing in File
>> WebCore/rendering/RenderObject.cpp Function arenaDelete in the line
>>
>> delete this
>>
>> It also crashes when I reload the google page by pressing right click and
>> reload.
>>
>> The same release when built for x86 runs fine.
>>
>> Kindly help me in solving this issue.
>
> No idea if this is helpful or even applies to your problem, but during the
> Haiku porting effort, we found out that when using USE_SYSTEM_MALLOC=1,
> WebCore makes some assumptions about alignment of allocations that are not
> guarenteed when using malloc() (should use memalign()). When we switched to
> using the built-in TCSystemMalloc, those problems went away.

Thats interesting. How did you force TCSystemMalloc for Haiku port?

Regards,
İsmail
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Webkit mipsel crashing in arenaDelete

[Stephan Assmus]

Hi,

On 2010-02-16 at 08:50:21 [+0100], Bharathwaaj S  
wrote:
> I could port webkit to mipsel architechture using DirectFB Backend.
> 
> I've taken svn WebKitGtk release 1.1.8 present
> here
> .
> 
> I could get google.com homepage when I run GtkLauncher. But when I press any
> the Google Search button, it crashes.
> 
> I added printfs in the code and I found that it is crashing in File
> WebCore/rendering/RenderObject.cpp Function arenaDelete in the line
> 
> delete this
> 
> It also crashes when I reload the google page by pressing right click and
> reload.
> 
> The same release when built for x86 runs fine.
> 
> Kindly help me in solving this issue.

No idea if this is helpful or even applies to your problem, but during the 
Haiku porting effort, we found out that when using USE_SYSTEM_MALLOC=1, 
WebCore makes some assumptions about alignment of allocations that are not 
guarenteed when using malloc() (should use memalign()). When we switched to 
using the built-in TCSystemMalloc, those problems went away.

Also, I don't know which build system you are using, but you need to make 
sure that you compile all parts of WebKit with the same defines. Since there 
are a lot of #defines in the code which enable or disable various features, 
the object sizes will change when you compile different parts of the code 
with different #defines, which can lead to all sorts of funny crashes.

Best regards,
-Stephan


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev