[webkit-dev] New Qt buildbots

2010-04-09 Thread Gabor Rapcsanyi

Hi!
We have some stable Qt bots on http://www.sed.hu/webkit/qtbuildbot/ 
which we would like to connect to the Apple buildbot master.


The bot names are:
x86-32 Windows Qt Release   - QtWebKit release build on x86-32 
architecture
x86-32 Windows Qt Debug - QtWebKit debug build on x86-32 
architecture
x86-32 Linux Qt Release Minimal - QtWebKit release build with --minimal 
switch
ARMv7 Linux Qt Release  - QtWebKit release build on ARMv7 
architecture
ARMv5 Linux Qt Release  - QtWebKit release build on ARMv5 
architecture


These bots are stable and only build now, doesn't do any tests yet.
If you have any question about the bots we can discuss here.

Regards,
Gabor

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


Re: [webkit-dev] New Qt buildbots

2010-04-09 Thread Eric Seidel
I'm strongly in favor of more builders.

However, it would be nice if the builders on build.webkit.org's
front-page were all builders we were actually supposed to keep green.

Right now Windows, Qt and Gtk builders at build.webkit.org are red and
mostly ignored by the project.  Would these new builders be green, or
mostly ignored like the existing Qt builders?

Perhaps build.webkit.org should have a multi-page setup like how
build.chromium.org does where the main page is builders that are
expected to be green, and other pages are FYI were builders may or
may not always be green.

-eric

On Fri, Apr 9, 2010 at 12:55 AM, Gabor Rapcsanyi rga...@inf.u-szeged.hu wrote:
 Hi!
 We have some stable Qt bots on http://www.sed.hu/webkit/qtbuildbot/ which we
 would like to connect to the Apple buildbot master.

 The bot names are:
 x86-32 Windows Qt Release       - QtWebKit release build on x86-32
 architecture
 x86-32 Windows Qt Debug         - QtWebKit debug build on x86-32
 architecture
 x86-32 Linux Qt Release Minimal - QtWebKit release build with --minimal
 switch
 ARMv7 Linux Qt Release          - QtWebKit release build on ARMv7
 architecture
 ARMv5 Linux Qt Release          - QtWebKit release build on ARMv5
 architecture

 These bots are stable and only build now, doesn't do any tests yet.
 If you have any question about the bots we can discuss here.

 Regards,
 Gabor

 ___
 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] New Qt buildbots

2010-04-09 Thread Maciej Stachowiak


On Apr 9, 2010, at 1:02 AM, Eric Seidel wrote:


I'm strongly in favor of more builders.

However, it would be nice if the builders on build.webkit.org's
front-page were all builders we were actually supposed to keep green.

Right now Windows, Qt and Gtk builders at build.webkit.org are red and
mostly ignored by the project.  Would these new builders be green, or
mostly ignored like the existing Qt builders?

Perhaps build.webkit.org should have a multi-page setup like how
build.chromium.org does where the main page is builders that are
expected to be green, and other pages are FYI were builders may or
may not always be green.


I would support a multi-page setup like this.

 - Maciej



-eric

On Fri, Apr 9, 2010 at 12:55 AM, Gabor Rapcsanyi rga...@inf.u-szeged.hu 
 wrote:

Hi!
We have some stable Qt bots on http://www.sed.hu/webkit/qtbuildbot/  
which we

would like to connect to the Apple buildbot master.

The bot names are:
x86-32 Windows Qt Release   - QtWebKit release build on x86-32
architecture
x86-32 Windows Qt Debug - QtWebKit debug build on x86-32
architecture
x86-32 Linux Qt Release Minimal - QtWebKit release build with -- 
minimal

switch
ARMv7 Linux Qt Release  - QtWebKit release build on ARMv7
architecture
ARMv5 Linux Qt Release  - QtWebKit release build on ARMv5
architecture

These bots are stable and only build now, doesn't do any tests yet.
If you have any question about the bots we can discuss here.

Regards,
Gabor

___
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] Announcing WebKit2

2010-04-09 Thread Jeremy Orlow
On Fri, Apr 9, 2010 at 2:33 AM, Adam Treat tr...@kde.org wrote:

 On Thursday 08 April 2010 09:24:32 pm Darin Adler wrote:
  On Apr 8, 2010, at 6:23 PM, Adam Treat wrote:
   Can someone please point to the bug report and the forum where this
   development was discussed by the greater WebKit community?
 
  The time for that discussion is now. The forum is here.
 
  I suggest we use this mailing list, not a bug report.

 Isn't that a little cart before the horse?  It is already actively being
 landed...


I'd have to agree.  A new port is a maintenance burden on the entire
community.  Normally we discuss such things before starting to commit them.

For example, my first question is whether we can adapt the Chromium WebKit
API (or devise an API that could replace the Chromium WebKit API) since it
sounds like our goals and the goals of this new API are fairly similar.  If
we do the former, I'm sure we can talk about changing the name.  :-)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Announcing WebKit2

2010-04-09 Thread Xan Lopez
On Fri, Apr 9, 2010 at 2:47 AM, Xan Lopez x...@gnome.org wrote:
 I suppose I could wait until you land the patches and see by myself, but:

 - In the wiki you mention that one goal of the new framework is to
 provide a stable C-based API. Is this meant as a public API for
 WebKit, the same in all platforms (like JSC), or a stable internal API
 for embedders to use in order to implement their native APIs on top?
 From some lines in the wiki (like WKView wrapping native objects) it
 seems like you want to do the former, but that seems like quite a
 massive effort and the loss of an important selling port of the
 various WebKit ports.

 - Does your new framework require any significant changes in WebCore?
 Could you briefly summarize them?

 - Do you see valid usecases in the long term for the traditional
 ports or are your plans to quickly transition all code to the new
 system as soon as it's ready?


Another issue seems to be that parts of the public C API expose
CoreFoundation, which definitely would be an issue for the other
ports. I'm told on the side that this was just done as a quick
solution to have something running and that if there's interest by
other ports in using this we'd solve it with the good-old let's add
another abstraction layer method, right?

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


Re: [webkit-dev] Announcing WebKit2

2010-04-09 Thread Maciej Stachowiak


On Apr 9, 2010, at 3:36 AM, Jeremy Orlow wrote:



I hope this post clarifies why the Chromium WebKit port is not  
really a viable solution for our needs as it stands today.


It was _very_ helpful.  Thanks for taking the time to explain it so  
well.  (It might be worth moving some of that description and  
diagrams into the Wiki as well.)


Yeah, I'm trying to put some of this info in the wiki as we speak. :-)



Anyhow, I sincerely do hope that we (Chromium + Apple) can both make  
it a goal to share as much code as possible between our two  
implementations, especially in WebCore.  Maybe it'd even be useful  
and practical to upstream some Chromium code to WebKit to help  
further the WebKit2 API (and share more code)?  It'll be great to  
talk about this stuff at the meeting next week.


I hope so too! I'd love to discuss ideas along these lines, both in  
the meeting and by email.



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


Re: [webkit-dev] Announcing WebKit2

2010-04-09 Thread Zoltan Herczeg
Hi!

Your wiki says:

DrawingArea - an abstraction for a cross-process drawing area. Multiple
drawing strategies are possible, the simplest is just a shared memory
bitmap.

Could you tell me more about it? I am working on a parallel painting
feature (GraphicsContext commands can be forwarded to different threads),
and would be interested how this feature affect my work.

Zoltan


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


Re: [webkit-dev] Announcing WebKit2

2010-04-09 Thread Maciej Stachowiak


On Apr 9, 2010, at 3:40 AM, Maciej Stachowiak wrote:



On Apr 9, 2010, at 3:36 AM, Jeremy Orlow wrote:



I hope this post clarifies why the Chromium WebKit port is not  
really a viable solution for our needs as it stands today.


It was _very_ helpful.  Thanks for taking the time to explain it so  
well.  (It might be worth moving some of that description and  
diagrams into the Wiki as well.)


Yeah, I'm trying to put some of this info in the wiki as we speak. :-)


I made a bunch of updates to the wiki page:

http://trac.webkit.org/wiki/WebKit2

Regards,
Maciej

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


Re: [webkit-dev] Announcing WebKit2

2010-04-09 Thread zaheer ahmad
hi ,
why only multi-process and not multi-thread like android. It is useful for
mobile environments.

thanks,
Zaheer

On Fri, Apr 9, 2010 at 5:15 PM, Maciej Stachowiak m...@apple.com wrote:


 On Apr 9, 2010, at 3:40 AM, Maciej Stachowiak wrote:


 On Apr 9, 2010, at 3:36 AM, Jeremy Orlow wrote:


 I hope this post clarifies why the Chromium WebKit port is not really a
 viable solution for our needs as it stands today.


 It was _very_ helpful.  Thanks for taking the time to explain it so well.
  (It might be worth moving some of that description and diagrams into the
 Wiki as well.)


 Yeah, I'm trying to put some of this info in the wiki as we speak. :-)


 I made a bunch of updates to the wiki page:

 http://trac.webkit.org/wiki/WebKit2

 Regards,
 Maciej


 ___
 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] New Qt buildbots

2010-04-09 Thread Gustavo Noronha Silva
On Fri, 2010-04-09 at 01:20 -0700, Maciej Stachowiak wrote:
  Perhaps build.webkit.org should have a multi-page setup like how
  build.chromium.org does where the main page is builders that are
  expected to be green, and other pages are FYI were builders may or
  may not always be green.
 
 I would support a multi-page setup like this.

I would support that as well, given that we have 4 bots, and some of
them are difficult to keep green at all times.

Thanks,

-- 
Gustavo Noronha Silva g...@gnome.org
GNOME Project

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


Re: [webkit-dev] Announcing WebKit2

2010-04-09 Thread Hajime Morita
Hi,
It looks supporting multi-threaded model.
See WebProcessLauncher.mm for detail.

--
morita

On Fri, Apr 9, 2010 at 9:11 PM, zaheer ahmad zaheer@gmail.com wrote:
 hi ,
 why only multi-process and not multi-thread like android. It is useful for
 mobile environments.
 thanks,
 Zaheer

 On Fri, Apr 9, 2010 at 5:15 PM, Maciej Stachowiak m...@apple.com wrote:

 On Apr 9, 2010, at 3:40 AM, Maciej Stachowiak wrote:

 On Apr 9, 2010, at 3:36 AM, Jeremy Orlow wrote:

 I hope this post clarifies why the Chromium WebKit port is not really a
 viable solution for our needs as it stands today.

 It was _very_ helpful.  Thanks for taking the time to explain it so well.
  (It might be worth moving some of that description and diagrams into the
 Wiki as well.)

 Yeah, I'm trying to put some of this info in the wiki as we speak. :-)

 I made a bunch of updates to the wiki page:
 http://trac.webkit.org/wiki/WebKit2
 Regards,
 Maciej

 ___
 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





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


Re: [webkit-dev] New Qt buildbots

2010-04-09 Thread Osztrogonac Csaba

Hi,

Of course we would like to add only very stable bots to build.webkit.org .
The bots in question are two Windows builders (release and debug), one
Linux builder (release with --minimal option, which guards the #ifded
guards) and two ARM-Linux builders (ARMv5, ARMv7).

The URL that Gábor showed wasn't the best one, because you could
also see our experimental (maybe red) layout bots.

Here you can check our stable bots: http://alturl.com/jtc9

These bots have a history of several months, they are stable enough,
and green almost all the time. Flakey tests are irrelevant, because
they are only builder bots and don't run layout test.

Furthermore we agree that a multi-page setup would be more useful,
and things like console view is more scalable than waterfall.

br,
Ossy

Eric Seidel írta:

I'm strongly in favor of more builders.

However, it would be nice if the builders on build.webkit.org's
front-page were all builders we were actually supposed to keep green.

