[webkit-dev] New Qt buildbots

[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

[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  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

[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 > 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

[Jeremy Orlow]

On Fri, Apr 9, 2010 at 2:33 AM, Adam Treat  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

[Xan Lopez]

On Fri, Apr 9, 2010 at 2:47 AM, Xan Lopez  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

[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

[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

[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

[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  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

[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 
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

[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  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  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

[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

[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

[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]

[Evan Martin]

On Thu, Apr 8, 2010 at 4:01 PM, Anders Carlsson  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]

[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  wrote:
> On Thu, Apr 8, 2010 at 4:01 PM, Anders Carlsson  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

[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

[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

[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

[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

[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]

[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  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  wrote:
> > On Thu, Apr 8, 2010 at 4:01 PM, Anders Carlsson 
> 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

[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

[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  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

[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

[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  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

[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

[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 

Re: [webkit-dev] Announcing WebKit2

[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

[Cameron Zwarich]

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

> On Fri, Apr 9, 2010 at 2:33 AM, Adam Treat  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

[Adam Barth]

On Fri, Apr 9, 2010 at 1:53 PM, Cameron Zwarich  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

[Kenneth Christiansen]

Which ports are considered unmaintained?

Kenneth

On Fri, Apr 9, 2010 at 6:03 PM, Adam Barth  wrote:
> On Fri, Apr 9, 2010 at 1:53 PM, Cameron Zwarich  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

[Maciej Stachowiak]

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

On Fri, Apr 9, 2010 at 1:53 PM, Cameron Zwarich  
 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

[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  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

[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

[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)

[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)

[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  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

[Darin Fisher]

On Fri, Apr 9, 2010 at 1:53 PM, Cameron Zwarich wrote:

> On Apr 9, 2010, at 2:34 AM, Jeremy Orlow wrote:
>
> On Fri, Apr 9, 2010 at 2:33 AM, Adam Treat  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, 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] Announcing WebKit2

[Darin Fisher]

On Fri, Apr 9, 2010 at 2:36 PM, Darin Fisher  wrote:

> On Fri, Apr 9, 2010 at 1:53 PM, Cameron Zwarich wrote:
>
>> On Apr 9, 2010, at 2:34 AM, Jeremy Orlow wrote:
>>
>> On Fri, Apr 9, 2010 at 2:33 AM, Adam Treat  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

[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)]
> 

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

[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  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)

[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)

[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

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

[Maciej Stachowiak]

On Apr 9, 2010, at 2:36 PM, Darin Fisher wrote:



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.


One thing Adam Barth and I discussed recently was unforking URL  
processing. I think that would be a good session for the contributor  
meeting.


Cheers,
Maciej

P.S. those of you planning to attend the meeting should think about  
potential session topics - the whole agenda will be driven by the  
topics people that attendees come up with. The sessions are msotly  
going to be more like roundtable discussions or hackfests than formal  
sessions, but if anyone has prepared notes for speaking about a topic,  
that is fine too.

___
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)

[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  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?

[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)

[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?

[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  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

[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: " "
>>  

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

[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

[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  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

[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"  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  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

[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

[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

[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

[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) s

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

[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  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"  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  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

[Adam Barth]

On Fri, Apr 9, 2010 at 4:43 PM, Brady Eidson  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

[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  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  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"  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  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?

[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=150&rev=-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

[Dirk Pranke]

On Fri, Apr 9, 2010 at 4:43 PM, Brady Eidson  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

[Dirk Pranke]

On Fri, Apr 9, 2010 at 5:03 PM, Yuzo Fujishima  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

[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

Re: [webkit-dev] Announcing WebKit2

[Brent Fulgham]

On Apr 9, 2010, at 2:40 AM, Xan Lopez wrote:

> 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?

You can always use CFLite (available externally from Apple as 'opencflite' 
(http://sourceforge.net/projects/opencflite/).

It builds on Linux, Windows, and Mac OS X.  I've found it very useful for 
tracking the full Apple WebKit port, as it means there is much less code to 
duplicate and maintain.  I can just let the kind folks at Apple do all the 
heavy lifting :-)

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