Right now Windows, Qt and Gtk builders at build.webkit.org are red and
mostly ignored by the project.  Would these new builders be green, or
mostly ignored like the existing Qt builders?

Perhaps build.webkit.org should have a multi-page setup like how
build.chromium.org does where the main page is builders that are
expected to be green, and other pages are FYI were builders may or
may not always be green.

-eric

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


Re: [webkit-dev] Announcing WebKit2

2010-04-09 Thread Adam Treat
On Friday 09 April 2010 06:24:51 am Maciej Stachowiak wrote:
 Given what proportion of overall maintenance work on WebKit I done by
 Apple, I don't think anyone is entitled to veto us adding a new API

Whaa?  Who is talking about veto of Apple's work?  Rather, I am suggesting 
that it would have been helpful if people in the broader community had a 
chance to review and discuss the patches before they were summarily landed.

To be clear, I have not had a chance to review the patches (I'm actually 
pretty excited by the ideas and I've no doubt the work is technically 
excellent given the people involved) and see what is going on before they were 
pushed into the tree.  It just would have been nice to give the *community* 
more of a heads up and a chance to have a look and offer opinions.  This isn't 
about 'Apple' and 'veto' so much as it is about a significant new piece of tech 
being added to WebKit without going through the common procedure where a bug 
is opened a patch is attached webkit-dev is notified and people have a chance 
to discuss and poke a little.

It just felt a little rushed especially so that the new stuff is being landed 
with style errors.  I normally wouldn't quibble with style issues, but others 
have and new ports have been required to fix any and all styling issues before 
landing.

 layer. I also recall that when the Chromium API layer was added, no
 one asked permission, you just let us know that it was coming. Which
 is fine - API layers are pretty low cost, and I hope no one would
 argue against a major contributor including theirs. What's more, this
 is really a parallel version of existing well-maintained API layers. I
 do not like the implication that Apple should have to ask permission
 for what we do with the WebKit API on Mac OS X. We do not ask the Qt
 or Gtk developers to explain all their API choices.

Again, I think it'd be good to get away from 'Apple' vs 'Others'.  The 
community as a whole has some fairly common procedures for landing large 
changes like this.  This just felt a bit rushed.  And no doubt I was a bit 
taken by the name 'WebKit2'.

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


Re: [webkit-dev] [webkit-changes] [57262] trunk/JavaScriptCore

2010-04-09 Thread Osztrogonac Csaba

Hi,

Alexey Proskuryakov írta:
 FIXME!  is different from FIXME:  in that Xcode doesn't recognize
 it. I'm surprised that style guide doesn't say anything about FIXME vs.
 TODO.
I wasn't aware of this, thanks for your
advice, I will use FIXME: next time.


 + // [Qt]r57240 broke Qt build (might be a gcc bug)
 + // FIXME! See: https://bugs.webkit.org/show_bug.cgi?id=37253
 But I'm not sure if a comment was even needed here - the ugliness of
 nested #ifs shouts the same.
This patch is only a workaround for buggy gcc. I added this comments,
because I want to avoid that somebody would like to optimize Qt port
and remove these guards.

Ugliness of nested #ifs is another question, I hate them as you.
It would be great if we can define it in Coding Style Guidelines.
We can found different styles for nested #ifdefs in trunk
(for example in JavaScriptCore/wtf/Platform.h(

style-I.)
#if xxx
#if yyy
...
#else
...
#endif
#endif

style-II.)
#if xxx
#if yyy
...
#else
...
#endif // yyy
#endif // xxx

style-III.)
#if xxx
#if yyy
...
#else
...
#endif // yyy
#endif // xxx

style-IV.)
#if xxx
#  if yyy
 ...
#  else
 ...
#  endif
#endif


As for me, I prefer style-III, but all reviewer ask me to modify
my patches into style-I or style-II. I think we should make
consensus which of them is the preferred coding style.

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


[webkit-dev] multi-process always [Re: Announcing WebKit2]

2010-04-09 Thread Evan Martin
On Thu, Apr 8, 2010 at 4:01 PM, Anders Carlsson ander...@apple.com wrote:
 WebKit2 is designed from the ground up to support a split process model,
 where the web content (JavaScript, HTML, layout, etc) lives in a separate
 process. This model is similar to what Google Chrome offers, with the major
 difference being that we have built the process split model directly into
 the framework, allowing other clients to use it.

One thing I'd discussed with the WebKitGtk folks in the past is
whether/where multi-process WebKit fits into apps.  An app that just
wants a quick HTML component -- say it wants to embed some known
safe/simple HTML content (consider for example the bits of the MS
Windows control panel UI that are done in HTML, or the system help
viewer) doesn't worry a lot about the stability/performance benefits
of multiproc but might care about the memory/developer overhead.
(Developer overhead for the embedder, in the sense that multiproc is
more painful to debug and code for.)

From the original announcement I could see the above description going
one of two ways:
- WebKit2 could *support* a split process model, by adding all the
callback-like hooks described, while still allowing an embedder to
implement it in a single-process way
- or WebKit2 could define and implement a split process model

The Chromium port vaguely aims at the former, though I think it falls
out more from not wanting to stuff even more Chromium-specific code in
the WebKit tree.  :)  It seems from the graphics Maciej posted that
the latter is what you're doing.  Is that correct?  Do you have any
intent to continue supporting a single process model?

(There's some compromise path between the above two, where you require
the asynchronous interface but allow embedders to just use in a
thread.  We've found this to be a bit finicky to keep working in
Chrome, and while that could be our bad engineering practices, if it's
kept on the table it certainly will require continuing engineering
effort to support.)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] multi-process always [Re: Announcing WebKit2]

2010-04-09 Thread Adam Barth
The OpenGL approach to this problem is to have two layers with the
same API.  (Sorry my diagrams aren't as awesome as Maciej's.)

Application
--- WebKit2 API ---
Multiproc client implementation
=== Process Boundary ===
Multiproc server implementation
--- WebKit2 API ---
Singleproc implementation
WebCore, etc

Notice that the WebKit2 API appears twice in this diagram.  By
layering WebKit2 over itself, you allow for easy single-process
embeddings:

Application
--- WebKit2 API ---
Singleproc implementation
WebCore, etc

This design as worked well for OpenGL over a long period of time,
including several revolutions in underlying technology (system of
components, daughter board GPUs, integrated with the CPUs).

Another benefit of this design is it separates the multiprocessing
concerns from the concerns of implementing the API because the
multiproc layer is purely concerned with proxying the API over a
process boundary.

Adam


On Fri, Apr 9, 2010 at 8:00 AM, Evan Martin e...@chromium.org wrote:
 On Thu, Apr 8, 2010 at 4:01 PM, Anders Carlsson ander...@apple.com wrote:
 WebKit2 is designed from the ground up to support a split process model,
 where the web content (JavaScript, HTML, layout, etc) lives in a separate
 process. This model is similar to what Google Chrome offers, with the major
 difference being that we have built the process split model directly into
 the framework, allowing other clients to use it.

 One thing I'd discussed with the WebKitGtk folks in the past is
 whether/where multi-process WebKit fits into apps.  An app that just
 wants a quick HTML component -- say it wants to embed some known
 safe/simple HTML content (consider for example the bits of the MS
 Windows control panel UI that are done in HTML, or the system help
 viewer) doesn't worry a lot about the stability/performance benefits
 of multiproc but might care about the memory/developer overhead.
 (Developer overhead for the embedder, in the sense that multiproc is
 more painful to debug and code for.)

 From the original announcement I could see the above description going
 one of two ways:
 - WebKit2 could *support* a split process model, by adding all the
 callback-like hooks described, while still allowing an embedder to
 implement it in a single-process way
 - or WebKit2 could define and implement a split process model

 The Chromium port vaguely aims at the former, though I think it falls
 out more from not wanting to stuff even more Chromium-specific code in
 the WebKit tree.  :)  It seems from the graphics Maciej posted that
 the latter is what you're doing.  Is that correct?  Do you have any
 intent to continue supporting a single process model?

 (There's some compromise path between the above two, where you require
 the asynchronous interface but allow embedders to just use in a
 thread.  We've found this to be a bit finicky to keep working in
 Chrome, and while that could be our bad engineering practices, if it's
 kept on the table it certainly will require continuing engineering
 effort to support.)
 ___
 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] multi-process always

2010-04-09 Thread Darin Adler
The prototype works with both a threaded model and a multiple process model, 
chosen at runtime. It seems worthwhile to keep this feature.

Anders told me he often turns on the threaded model to debug since the 
development tools we have work better with a single process and multiple 
threads than they do with multiple processes.

-- Darin

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


Re: [webkit-dev] multi-process always

2010-04-09 Thread Benbuck Nason

On 4/9/2010 9:06 AM, Darin Adler wrote:

The prototype works with both a threaded model and a multiple process model, 
chosen at runtime.


That's good to hear, because also there are some platforms where 
creating multiple user processes is not allowed.


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


Re: [webkit-dev] Announcing WebKit2

2010-04-09 Thread Geoffrey Garen
 Another issue seems to be that parts of the public C API expose
 CoreFoundation, which definitely would be an issue for the other
 ports. I'm told on the side that this was just done as a quick
 solution to have something running and that if there's interest by
 other ports in using this we'd solve it with the good-old let's add
 another abstraction layer method, right?

I had some involvement in that decision, so I'll take a crack at answering this.

We want to avoid adding, at the API layer, new abstractions for basic types 
like strings, URLRequests, URLResponses, etc -- for two reasons:

1. That would require a lot of unnecessary and error-prone typing -- both for 
WebKit implementors and for WebKit clients.

2. That would require wasting memory and CPU to make copies at API boundaries.

Hopefully, a given port can use the same port-specific types at the API layer 
as it uses inside WebCore. Our theory is that, on any given platform, those are 
the best/easiest types for the WebKit client to use, anyway.

For example, an application should be able to pass WebKit a platform-specific 
URLRequest, and WebKit should be able to pass that to WebCore in turn, and 
WebCore should be able to pass that to its networking layer in turn -- all 
without any copying or conversion code. For CF ports, that's a CFURLRequest. 
For Qt, a QNetworkRequest. Etc.

I think the right way to achieve this will be with a simple typedef, but we 
won't know for sure until more ports try to adopt this API.

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


Re: [webkit-dev] Announcing WebKit2

2010-04-09 Thread Anders Carlsson

On Apr 8, 2010, at 5:58 PM, Maciej Stachowiak wrote:

 - Does your new framework require any significant changes in WebCore?
 Could you briefly summarize them?
 
 No WebCore changes are required - it works with the existing WebCore.
 

Right now WebCore needs to be built with some different flags 
(ENABLE_EXPERIMENTAL_SINGLE_VIEW_MODE=1 
and WTF_USE_WEB_THREAD=1), but the goal is that the same WebCore should be able 
to support both WebKit and WebKit2 (and on the mac, both WebKit frameworks will 
link against the same WebCore framework).

- Anders

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


[webkit-dev] A Range question

2010-04-09 Thread Finnur Thorarinsson
Hi all,

I need a WebKit Ranger for this question:

Imagine I have the word Foo inside an edit field (input type=text
value=Foo) and the word bar outside of it, like so: [Foo]bar

If I try to create a Range of the text Foobar, the range will get collapsed.

It collapses because Range::setEnd has a |start| inside the shadow tree and
an |end| outside of it. Specifically, setEnd walks up the parent chain for
both |start| and |end| (to see if they share the same root container), but
doesn't reach the top for |start| because while walking up the parent list
it stops on a shadow node (TextControlInnerTextElement), which has only a
shadow parent.

Is this expected? Is this a bug? Is the right fix to have it walk up the
shadow parent for shadow nodes?

Best regards,
Finnur

PS. I believe this is the root cause for
https://bugs.webkit.org/show_bug.cgi?id=25868, which was a regression caused
by the fix for https://bugs.webkit.org/show_bug.cgi?id=7023.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] multi-process always [Re: Announcing WebKit2]

2010-04-09 Thread Darin Fisher
This is how we are designing the Pepper API [1] by the way.  It is designed
to be layered in order to support an optional, out-of-process
implementation.

I've always been interested in a similar model for WebKit.

-Darin

[1] https://wiki.mozilla.org/Plugins:PlatformIndependentNPAPI


On Fri, Apr 9, 2010 at 8:13 AM, Adam Barth aba...@webkit.org wrote:

 The OpenGL approach to this problem is to have two layers with the
 same API.  (Sorry my diagrams aren't as awesome as Maciej's.)

 Application
 --- WebKit2 API ---
 Multiproc client implementation
 === Process Boundary ===
 Multiproc server implementation
 --- WebKit2 API ---
 Singleproc implementation
 WebCore, etc

 Notice that the WebKit2 API appears twice in this diagram.  By
 layering WebKit2 over itself, you allow for easy single-process
 embeddings:

 Application
 --- WebKit2 API ---
 Singleproc implementation
 WebCore, etc

 This design as worked well for OpenGL over a long period of time,
 including several revolutions in underlying technology (system of
 components, daughter board GPUs, integrated with the CPUs).

 Another benefit of this design is it separates the multiprocessing
 concerns from the concerns of implementing the API because the
 multiproc layer is purely concerned with proxying the API over a
 process boundary.

 Adam


 On Fri, Apr 9, 2010 at 8:00 AM, Evan Martin e...@chromium.org wrote:
  On Thu, Apr 8, 2010 at 4:01 PM, Anders Carlsson ander...@apple.com
 wrote:
  WebKit2 is designed from the ground up to support a split process model,
  where the web content (JavaScript, HTML, layout, etc) lives in a
 separate
  process. This model is similar to what Google Chrome offers, with the
 major
  difference being that we have built the process split model directly
 into
  the framework, allowing other clients to use it.
 
  One thing I'd discussed with the WebKitGtk folks in the past is
  whether/where multi-process WebKit fits into apps.  An app that just
  wants a quick HTML component -- say it wants to embed some known
  safe/simple HTML content (consider for example the bits of the MS
  Windows control panel UI that are done in HTML, or the system help
  viewer) doesn't worry a lot about the stability/performance benefits
  of multiproc but might care about the memory/developer overhead.
  (Developer overhead for the embedder, in the sense that multiproc is
  more painful to debug and code for.)
 
  From the original announcement I could see the above description going
  one of two ways:
  - WebKit2 could *support* a split process model, by adding all the
  callback-like hooks described, while still allowing an embedder to
  implement it in a single-process way
  - or WebKit2 could define and implement a split process model
 
  The Chromium port vaguely aims at the former, though I think it falls
  out more from not wanting to stuff even more Chromium-specific code in
  the WebKit tree.  :)  It seems from the graphics Maciej posted that
  the latter is what you're doing.  Is that correct?  Do you have any
  intent to continue supporting a single process model?
 
  (There's some compromise path between the above two, where you require
  the asynchronous interface but allow embedders to just use in a
  thread.  We've found this to be a bit finicky to keep working in
  Chrome, and while that could be our bad engineering practices, if it's
  kept on the table it certainly will require continuing engineering
  effort to support.)
  ___
  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] A Range question

2010-04-09 Thread Darin Adler
On Apr 9, 2010, at 10:52 AM, Finnur Thorarinsson wrote:

 I need a WebKit Ranger for this question:
 
 Imagine I have the word Foo inside an edit field (input type=text 
 value=Foo) and the word bar outside of it, like so: [Foo]bar
 
 If I try to create a Range of the text Foobar, the range will get collapsed.
 
 It collapses because Range::setEnd has a |start| inside the shadow tree and 
 an |end| outside of it. Specifically, setEnd walks up the parent chain for 
 both |start| and |end| (to see if they share the same root container), but 
 doesn't reach the top for |start| because while walking up the parent list it 
 stops on a shadow node (TextControlInnerTextElement), which has only a shadow 
 parent.
 
 Is this expected? Is this a bug? Is the right fix to have it walk up the 
 shadow parent for shadow nodes?
 
 Best regards,
 Finnur
 
 PS. I believe this is the root cause for 
 https://bugs.webkit.org/show_bug.cgi?id=25868, which was a regression caused 
 by the fix for https://bugs.webkit.org/show_bug.cgi?id=7023.

It’s expected behavior.

A selection needs to be either entirely inside an edit field, or outside the 
edit field. We don’t support selections that start partway through an edit 
field and then continue out to the outside document.

From the DOM API’s point of view, selections inside an edit field aren’t 
really selections at all. The DOM nodes within the shadow DOM tree should 
never be exposed to JavaScript in a webpage.

The find code in markAllMatchesForText needs to not consider matches that cross 
the boundary between the inside of an edit field and the rest of the document.

-- Darin

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


Re: [webkit-dev] A Range question

2010-04-09 Thread Finnur Thorarinsson
Thanks for a super quick response Darin. One followup question:

 The find code in markAllMatchesForText needs to not consider matches that
cross the boundary between the inside of an edit field and the rest of the
document.

Fair enough. I can see why it should ignore those matches, but if you look
at the details for the bug (https://bugs.webkit.org/show_bug.cgi?id=25868)
it states that the markAllMatchesForText function not only ignores the match
but it also stops looking for more matches...

I assume that's not expected?


On Fri, Apr 9, 2010 at 10:58, Darin Adler da...@apple.com wrote:

 On Apr 9, 2010, at 10:52 AM, Finnur Thorarinsson wrote:

  I need a WebKit Ranger for this question:
 
  Imagine I have the word Foo inside an edit field (input type=text
 value=Foo) and the word bar outside of it, like so: [Foo]bar
 
  If I try to create a Range of the text Foobar, the range will get
 collapsed.
 
  It collapses because Range::setEnd has a |start| inside the shadow tree
 and an |end| outside of it. Specifically, setEnd walks up the parent chain
 for both |start| and |end| (to see if they share the same root container),
 but doesn't reach the top for |start| because while walking up the parent
 list it stops on a shadow node (TextControlInnerTextElement), which has only
 a shadow parent.
 
  Is this expected? Is this a bug? Is the right fix to have it walk up the
 shadow parent for shadow nodes?
 
  Best regards,
  Finnur
 
  PS. I believe this is the root cause for
 https://bugs.webkit.org/show_bug.cgi?id=25868, which was a regression
 caused by the fix for https://bugs.webkit.org/show_bug.cgi?id=7023.

 It’s expected behavior.

 A selection needs to be either entirely inside an edit field, or outside
 the edit field. We don’t support selections that start partway through an
 edit field and then continue out to the outside document.

 From the DOM API’s point of view, selections inside an edit field aren’t
 really selections at all. The DOM nodes within the shadow DOM tree should
 never be exposed to JavaScript in a webpage.

 The find code in markAllMatchesForText needs to not consider matches that
 cross the boundary between the inside of an edit field and the rest of the
 document.

-- Darin


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


Re: [webkit-dev] A Range question

2010-04-09 Thread Darin Adler
On Apr 9, 2010, at 11:06 AM, Finnur Thorarinsson wrote:

 Fair enough. I can see why it should ignore those matches, but if you look at 
 the details for the bug (https://bugs.webkit.org/show_bug.cgi?id=25868) it 
 states that the markAllMatchesForText function not only ignores the match but 
 it also stops looking for more matches...
 
 I assume that's not expected?

Yes, right. The code needs to be corrected so it keeps looking.

-- Darin

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


Re: [webkit-dev] A Range question

2010-04-09 Thread Finnur Thorarinsson
Excellent.

If anyone has good ideas on how to improve it, I'm willing to come up with a
patch, test it in my tree and submit it for review...

On Fri, Apr 9, 2010 at 11:07, Darin Adler da...@apple.com wrote:

 On Apr 9, 2010, at 11:06 AM, Finnur Thorarinsson wrote:

  Fair enough. I can see why it should ignore those matches, but if you
 look at the details for the bug (
 https://bugs.webkit.org/show_bug.cgi?id=25868) it states that the
 markAllMatchesForText function not only ignores the match but it also stops
 looking for more matches...
 
  I assume that's not expected?

 Yes, right. The code needs to be corrected so it keeps looking.

-- Darin


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


Re: [webkit-dev] Announcing WebKit2

2010-04-09 Thread Maciej Stachowiak


On Apr 9, 2010, at 7:14 AM, Adam Treat wrote:


On Friday 09 April 2010 06:24:51 am Maciej Stachowiak wrote:

Given what proportion of overall maintenance work on WebKit I done by
Apple, I don't think anyone is entitled to veto us adding a new API


Whaa?  Who is talking about veto of Apple's work?  Rather, I am  
suggesting
that it would have been helpful if people in the broader community  
had a
chance to review and discuss the patches before they were summarily  
landed.


To be clear, I have not had a chance to review the patches (I'm  
actually

pretty excited by the ideas and I've no doubt the work is technically
excellent given the people involved) and see what is going on before  
they were
pushed into the tree.  It just would have been nice to give the  
*community*
more of a heads up and a chance to have a look and offer opinions.   
This isn't
about 'Apple' and 'veto' so much as it is about a significant new  
piece of tech
being added to WebKit without going through the common procedure  
where a bug
is opened a patch is attached webkit-dev is notified and people have  
a chance

to discuss and poke a little.


There were in fact bugs opened with patches attached, and webkit-dev  
was notified before any of the patches were committed afaik. However,  
the new piece of tech really is just a new API layer for the Mac and  
Win ports. We are interested in other people being able to reuse this  
technology, but fundamentally, this is an extension of our existing  
APIs.


It just felt a little rushed especially so that the new stuff is  
being landed
with style errors.  I normally wouldn't quibble with style issues,  
but others
have and new ports have been required to fix any and all styling  
issues before

landing.


Agree, it was not good to commit with style errors and we should try  
to fix them promptly.





layer. I also recall that when the Chromium API layer was added, no
one asked permission, you just let us know that it was coming. Which
is fine - API layers are pretty low cost, and I hope no one would
argue against a major contributor including theirs. What's more, this
is really a parallel version of existing well-maintained API  
layers. I

do not like the implication that Apple should have to ask permission
for what we do with the WebKit API on Mac OS X. We do not ask the Qt
or Gtk developers to explain all their API choices.


Again, I think it'd be good to get away from 'Apple' vs 'Others'.  The
community as a whole has some fairly common procedures for landing  
large
changes like this.  This just felt a bit rushed.  And no doubt I was  
a bit

taken by the name 'WebKit2'.


It was in retrospect not a good choice of name. We hoped it would be a  
very boring choice. Think of it as WebKit/mac/async/ or something and  
see if you might feel differently.


Regards,
Maciej


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


[webkit-dev] Get src and element from render object in dump tree

2010-04-09 Thread rikutse

Dear everyone,
I am new to study Webkit. In short, I used dump render tree for Google
page: http://www.google.com :
layer at (0,0) size 800x600
  RenderView at (0,0) size 800x600
layer at (0,0) size 800x371
  RenderBlock {HTML} at (0,0) size 800x371
RenderBody {BODY} at (8,3) size 784x352 [bgcolor=#FF]
  RenderBlock {DIV} at (0,0) size 784x24
RenderBlock (floating) {DIV} at (0,0) size 377x23
  RenderInline {NOBR} at (0,0) size 377x16
RenderInline {B} at (0,0) size 29x16
  RenderText {#text} at (0,1) size 29x16
text run at (0,1) width 29: Web
RenderText {#text} at (35,1) size 4x16
  text run at (35,1) width 4:  
RenderInline {A} at (0,0) size 42x16 [color=#CC]
  RenderText {#text} at (39,1) size 42x16
text run at (39,1) width 42: Images
RenderText {#text} at (87,1) size 4x16
  text run at (87,1) width 4:  
RenderInline {A} at (0,0) size 40x16 [color=#CC]
  RenderText {#text} at (91,1) size 40x16
text run at (91,1) width 40: Videos
RenderText {#text} at (137,1) size 4x16
  text run at (137,1) width 4:  
RenderInline {A} at (0,0) size 32x16 [color=#CC]
  RenderText {#text} at (141,1) size 32x16
text run at (141,1) width 32: Maps
RenderText {#text} at (179,1) size 4x16
  text run at (179,1) width 4:  
RenderInline {A} at (0,0) size 32x16 [color=#CC]
  RenderText {#text} at (183,1) size 32x16
text run at (183,1) width 32: News
RenderText {#text} at (221,1) size 4x16
  text run at (221,1) width 4:  
RenderInline {A} at (0,0) size 54x16 [color=#CC]
  RenderText {#text} at (225,1) size 54x16
text run at (225,1) width 54: Shopping
RenderText {#text} at (285,1) size 4x16
  text run at (285,1) width 4:  
RenderInline {A} at (0,0) size 34x16 [color=#CC]
  RenderText {#text} at (289,1) size 34x16
text run at (289,1) width 34: Gmail
RenderText {#text} at (329,1) size 4x16
  text run at (329,1) width 4:  
RenderInline {A} at (0,0) size 44x16 [color=#CC]
  RenderInline {U} at (0,0) size 29x16
RenderText {#text} at (333,1) size 29x16
  text run at (333,1) width 29: more
  RenderText {#text} at (362,1) size 4x16
text run at (362,1) width 4:  
  RenderInline {SMALL} at (0,0) size 11x14
RenderText {#text} at (366,3) size 11x14
  text run at (366,3) width 11: \x{25BC}
RenderBlock {DIV} at (0,0) size 784x24
  RenderInline {NOBR} at (0,0) size 197x16
RenderInline {SPAN} at (0,0) size 0x0
RenderInline {SPAN} at (0,0) size 0x0
RenderInline {SPAN} at (0,0) size 55x16
  RenderInline {A} at (0,0) size 44x16 [color=#CC]
RenderText {#text} at (587,1) size 44x16
  text run at (587,1) width 44: iGoogle
  RenderText {#text} at (631,1) size 11x16
text run at (631,1) width 11:  | 
RenderInline {A} at (0,0) size 91x16 [color=#CC]
  RenderText {#text} at (642,1) size 91x16
text run at (642,1) width 91: Search settings
RenderText {#text} at (733,1) size 11x16
  text run at (733,1) width 11:  | 
RenderInline {A} at (0,0) size 40x16 [color=#CC]
  RenderText {#text} at (744,1) size 40x16
text run at (744,1) width 40: Sign in
  RenderBlock {CENTER} at (0,24) size 784x328
RenderBlock (anonymous) at (0,0) size 784x152
  RenderBR {BR} at (392,0) size 0x18
  RenderImage {IMG} at (254,19) size 276x110
  RenderBR {BR} at (530,114) size 0x18
  RenderBR {BR} at (392,133) size 0x18
RenderBlock {FORM} at (0,152) size 784x64
  RenderTable {TABLE} at (0,0) size 784x64
RenderTableSection {TBODY} at (0,0) size 784x64
  RenderTableRow {TR} at (0,0) size 784x64
RenderTableCell {TD} at (0,0) size 134x12 [r=0 c=0 rs=1
cs=1]
  RenderText {#text} at (0,-3) size 4x18
text run at (0,-3) width 4:  
RenderTableCell {TD} at (134,0) size 487x64 [r=0 c=1 rs=1
cs=1]
  RenderTextControl {INPUT} at (2,2) size 483x26
[bgcolor=#FF] [border: (2px inset #00)]
  RenderBR {BR} at (487,16) size 0x18
  RenderButton {INPUT} at (112,34) size 121x27 [border: (1px
solid #99)]
RenderBlock (anonymous) at (9,4) size 103x19
  RenderText at (3,1) size 97x17
text 

Re: [webkit-dev] Announcing WebKit2

2010-04-09 Thread Geoffrey Garen
 I think the right way to achieve this will be with a simple typedef, but we 
 won't know for sure until more ports try to adopt this API.

Looks like Sam went with a slightly different solution: 
https://bugs.webkit.org/show_bug.cgi?id=37347.

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


Re: [webkit-dev] Announcing WebKit2

2010-04-09 Thread Cameron Zwarich
On Apr 9, 2010, at 2:34 AM, Jeremy Orlow wrote:

 On Fri, Apr 9, 2010 at 2:33 AM, Adam Treat tr...@kde.org wrote:
 On Thursday 08 April 2010 09:24:32 pm Darin Adler wrote:
  On Apr 8, 2010, at 6:23 PM, Adam Treat wrote:
   Can someone please point to the bug report and the forum where this
   development was discussed by the greater WebKit community?
 
  The time for that discussion is now. The forum is here.
 
  I suggest we use this mailing list, not a bug report.
 
 Isn't that a little cart before the horse?  It is already actively being
 landed...
 
 I'd have to agree.  A new port is a maintenance burden on the entire 
 community.  Normally we discuss such things before starting to commit them.

We seem to welcome pretty much any port that has an active maintainer.

In the past we have accepted the Chromium port despite it having a new JS 
engine, new DOM bindings, an overreaching catch-all #ifdef for unrelated 
changes, numerous layering violations, and seemingly unnecessary changes or 
replacements of platform-independent code. All of these problems were discussed 
on webkit-dev and in Bugzilla prior to Chromium landing, but they were largely 
ignored and still exist today.

 For example, my first question is whether we can adapt the Chromium WebKit 
 API (or devise an API that could replace the Chromium WebKit API) since it 
 sounds like our goals and the goals of this new API are fairly similar.  If 
 we do the former, I'm sure we can talk about changing the name.  :-)

As it stands, there is no way for a WebKit port to opt in to Chromium's 
multiprocess model, and making this possible has never been a priority for the 
Chromium team. WebKit 2 looks a lot cleaner in this respect.

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


Re: [webkit-dev] Announcing WebKit2

2010-04-09 Thread Adam Barth
On Fri, Apr 9, 2010 at 1:53 PM, Cameron Zwarich cwzwar...@webkit.org wrote:
 We seem to welcome pretty much any port that has an active maintainer.

IMHO, that's a good thing.  I wonder if we should archive ports that
don't have an active maintainer (e.g., by moving them into a branch).

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


Re: [webkit-dev] Announcing WebKit2

2010-04-09 Thread Kenneth Christiansen
Which ports are considered unmaintained?

Kenneth

On Fri, Apr 9, 2010 at 6:03 PM, Adam Barth aba...@webkit.org wrote:
 On Fri, Apr 9, 2010 at 1:53 PM, Cameron Zwarich cwzwar...@webkit.org wrote:
 We seem to welcome pretty much any port that has an active maintainer.

 IMHO, that's a good thing.  I wonder if we should archive ports that
 don't have an active maintainer (e.g., by moving them into a branch).

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




-- 
Kenneth Rohde Christiansen
Technical Lead / Senior Software Engineer
Qt Labs Americas, Nokia Technology Institute, INdT
Phone  +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Announcing WebKit2

2010-04-09 Thread Maciej Stachowiak


On Apr 9, 2010, at 2:03 PM, Adam Barth wrote:

On Fri, Apr 9, 2010 at 1:53 PM, Cameron Zwarich  
cwzwar...@webkit.org wrote:
We seem to welcome pretty much any port that has an active  
maintainer.


IMHO, that's a good thing.  I wonder if we should archive ports that
don't have an active maintainer (e.g., by moving them into a branch).


I think that would be good, if there are any such ports (I am not sure  
there are any on trunk currently that are totally unmaintained).


Regards,
Maciej

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


Re: [webkit-dev] Announcing WebKit2

2010-04-09 Thread Oliver Hunt
On Apr 9, 2010, at 2:09 PM, Maciej Stachowiak wrote:

 
 On Apr 9, 2010, at 2:03 PM, Adam Barth wrote:
 
 On Fri, Apr 9, 2010 at 1:53 PM, Cameron Zwarich cwzwar...@webkit.org wrote:
 We seem to welcome pretty much any port that has an active maintainer.
 
 IMHO, that's a good thing.  I wonder if we should archive ports that
 don't have an active maintainer (e.g., by moving them into a branch).
 
 I think that would be good, if there are any such ports (I am not sure there 
 are any on trunk currently that are totally unmaintained).

S60? http://trac.webkit.org/browser/S60

--Oliver

 
 Regards,
 Maciej
 
 ___
 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] Announcing WebKit2

2010-04-09 Thread Adam Treat
On Friday 09 April 2010 02:11:33 pm Maciej Stachowiak wrote:
 There were in fact bugs opened with patches attached, and webkit-dev
 was notified before any of the patches were committed afaik. However,

Indeed, but the post to webkit-dev had no link to the patches and no time was 
given for anyone in the community who hadn't been privy to the private 
development to have a look before it was landed.

 the new piece of tech really is just a new API layer for the Mac and
 Win ports. We are interested in other people being able to reuse this
 technology, but fundamentally, this is an extension of our existing
 APIs.

I understand this now.  I definitely didn't get this impression at first, but 
probably my mistake.

 It was in retrospect not a good choice of name. We hoped it would be a
 very boring choice. Think of it as WebKit/mac/async/ or something and
 see if you might feel differently.

It does throw things in a different light.  However, I still think it would 
have been nice to give people an opportunity to have a look and a little time 
for discussion before it was landed.  I lament that we have so much private 
development in the community although I understand the necessity at times.

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


Re: [webkit-dev] Announcing WebKit2

2010-04-09 Thread Adam Treat
On Friday 09 April 2010 04:53:31 pm Cameron Zwarich wrote:
 In the past we have accepted the Chromium port despite it having a new JS
 engine, new DOM bindings, an overreaching catch-all #ifdef for unrelated
 changes, numerous layering violations, and seemingly unnecessary changes
 or replacements of platform-independent code. All of these problems were
 discussed on webkit-dev and in Bugzilla prior to Chromium landing, but
 they were largely ignored and still exist today.

In the past we've also had new ports land with some fairly hefty requirements 
including fixing of all style violations, layering violations, and generally 
going through the code with a fine tooth comb.  Were that all ports and 
contributions received the same treatment.

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


[webkit-dev] Archiving the Haiku port? (was WebKit2 and all that jazz)

2010-04-09 Thread Adam Barth
Is the Haiku port actively maintained?

http://trac.webkit.org/browser/trunk/WebKit/haiku/

Looking at the ChangeLog, I don't see any real activity:

http://trac.webkit.org/browser/trunk/WebKit/haiku/ChangeLog

Maybe we should archive it?  I certainly don't want to exclude Haiku
from the community.  Ideally, we'd make it easy to unarchive it if
folks appear who want to work on it again.

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


Re: [webkit-dev] Archiving the Haiku port? (was WebKit2 and all that jazz)

2010-04-09 Thread Eric Seidel
SVN already is an archive.  Were we to archive a port, we would just
remove the ifdefs and associated files.  We already have scripts for
doing this (buried in bugzilla, or in WebKitTools/Scripts).

-eric

On Fri, Apr 9, 2010 at 2:26 PM, Adam Barth aba...@webkit.org wrote:
 Is the Haiku port actively maintained?

 http://trac.webkit.org/browser/trunk/WebKit/haiku/

 Looking at the ChangeLog, I don't see any real activity:

 http://trac.webkit.org/browser/trunk/WebKit/haiku/ChangeLog

 Maybe we should archive it?  I certainly don't want to exclude Haiku
 from the community.  Ideally, we'd make it easy to unarchive it if
 folks appear who want to work on it again.

 Adam
 ___
 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] Announcing WebKit2

2010-04-09 Thread Darin Fisher
On Fri, Apr 9, 2010 at 2:36 PM, Darin Fisher da...@chromium.org wrote:

 On Fri, Apr 9, 2010 at 1:53 PM, Cameron Zwarich cwzwar...@webkit.orgwrote:

 On Apr 9, 2010, at 2:34 AM, Jeremy Orlow wrote:

 On Fri, Apr 9, 2010 at 2:33 AM, Adam Treat tr...@kde.org wrote:

 On Thursday 08 April 2010 09:24:32 pm Darin Adler wrote:
  On Apr 8, 2010, at 6:23 PM, Adam Treat wrote:
   Can someone please point to the bug report and the forum where this
   development was discussed by the greater WebKit community?
 
  The time for that discussion is now. The forum is here.
 
  I suggest we use this mailing list, not a bug report.

 Isn't that a little cart before the horse?  It is already actively being
 landed...


 I'd have to agree.  A new port is a maintenance burden on the entire
 community.  Normally we discuss such things before starting to commit them.


 We seem to welcome pretty much any port that has an active maintainer.

 In the past we have accepted the Chromium port despite it having a new JS
 engine, new DOM bindings, an overreaching catch-all #ifdef for unrelated
 changes, numerous layering violations, and seemingly unnecessary changes or
 replacements of platform-independent code. All of these problems were
 discussed on webkit-dev and in Bugzilla prior to Chromium landing, but they
 were largely ignored and still exist today.


 Perhaps we should discuss some of these problems that you perceive to still
 exist with the Chromium port at the WebKit conference.  I'd like to
 understand better.

 I have heard/read some arguments in favor of breaking PLATFORM(CHROMIUM) up
 into separate defines, and that all sounds conceptually reasonable, but
 there hasn't been much of a need to do so since there have been no other
 ports interested in sharing portions of what is currently behind
 PLATFORM(CHROMIUM).  Perhaps we're at a point now, because of WebKit2, in
 which we would benefit from sharing code that is presently behind
 PLATFORM(CHROMIUM)?

 Regards,
 -Darin


For example, Sam mentioned that WebKit2 might want to use the
BackForwardListClient that we added for the Chromium port.  It seems like a
trivial change to invent an ENABLE option for that so that it can be shared.
 Are there more examples?

-Darin





  For example, my first question is whether we can adapt the Chromium
 WebKit API (or devise an API that could replace the Chromium WebKit API)
 since it sounds like our goals and the goals of this new API are fairly
 similar.  If we do the former, I'm sure we can talk about changing the name.
  :-)


 As it stands, there is no way for a WebKit port to opt in to Chromium's
 multiprocess model, and making this possible has never been a priority for
 the Chromium team. WebKit 2 looks a lot cleaner in this respect.

 Cameron

 ___
 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] Get src and element from render object in dump tree

2010-04-09 Thread rikutse

Is my question too stupid?



rikutse wrote:
 
 Dear everyone,
 I am new to study Webkit. In short, I used dump render tree for Google
 page: http://www.google.com :
 layer at (0,0) size 800x600
   RenderView at (0,0) size 800x600
 layer at (0,0) size 800x371
   RenderBlock {HTML} at (0,0) size 800x371
 RenderBody {BODY} at (8,3) size 784x352 [bgcolor=#FF]
   RenderBlock {DIV} at (0,0) size 784x24
 RenderBlock (floating) {DIV} at (0,0) size 377x23
   RenderInline {NOBR} at (0,0) size 377x16
 RenderInline {B} at (0,0) size 29x16
   RenderText {#text} at (0,1) size 29x16
 text run at (0,1) width 29: Web
 RenderText {#text} at (35,1) size 4x16
   text run at (35,1) width 4:  
 RenderInline {A} at (0,0) size 42x16 [color=#CC]
   RenderText {#text} at (39,1) size 42x16
 text run at (39,1) width 42: Images
 RenderText {#text} at (87,1) size 4x16
   text run at (87,1) width 4:  
 RenderInline {A} at (0,0) size 40x16 [color=#CC]
   RenderText {#text} at (91,1) size 40x16
 text run at (91,1) width 40: Videos
 RenderText {#text} at (137,1) size 4x16
   text run at (137,1) width 4:  
 RenderInline {A} at (0,0) size 32x16 [color=#CC]
   RenderText {#text} at (141,1) size 32x16
 text run at (141,1) width 32: Maps
 RenderText {#text} at (179,1) size 4x16
   text run at (179,1) width 4:  
 RenderInline {A} at (0,0) size 32x16 [color=#CC]
   RenderText {#text} at (183,1) size 32x16
 text run at (183,1) width 32: News
 RenderText {#text} at (221,1) size 4x16
   text run at (221,1) width 4:  
 RenderInline {A} at (0,0) size 54x16 [color=#CC]
   RenderText {#text} at (225,1) size 54x16
 text run at (225,1) width 54: Shopping
 RenderText {#text} at (285,1) size 4x16
   text run at (285,1) width 4:  
 RenderInline {A} at (0,0) size 34x16 [color=#CC]
   RenderText {#text} at (289,1) size 34x16
 text run at (289,1) width 34: Gmail
 RenderText {#text} at (329,1) size 4x16
   text run at (329,1) width 4:  
 RenderInline {A} at (0,0) size 44x16 [color=#CC]
   RenderInline {U} at (0,0) size 29x16
 RenderText {#text} at (333,1) size 29x16
   text run at (333,1) width 29: more
   RenderText {#text} at (362,1) size 4x16
 text run at (362,1) width 4:  
   RenderInline {SMALL} at (0,0) size 11x14
 RenderText {#text} at (366,3) size 11x14
   text run at (366,3) width 11: \x{25BC}
 RenderBlock {DIV} at (0,0) size 784x24
   RenderInline {NOBR} at (0,0) size 197x16
 RenderInline {SPAN} at (0,0) size 0x0
 RenderInline {SPAN} at (0,0) size 0x0
 RenderInline {SPAN} at (0,0) size 55x16
   RenderInline {A} at (0,0) size 44x16 [color=#CC]
 RenderText {#text} at (587,1) size 44x16
   text run at (587,1) width 44: iGoogle
   RenderText {#text} at (631,1) size 11x16
 text run at (631,1) width 11:  | 
 RenderInline {A} at (0,0) size 91x16 [color=#CC]
   RenderText {#text} at (642,1) size 91x16
 text run at (642,1) width 91: Search settings
 RenderText {#text} at (733,1) size 11x16
   text run at (733,1) width 11:  | 
 RenderInline {A} at (0,0) size 40x16 [color=#CC]
   RenderText {#text} at (744,1) size 40x16
 text run at (744,1) width 40: Sign in
   RenderBlock {CENTER} at (0,24) size 784x328
 RenderBlock (anonymous) at (0,0) size 784x152
   RenderBR {BR} at (392,0) size 0x18
   RenderImage {IMG} at (254,19) size 276x110
   RenderBR {BR} at (530,114) size 0x18
   RenderBR {BR} at (392,133) size 0x18
 RenderBlock {FORM} at (0,152) size 784x64
   RenderTable {TABLE} at (0,0) size 784x64
 RenderTableSection {TBODY} at (0,0) size 784x64
   RenderTableRow {TR} at (0,0) size 784x64
 RenderTableCell {TD} at (0,0) size 134x12 [r=0 c=0 rs=1
 cs=1]
   RenderText {#text} at (0,-3) size 4x18
 text run at (0,-3) width 4:  
 RenderTableCell {TD} at (134,0) size 487x64 [r=0 c=1 rs=1
 cs=1]
   RenderTextControl {INPUT} at (2,2) size 483x26
 [bgcolor=#FF] [border: (2px inset #00)]
   RenderBR {BR} at (487,16) size 0x18
   RenderButton {INPUT} at (112,34) size 121x27 [border:
 (1px solid #99)]
  

Re: [webkit-dev] Archiving the Haiku port? (was WebKit2 and all that jazz)

2010-04-09 Thread Kenneth Christiansen
Last I looked there are still patches up for review for Haiku. It
would be nice to know why it is not being maintained. Is that due to
having no interest from their community or due to the fact that noone
are reviewing the patches?

Kenneth

On Fri, Apr 9, 2010 at 6:26 PM, Adam Barth aba...@webkit.org wrote:
 Is the Haiku port actively maintained?

 http://trac.webkit.org/browser/trunk/WebKit/haiku/

 Looking at the ChangeLog, I don't see any real activity:

 http://trac.webkit.org/browser/trunk/WebKit/haiku/ChangeLog

 Maybe we should archive it?  I certainly don't want to exclude Haiku
 from the community.  Ideally, we'd make it easy to unarchive it if
 folks appear who want to work on it again.

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




-- 
Kenneth Rohde Christiansen
Technical Lead / Senior Software Engineer
Qt Labs Americas, Nokia Technology Institute, INdT
Phone  +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Archiving the Haiku port? (was WebKit2 and all that jazz)

2010-04-09 Thread Stephan Assmus
- Ursprüngliche Nachricht -
Von: Kenneth Christiansen
Gesendet: 09.04.10 23:52 Uhr
An: Adam Barth
Betreff: Re: [webkit-dev] Archiving the Haiku port? (was WebKit2 and all that 
jazz)

Last I looked there are still patches up for review for Haiku. It
would be nice to know why it is not being maintained. Is that due to
having no interest from their community or due to the fact that noone
are reviewing the patches?

Some people do review the patches, but the initial reviews appear usually days 
after I submitted a patch and sometimes there is no reaction after I update the 
patch or explain things. It is totally understandable... I don't mean to 
complain about reviewers, they are probably overwhelmed in work. However, this 
has resulted in me being reluctant about posting new patches. I would have a 
lot more patches in the pipe, but very few patches that would be about 20K or 
less. It has been expressed very clearly to me that only small patches are 
prefered. However, I have completely redesigned the Haiku WebKit API, 
implemented a great deal more code to expose additional WebCore features, done 
a lot of changes to the GraphicsContext implementation... I am under the 
impression that I would have to somehow fake individual changes to the files to 
somehow extract smaller patches. Like revert to the original file, add code 
back piece by piece while creating patches to keep them small. You can imagine 
it's a lot of additional work and overhead. I hope you guys understand that 
I've been reluctant to even try to get this stuff commited with how the review 
process went for me so far. However, I am willing to give it a try once more, 
if there are people interested in reviewing my patches and to keep the Haiku 
port going. It is certainly actively maintained.

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


Re: [webkit-dev] Archiving the Haiku port? (was WebKit2 and all that jazz)

2010-04-09 Thread Stephan Assmus
 - Ursprüngliche Nachricht -
 Von: Adam Barth
 Gesendet: 09.04.10 23:26 Uhr
 An: webkit-dev@lists.webkit.org
 Betreff: [webkit-dev] Archiving the Haiku port? (was WebKit2 and all that 
 jazz)
 
 Is the Haiku port actively maintained?
 
 http://trac.webkit.org/browser/trunk/WebKit/haiku/
 
 Looking at the ChangeLog, I don't see any real activity:
 
 http://trac.webkit.org/browser/trunk/WebKit/haiku/ChangeLog
 
 Maybe we should archive it? I certainly don't want to exclude Haiku
 from the community. Ideally, we'd make it easy to unarchive it if
 folks appear who want to work on it again.

I am actively working on the Haiku port. I have submitted a number of patches, 
but since the review process takes _very_ long (no offense intended) I am 
careful to only submit patches when I don't anticipate changes to the files in 
the near future. A few of my patches still just sit there in bugzilla. Some got 
reviewed, the last activity was on a patch to ImageBufferHaiku.cpp, where the 
reviewer gave an r- because I removed the original copyright. Myself and Maxime 
Simone (original copyright holder) explained the issue and why it was correct 
to remove it. However, no response from the reviewer since then.

I have a *huge* number of additional patches, since I am writing a WebKit 
browser for Haiku, completing the port, the Haiku WebKit API and the browser. 
Many of the patches would simply not be small, and to be frank, the review 
process has so far discouraged me from even trying to submit any of the bigger 
stuff. Especially the stuff I am working on all the time.

I can certainly prepare updated patches and new patches in the next days, but 
it takes careful preparation and if those patches just sit there in bugzilla 
and receive no further feedback after initial review... it is just not 
motivating if the initial review came after about 10 days in the first place.

The problem is of course that there are no dedicated Haiku reviewers. Other 
ports have their own number of reviewers and people interested in getting 
patches for their ports landed. With Haiku it's a chicken and egg problem. As 
long as I don't get a significant amount of patches landed, I won't even become 
committer.

I don't really know what a solution could be. The Haiku port touches no other 
code, it's pretty self-contained. In that respect the chances are very low to 
affect other ports/people. I don't know if that could be an argument for just 
rubber stamping a lot of patches until the Haiku code in the official repo 
includes most of my stuff. What do you guys think? IMHO, the problem with the 
Haiku port is certainly not that it is not actively maintained, I work many 
hours on it each day, the problem is how to get the patches into SVN smoothly.

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


Re: [webkit-dev] Announcing WebKit2

2010-04-09 Thread Maciej Stachowiak


On Apr 9, 2010, at 2:13 PM, Adam Treat wrote:


On Friday 09 April 2010 02:11:33 pm Maciej Stachowiak wrote:


the new piece of tech really is just a new API layer for the Mac  
and

Win ports. We are interested in other people being able to reuse this
technology, but fundamentally, this is an extension of our existing
APIs.


I understand this now.  I definitely didn't get this impression at  
first, but

probably my mistake.


I think it was initially our mistake in communicating poorly. I  
apologize for that, we could have done a better job of making the  
scope of the work clear. We also didn't have to rush quite so much to  
commit the patches - we were just eager to share this code for broader  
review and input quicly.




It was in retrospect not a good choice of name. We hoped it would  
be a

very boring choice. Think of it as WebKit/mac/async/ or something and
see if you might feel differently.


It does throw things in a different light.  However, I still think  
it would
have been nice to give people an opportunity to have a look and a  
little time
for discussion before it was landed.  I lament that we have so much  
private
development in the community although I understand the necessity at  
times.


Really our goal here was to have something sufficiently working that  
it was worth showing. This project is in no way locked in or  
imminently shipping - it is an early technology preview. We would  
*love* to have feedback from you and other community members. Even  
though the driving force is to be a new API layer for Apple's ports,  
we are very interested in making the code useful for other ports if  
they are interested. One thing we're looking at is how to make the API  
more agnostic about basic types like strings, since at least some Gtk  
folks have expressed interest in the basic technology.


Regards,
Maciej

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


Re: [webkit-dev] Archiving the Haiku port? (was WebKit2 and all that jazz)

2010-04-09 Thread Adam Barth
Woah, ok.  It seems there is still significant interest in the Haiku
port.  No offense intended.

Adam


On Fri, Apr 9, 2010 at 3:09 PM, Stephan Assmus supersti...@gmx.de wrote:
 - Ursprüngliche Nachricht -
 Von: Adam Barth
 Gesendet: 09.04.10 23:26 Uhr

 An: webkit-...@lists.webkit.org
 Betreff: [webkit-dev] Archiving the Haiku port? (was WebKit2 and all that jazz)

 Is the Haiku port actively maintained?

 http://trac.webkit.org/browser/trunk/WebKit/haiku/

 Looking at the ChangeLog, I don't see any real activity:

 http://trac.webkit.org/browser/trunk/WebKit/haiku/ChangeLog

 Maybe we should archive it? I certainly don't want to exclude Haiku
 from the community. Ideally, we'd make it easy to unarchive it if
 folks appear who want to work on it again.

 I am actively working on the Haiku port. I have submitted a number of patches, but since the review process takes _very_ long (no offense intended) I am careful to only submit patches when I don't anticipate changes to the files in the near future. A few of my patches still just sit there in bugzilla. Some got reviewed, the last activity was on a patch to ImageBufferHaiku.cpp, where the reviewer gave an r- because I removed the original copyright. Myself and Maxime Simone (original copyright holder) explained the issue and why it was correct to remove it. However, no response from the reviewer since then.

 I have a *huge* number of additional patches, since I am writing a WebKit browser for Haiku, completing the port, the Haiku WebKit API and the browser. Many of the patches would simply not be small, and to be frank, the review process has so far discouraged me from even trying to submit any of the bigger stuff. Especially the stuff I am working on all the time.

 I can certainly prepare updated patches and new patches in the next days, but it takes careful preparation and if those patches just sit there in bugzilla and receive no further feedback after initial review... it is just not motivating if the initial review came after about 10 days in the first place.

 The problem is of course that there are no dedicated Haiku reviewers. Other ports have their own number of reviewers and people interested in getting patches for their ports landed. With Haiku it's a chicken and egg problem. As long as I don't get a significant amount of patches landed, I won't even become committer.

 I don't really know what a solution could be. The Haiku port touches no other code, it's pretty self-contained. In that respect the chances are very low to affect other ports/people. I don't know if that could be an argument for just rubber stamping a lot of patches until the Haiku code in the official repo includes most of my stuff. What do you guys think? IMHO, the problem with the Haiku port is certainly not that it is not actively maintained, I work many hours on it each day, the problem is how to get the patches into SVN smoothly.

 Best regards,
 -Stephan

 ___
 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] How to bind a new scripting language to Webcore?

2010-04-09 Thread yunpheng lau
Can anyone tell me is it possible and if possible how to bind a new
scripting language to webkit?

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


[webkit-dev] Archiving the Haiku port? (was WebKit2 and all that jazz)

2010-04-09 Thread Maxime Simon
Hi,

I'm officially the main maintainer of the Haiku port. But
considering my university course I have little time to work on it.
(I had plan to do so next summer though.) Another Haiku developer,
Stephan Assmus, did lately some great improvements on the port,
but is now focused on the web browser and keeps a not up-to-date
version of WebKit for his work.

In fact, our community is really interested on this port but having
a web browser seems to be of greater priority.

Our maintainers are using a subversion repository to work on the port,
but it has to be a temporary solution. And as I saw Stephan recent
work I think we should move on, re update our repo to a newer version,
propose patches to move the code on the WebKit repository.

I think it would be a mess to waste the work done last summer and
recently. (I know it would be put in another branch, but it's kinda
lose for us.) But it's also my fault for not trying to propose new
patches from Stephan's work.

PS: Sorry Stephan, you have been quicker than me to reply. :-)
PPS: Adam, we aren't offended, just showing that we are still alive.

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


Re: [webkit-dev] How to bind a new scripting language to Webcore?

2010-04-09 Thread Adam Barth
It is possible, although a lot of work.  You might be interested in
the code in WebCore/bindings, which shows how to bind JavaScript and
Objective-C.

Adam


On Fri, Apr 9, 2010 at 3:26 PM, yunpheng lau yunpheng@gmail.com wrote:
 Can anyone tell me is it possible and if possible how to bind a new
 scripting language to webkit?
 cheers,
 Alex
 ___
 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] Get src and element from render object in dump tree

2010-04-09 Thread Adele Peterson

On Apr 9, 2010, at 2:45 PM, rikutse wrote:

 
 Is my question too stupid?

No, but it is directed at the wrong mailing list.  You should read 
http://webkit.org/contact.html and probably contact webkit-help.

- Adele

 
 
 
 rikutse wrote:
 
 Dear everyone,
I am new to study Webkit. In short, I used dump render tree for Google
 page: http://www.google.com :
 layer at (0,0) size 800x600
  RenderView at (0,0) size 800x600
 layer at (0,0) size 800x371
  RenderBlock {HTML} at (0,0) size 800x371
RenderBody {BODY} at (8,3) size 784x352 [bgcolor=#FF]
  RenderBlock {DIV} at (0,0) size 784x24
RenderBlock (floating) {DIV} at (0,0) size 377x23
  RenderInline {NOBR} at (0,0) size 377x16
RenderInline {B} at (0,0) size 29x16
  RenderText {#text} at (0,1) size 29x16
text run at (0,1) width 29: Web
RenderText {#text} at (35,1) size 4x16
  text run at (35,1) width 4:  
RenderInline {A} at (0,0) size 42x16 [color=#CC]
  RenderText {#text} at (39,1) size 42x16
text run at (39,1) width 42: Images
RenderText {#text} at (87,1) size 4x16
  text run at (87,1) width 4:  
RenderInline {A} at (0,0) size 40x16 [color=#CC]
  RenderText {#text} at (91,1) size 40x16
text run at (91,1) width 40: Videos
RenderText {#text} at (137,1) size 4x16
  text run at (137,1) width 4:  
RenderInline {A} at (0,0) size 32x16 [color=#CC]
  RenderText {#text} at (141,1) size 32x16
text run at (141,1) width 32: Maps
RenderText {#text} at (179,1) size 4x16
  text run at (179,1) width 4:  
RenderInline {A} at (0,0) size 32x16 [color=#CC]
  RenderText {#text} at (183,1) size 32x16
text run at (183,1) width 32: News
RenderText {#text} at (221,1) size 4x16
  text run at (221,1) width 4:  
RenderInline {A} at (0,0) size 54x16 [color=#CC]
  RenderText {#text} at (225,1) size 54x16
text run at (225,1) width 54: Shopping
RenderText {#text} at (285,1) size 4x16
  text run at (285,1) width 4:  
RenderInline {A} at (0,0) size 34x16 [color=#CC]
  RenderText {#text} at (289,1) size 34x16
text run at (289,1) width 34: Gmail
RenderText {#text} at (329,1) size 4x16
  text run at (329,1) width 4:  
RenderInline {A} at (0,0) size 44x16 [color=#CC]
  RenderInline {U} at (0,0) size 29x16
RenderText {#text} at (333,1) size 29x16
  text run at (333,1) width 29: more
  RenderText {#text} at (362,1) size 4x16
text run at (362,1) width 4:  
  RenderInline {SMALL} at (0,0) size 11x14
RenderText {#text} at (366,3) size 11x14
  text run at (366,3) width 11: \x{25BC}
RenderBlock {DIV} at (0,0) size 784x24
  RenderInline {NOBR} at (0,0) size 197x16
RenderInline {SPAN} at (0,0) size 0x0
RenderInline {SPAN} at (0,0) size 0x0
RenderInline {SPAN} at (0,0) size 55x16
  RenderInline {A} at (0,0) size 44x16 [color=#CC]
RenderText {#text} at (587,1) size 44x16
  text run at (587,1) width 44: iGoogle
  RenderText {#text} at (631,1) size 11x16
text run at (631,1) width 11:  | 
RenderInline {A} at (0,0) size 91x16 [color=#CC]
  RenderText {#text} at (642,1) size 91x16
text run at (642,1) width 91: Search settings
RenderText {#text} at (733,1) size 11x16
  text run at (733,1) width 11:  | 
RenderInline {A} at (0,0) size 40x16 [color=#CC]
  RenderText {#text} at (744,1) size 40x16
text run at (744,1) width 40: Sign in
  RenderBlock {CENTER} at (0,24) size 784x328
RenderBlock (anonymous) at (0,0) size 784x152
  RenderBR {BR} at (392,0) size 0x18
  RenderImage {IMG} at (254,19) size 276x110
  RenderBR {BR} at (530,114) size 0x18
  RenderBR {BR} at (392,133) size 0x18
RenderBlock {FORM} at (0,152) size 784x64
  RenderTable {TABLE} at (0,0) size 784x64
RenderTableSection {TBODY} at (0,0) size 784x64
  RenderTableRow {TR} at (0,0) size 784x64
RenderTableCell {TD} at (0,0) size 134x12 [r=0 c=0 rs=1
 cs=1]
  RenderText {#text} at (0,-3) size 4x18
text run at (0,-3) width 4:  
RenderTableCell {TD} at (134,0) size 487x64 [r=0 c=1 rs=1
 cs=1]
  RenderTextControl {INPUT} at (2,2) size 483x26
 [bgcolor=#FF] [border: (2px inset #00)]
  RenderBR {BR} at (487,16) 

[webkit-dev] Coming Soon: new-run-webkit-tests

2010-04-09 Thread Eric Seidel
Thanks to the tireless efforts of Dirk Pranke, Ojan Vafai, and
numerous other engineers, WebKit now has a new test harness for
running the Layout Tests.

It's FAST:
4-core Mac Pro, Debug build:
run-webkit-tests: 11m25s
new-run-webkit-tests: 3m24s
new-run-webkit-tests --experimental-fully-parallel: 2m42 [1]

WebKitTools/Scripts/new-run-webkit-tests is ready for you to play with
today, however it is not ready to replace run-webkit-tests as our main
testing script yet.

Pros:
- Fast (see above)
- Skipping is no longer our only tool, can mark tests as flaky (see
test_expectations.txt).
- Automatically retries failing tests to avoid failing due to flakiness.
- Outputs json for easier integration with other tools (like flakiness
dashboard).

Cons:
- Does not run on all core platforms yet (like Windows).
- results.html output is not as pretty as run-webkit-tests' output.
- Missing useful flags (e.g. --guard, --leaks).
- Can't run webarchive, mathml or wml tests yet.
- Exposes more flaky tests due to running tests in a non-deterministic order.

The test_expectations.txt file format is currently documented in the
file itself:
http://trac.webkit.org/browser/trunk/LayoutTests/platform/mac/test_expectations.txt

I would invite you to try running new-run-webkit-tests on your Mac
today.  You should feel encouraged to file bugs and hunt me down at
next week's contributer meeting.

If you're interested in contributing to the code, it can all be found here:
http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/layout_tests/

Eventually we will rename run-webkit-tests to old-run-webkit-tests and
new-run-webkit-tests to run-webkit-tests.  Since new-run-webkit-tests
is a complete re-write, some features of run-webkit-tests may go
missing when we move.  We will be moving them over to
new-run-webkit-tests in priority order.

Thanks for your time.

-eric

[1] new-run-webkit-tests currently defaults to a limited
parallel-by-directory mode.  Once we get new-run-webkit-tests on by
default and weed out the existing flaky tests we'll turn on the fully
parallel-by-file mode for a greater speed boost.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Coming Soon: new-run-webkit-tests

2010-04-09 Thread Yuzo Fujishima

Hi, Eric,

In my development environment, new-run-webkit-tests reports 149 errors
(out of 12692 tests) while run-webkit-tests none. Is this expected?

Are all of the errors what you mean by Exposes more flaky tests due to
running tests in a non-deterministic order ?

Yuzo

On Sat, Apr 10, 2010 at 7:35 AM, Eric Seidel e...@webkit.org wrote:


Thanks to the tireless efforts of Dirk Pranke, Ojan Vafai, and
numerous other engineers, WebKit now has a new test harness for
running the Layout Tests.



It's FAST:
4-core Mac Pro, Debug build:
run-webkit-tests: 11m25s
new-run-webkit-tests: 3m24s
new-run-webkit-tests --experimental-fully-parallel: 2m42 [1]



WebKitTools/Scripts/new-run-webkit-tests is ready for you to play with
today, however it is not ready to replace run-webkit-tests as our main
testing script yet.



Pros:
- Fast (see above)
- Skipping is no longer our only tool, can mark tests as flaky (see
test_expectations.txt).
- Automatically retries failing tests to avoid failing due to flakiness.
- Outputs json for easier integration with other tools (like flakiness
dashboard).



Cons:
- Does not run on all core platforms yet (like Windows).
- results.html output is not as pretty as run-webkit-tests' output.
- Missing useful flags (e.g. --guard, --leaks).
- Can't run webarchive, mathml or wml tests yet.
- Exposes more flaky tests due to running tests in a non-deterministic
order.



The test_expectations.txt file format is currently documented in the
file itself:



http://trac.webkit.org/browser/trunk/LayoutTests/platform/mac/test_expectations.txt



I would invite you to try running new-run-webkit-tests on your Mac
today.  You should feel encouraged to file bugs and hunt me down at
next week's contributer meeting.


If you're interested in contributing to the code, it can all be found  
here:



http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/layout_tests/



Eventually we will rename run-webkit-tests to old-run-webkit-tests and
new-run-webkit-tests to run-webkit-tests.  Since new-run-webkit-tests
is a complete re-write, some features of run-webkit-tests may go
missing when we move.  We will be moving them over to
new-run-webkit-tests in priority order.



Thanks for your time.



-eric



[1] new-run-webkit-tests currently defaults to a limited
parallel-by-directory mode.  Once we get new-run-webkit-tests on by
default and weed out the existing flaky tests we'll turn on the fully
parallel-by-file mode for a greater speed boost.
___
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] Coming Soon: new-run-webkit-tests

2010-04-09 Thread Eric Seidel
Sounds like a bug. You should expect 0 failures on leopard or snow leopard.
Please file a bug with a log of the failures and I will fix.

On Apr 9, 2010 4:11 PM, Yuzo Fujishima y...@google.com wrote:

Hi, Eric,

In my development environment, new-run-webkit-tests reports 149 errors
(out of 12692 tests) while run-webkit-tests none. Is this expected?

Are all of the errors what you mean by Exposes more flaky tests due to
running tests in a non-deterministic order ?

Yuzo

On Sat, Apr 10, 2010 at 7:35 AM, Eric Seidel e...@webkit.org wrote:

 
  Thanks to the tireless efforts of Dirk Pranke, Ojan Vafai, and
  numerous other engineers, WebKi...
 ___
 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] Coming Soon: new-run-webkit-tests

2010-04-09 Thread Brady Eidson

On Apr 9, 2010, at 3:35 PM, Eric Seidel wrote:

 Thanks to the tireless efforts of Dirk Pranke, Ojan Vafai, and
 numerous other engineers, WebKit now has a new test harness for
 running the Layout Tests.
 ...
 Cons:
 - Exposes more flaky tests due to running tests in a non-deterministic order.

This sounds like a pro to me.

~Brady

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


Re: [webkit-dev] Coming Soon: new-run-webkit-tests

2010-04-09 Thread Alexey Proskuryakov


On 09.04.2010, at 16:32, Brady Eidson wrote:

- Exposes more flaky tests due to running tests in a non- 
deterministic order.


This sounds like a pro to me.



Existing run-webkit-tests can also do that, via a non-default option.  
Unreproducible results with default options do sound like a con.


- WBR, Alexey Proskuryakov


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


Re: [webkit-dev] Coming Soon: new-run-webkit-tests

2010-04-09 Thread Brady Eidson

On Apr 9, 2010, at 4:41 PM, Alexey Proskuryakov wrote:

 
 On 09.04.2010, at 16:32, Brady Eidson wrote:
 
 - Exposes more flaky tests due to running tests in a non-deterministic 
 order.
 
 This sounds like a pro to me.
 
 
 Existing run-webkit-tests can also do that, via a non-default option. 
 Unreproducible results with default options do sound like a con.

Don't get me wrong - if a test fails reliably due to a specific run order, then 
the tool needs to be able to record the run-order so the failure can be 
explored.

But finding more flakey tests by mixing up the run order is - in principle - a 
good thing.

I'd forgotten that the current tool can mixup the run-order.

We should make the new tool record the order so order-specific failures can be 
explored.

~Brady

 - WBR, Alexey Proskuryakov
 
 

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


Re: [webkit-dev] Get src and element from render object in dump tree

2010-04-09 Thread rikutse

Thanks a lot, Adele

Adele Peterson wrote:
 
 
 On Apr 9, 2010, at 2:45 PM, rikutse wrote:
 
 
 Is my question too stupid?
 
 No, but it is directed at the wrong mailing list.  You should read
 http://webkit.org/contact.html and probably contact webkit-help.
 
 - Adele
 
 
 
 
 rikutse wrote:
 
 Dear everyone,
I am new to study Webkit. In short, I used dump render tree for
 Google
 page: http://www.google.com :
 layer at (0,0) size 800x600
  RenderView at (0,0) size 800x600
 layer at (0,0) size 800x371
  RenderBlock {HTML} at (0,0) size 800x371
RenderBody {BODY} at (8,3) size 784x352 [bgcolor=#FF]
  RenderBlock {DIV} at (0,0) size 784x24
RenderBlock (floating) {DIV} at (0,0) size 377x23
  RenderInline {NOBR} at (0,0) size 377x16
RenderInline {B} at (0,0) size 29x16
  RenderText {#text} at (0,1) size 29x16
text run at (0,1) width 29: Web
RenderText {#text} at (35,1) size 4x16
  text run at (35,1) width 4:  
RenderInline {A} at (0,0) size 42x16 [color=#CC]
  RenderText {#text} at (39,1) size 42x16
text run at (39,1) width 42: Images
RenderText {#text} at (87,1) size 4x16
  text run at (87,1) width 4:  
RenderInline {A} at (0,0) size 40x16 [color=#CC]
  RenderText {#text} at (91,1) size 40x16
text run at (91,1) width 40: Videos
RenderText {#text} at (137,1) size 4x16
  text run at (137,1) width 4:  
RenderInline {A} at (0,0) size 32x16 [color=#CC]
  RenderText {#text} at (141,1) size 32x16
text run at (141,1) width 32: Maps
RenderText {#text} at (179,1) size 4x16
  text run at (179,1) width 4:  
RenderInline {A} at (0,0) size 32x16 [color=#CC]
  RenderText {#text} at (183,1) size 32x16
text run at (183,1) width 32: News
RenderText {#text} at (221,1) size 4x16
  text run at (221,1) width 4:  
RenderInline {A} at (0,0) size 54x16 [color=#CC]
  RenderText {#text} at (225,1) size 54x16
text run at (225,1) width 54: Shopping
RenderText {#text} at (285,1) size 4x16
  text run at (285,1) width 4:  
RenderInline {A} at (0,0) size 34x16 [color=#CC]
  RenderText {#text} at (289,1) size 34x16
text run at (289,1) width 34: Gmail
RenderText {#text} at (329,1) size 4x16
  text run at (329,1) width 4:  
RenderInline {A} at (0,0) size 44x16 [color=#CC]
  RenderInline {U} at (0,0) size 29x16
RenderText {#text} at (333,1) size 29x16
  text run at (333,1) width 29: more
  RenderText {#text} at (362,1) size 4x16
text run at (362,1) width 4:  
  RenderInline {SMALL} at (0,0) size 11x14
RenderText {#text} at (366,3) size 11x14
  text run at (366,3) width 11: \x{25BC}
RenderBlock {DIV} at (0,0) size 784x24
  RenderInline {NOBR} at (0,0) size 197x16
RenderInline {SPAN} at (0,0) size 0x0
RenderInline {SPAN} at (0,0) size 0x0
RenderInline {SPAN} at (0,0) size 55x16
  RenderInline {A} at (0,0) size 44x16 [color=#CC]
RenderText {#text} at (587,1) size 44x16
  text run at (587,1) width 44: iGoogle
  RenderText {#text} at (631,1) size 11x16
text run at (631,1) width 11:  | 
RenderInline {A} at (0,0) size 91x16 [color=#CC]
  RenderText {#text} at (642,1) size 91x16
text run at (642,1) width 91: Search settings
RenderText {#text} at (733,1) size 11x16
  text run at (733,1) width 11:  | 
RenderInline {A} at (0,0) size 40x16 [color=#CC]
  RenderText {#text} at (744,1) size 40x16
text run at (744,1) width 40: Sign in
  RenderBlock {CENTER} at (0,24) size 784x328
RenderBlock (anonymous) at (0,0) size 784x152
  RenderBR {BR} at (392,0) size 0x18
  RenderImage {IMG} at (254,19) size 276x110
  RenderBR {BR} at (530,114) size 0x18
  RenderBR {BR} at (392,133) size 0x18
RenderBlock {FORM} at (0,152) size 784x64
  RenderTable {TABLE} at (0,0) size 784x64
RenderTableSection {TBODY} at (0,0) size 784x64
  RenderTableRow {TR} at (0,0) size 784x64
RenderTableCell {TD} at (0,0) size 134x12 [r=0 c=0 rs=1
 cs=1]
  RenderText {#text} at (0,-3) size 4x18
text run at (0,-3) width 4:  
RenderTableCell {TD} at (134,0) size 487x64 [r=0 c=1 rs=1
 cs=1]
  RenderTextControl {INPUT} at (2,2) size 483x26
 [bgcolor=#FF] [border: (2px inset 

Re: [webkit-dev] Coming Soon: new-run-webkit-tests

2010-04-09 Thread Yuzo Fujishima

Sorry, (mostly) false positives.

I've synced to r57383 and all but 3 failures are gone.

I don't see /tmp/layout-test-results. Where are the errors logged?
The following is the console output.

$ ./WebKitTools/Scripts/new-run-webkit-tests
stopping DumpRenderTree timed out, killing it
killed
  websocket/tests/frame-lengths.html - unexpected test timed out
  tables/mozilla/other/slashlogo.html - unexpected test timed out
  http/tests/cache/subresource-expiration.html - unexpected test timed out
  tables/mozilla/other/slashlogo.html - unexpected test timed out
  http/tests/cache/subresource-expiration.html - unexpected test timed out
  websocket/tests/frame-lengths.html - unexpected test timed out

12834 tests ran as expected, 3 didn't:

Regressions: Unexpected tests timed out : (3)
  http/tests/cache/subresource-expiration.html = TIMEOUT
  tables/mozilla/other/slashlogo.html = TIMEOUT
  websocket/tests/frame-lengths.html = TIMEOUT

Yuzo

On Sat, Apr 10, 2010 at 8:18 AM, Eric Seidel e...@webkit.org wrote:


Sounds like a bug. You should expect 0 failures on leopard or snow
leopard.  Please file a bug with a log of the failures and I will fix.



On Apr 9, 2010 4:11 PM, Yuzo Fujishima y...@google.com wrote:



Hi, Eric,



In my development environment, new-run-webkit-tests reports 149 errors
(out of 12692 tests) while run-webkit-tests none. Is this expected?



Are all of the errors what you mean by Exposes more flaky tests due to
running tests in a non-deterministic order ?



Yuzo



On Sat, Apr 10, 2010 at 7:35 AM, Eric Seidel e...@webkit.org wrote:




 Thanks to the tireless efforts of Dirk Pranke, Ojan Vafai, and
 numerous other engineers, WebKi...



___
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] Coming Soon: new-run-webkit-tests

2010-04-09 Thread Adam Barth
On Fri, Apr 9, 2010 at 4:43 PM, Brady Eidson beid...@apple.com wrote:
 We should make the new tool record the order so order-specific failures can 
 be explored.

That sounds like a good idea.  If the tool doesn't do this yet, we can
certainly add that.

Fixing some of these have been easy so far.  For example, there was a
test that printed out the width of a window and another test that
changed the width, etc.  Eric did some work with the tests that use
cookies so they clean out their cookies.  I haven't tried to fix any
of the hard ones.

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


Re: [webkit-dev] Coming Soon: new-run-webkit-tests

2010-04-09 Thread Adam Barth
The new tool had a much tighter timeout than the old tool.  We'll
probably have to increase that.  You can also mark a test as SLOW in
test_expectations.txt, and then it will be given a longer timeout.  It
might be worth having a shorter timeout for developers so we know when
we write slow tests.  :)

Adam


On Fri, Apr 9, 2010 at 5:03 PM, Yuzo Fujishima y...@google.com wrote:
 Sorry, (mostly) false positives.
 I've synced to r57383 and all but 3 failures are gone.
 I don't see /tmp/layout-test-results. Where are the errors logged?
 The following is the console output.
 $ ./WebKitTools/Scripts/new-run-webkit-tests
 stopping DumpRenderTree timed out, killing it
 killed
   websocket/tests/frame-lengths.html - unexpected test timed out
   tables/mozilla/other/slashlogo.html - unexpected test timed out
   http/tests/cache/subresource-expiration.html - unexpected test timed out
   tables/mozilla/other/slashlogo.html - unexpected test timed out
   http/tests/cache/subresource-expiration.html - unexpected test timed out
   websocket/tests/frame-lengths.html - unexpected test timed out

 12834 tests ran as expected, 3 didn't:
 Regressions: Unexpected tests timed out : (3)
   http/tests/cache/subresource-expiration.html = TIMEOUT
   tables/mozilla/other/slashlogo.html = TIMEOUT
   websocket/tests/frame-lengths.html = TIMEOUT
 Yuzo
 On Sat, Apr 10, 2010 at 8:18 AM, Eric Seidel e...@webkit.org wrote:

 Sounds like a bug. You should expect 0 failures on leopard or snow
 leopard.  Please file a bug with a log of the failures and I will fix.

 On Apr 9, 2010 4:11 PM, Yuzo Fujishima y...@google.com wrote:

 Hi, Eric,
 In my development environment, new-run-webkit-tests reports 149 errors
 (out of 12692 tests) while run-webkit-tests none. Is this expected?
 Are all of the errors what you mean by Exposes more flaky tests due to
 running tests in a non-deterministic order ?
 Yuzo

 On Sat, Apr 10, 2010 at 7:35 AM, Eric Seidel e...@webkit.org wrote:

 
  Thanks to the tireless efforts of Dirk Pranke, Ojan Vafai, and
  numerous other engineers, WebKi...

 ___
 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


[webkit-dev] adding webkit perf bots?

2010-04-09 Thread Ojan Vafai
Chromium has a bunch of perf bots that we run continuously. Most of these
are just page cyclers that loop through pages. They're grouped by different
types. You can see some graphs here:
http://build.chromium.org/buildbot/perf/dashboard/overview.html. The more
stable bots will also turn red on perf/memory regressions.

This is really useful data that it would be awesome to have at a more
granular level than each time chromium pulls in a new webkit revision. Also,
it would be great to have this upstream so that it doesn't depend on
chromium engineers to notice and help run the tests.

This came up recently due to a perf/memory regression from
http://trac.webkit.org/changeset/57215 on Mac loading international pages
(see
http://build.chromium.org/buildbot/perf/mac-release-10.5/intl2/report.html?history=150rev=-1).
With that data we were able to find the root problem and have a path forward
for fixing it https://bugs.webkit.org/show_bug.cgi?id=37292.

What would it take to support these (the ones that test web page perf) in
upstream WebKit?

Some initial thoughts:
1. Machines for the new bots.
2. Make the page cyclers work with Safari (DRT?). I imagine this is not too
hard.
3. Make the data available. Currently, these are on Chrome's internal svn
repo. I think this is due to fear of copyright infringement if we were to
publicly distribute them (i.e. a copy of someone else's copyrighted
website). I don't know the details here and IANAL, so I don't know how hard
this is to workaround. Seems like we ought to be able to figure something
out though.

Any interest? Anyone willing to do the grunt work?

Maybe this is a good topic for the webkit conference.

Ojan


Abberviated #webkit discussion:
[11:29am] smfr: why doesn't webkit have data like that?
[11:30am] smfr: ojan: it sucks that such data are not available via
webkit.org
[11:30am] ojan: smfr: i agree
[11:30am] smfr: we should be measuring page load and memory use for every
build
[11:30am] ojan: smfr: no argument from me
[11:30am] dglazkov: smfr, ojan: we totally should.
[11:31am] Catfish_Man: mmm delicious delicious metrics
[11:31am] smfr: any volunteers?
[11:31am] dglazkov: I volunteer ojan
[11:32am] ojan: dglazkov: i unvolunteer myself!
[11:32am] dglazkov: then I volunteer smfr
[11:32am] ojan: but i fully support someone else moving these tests to
webkit
[11:32am] smfr: we need a good server-side hacker
[11:32am] smfr: that's not me
[11:33am] dglazkov: so would it be a matter of hooking up DRT to run various
tests and putting up a bot?
[11:33am] enrica: great project for an intern
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Coming Soon: new-run-webkit-tests

2010-04-09 Thread Dirk Pranke
On Fri, Apr 9, 2010 at 4:43 PM, Brady Eidson beid...@apple.com wrote:

 On Apr 9, 2010, at 4:41 PM, Alexey Proskuryakov wrote:


 On 09.04.2010, at 16:32, Brady Eidson wrote:

 - Exposes more flaky tests due to running tests in a non-deterministic 
 order.

 This sounds like a pro to me.


 Existing run-webkit-tests can also do that, via a non-default option. 
 Unreproducible results with default options do sound like a con.

 Don't get me wrong - if a test fails reliably due to a specific run order, 
 then the tool needs to be able to record the run-order so the failure can be 
 explored.

 But finding more flakey tests by mixing up the run order is - in principle - 
 a good thing.

 I'd forgotten that the current tool can mixup the run-order.

 We should make the new tool record the order so order-specific failures can 
 be explored.


There are two sources of non-determinism.

One, which is easy to deal with, is the result of shuffling the
testing order. The new script supports this but doesn't use it by
default.

The other is the result of timing and concurrency issues, and is not
so easily dealt with. The default code path shards by directory, and
as a result it is reasonably predictable which tests will run on which
thread. However, even in this situation you can get contention on the
filesystem and (much more common) the web server that can produce
timeouts and other unpredictable events. The
--experimental-fully-parallel code path makes the situation worse by
not even being able to easily say that any two tests will or won't be
executed sequentially by the same thread (the code uses a threadsafe
Python Queue object with N consumers). We also (I think) see a fair
amount of contention on the queue itself that contributes to timing
issues.

-- Dirk

 ~Brady

 - WBR, Alexey Proskuryakov




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


Re: [webkit-dev] Coming Soon: new-run-webkit-tests

2010-04-09 Thread Dirk Pranke
On Fri, Apr 9, 2010 at 5:03 PM, Yuzo Fujishima y...@google.com wrote:
 I don't see /tmp/layout-test-results. Where are the errors logged?

/tmp/run-chromium-webkit-tests-layout-test-results/*

This was done intentionally at the time to not collide with
run-webkit-tests, but it should be changed [1].

-- Dirk

[1] https://bugs.webkit.org/show_bug.cgi?id=37380
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Coming Soon: new-run-webkit-tests

2010-04-09 Thread Zoltan Herczeg

 We should make the new tool record the order so order-specific failures
 can be explored.

A custom random generator would be enough. The seed can be given by a user
or a just starts with a random value which is reported when the test
finish. Much easier to share seed-revision pairs than anything else, and
also easy to replay.

Zoltan


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