Re: [webkit-dev] Frustrated at inconsiderate behavior

[David Levin]

On Wed, Jul 7, 2010 at 9:46 PM, William Siegrist wrote:

> On Jul 7, 2010, at 7:42 PM, Maciej Stachowiak wrote:
>
> >
> > On Jul 7, 2010, at 7:32 PM, Oliver Hunt wrote:
> >
> >> My opinion is that if people want to use the commit-queue to land
> patches they should be happy to drop their commit privileges thus mooting
> this entire issue.
> >
> > That would probably make things worse on net, since the commit queue
> would then not mark the person as the committer in SVN.
> >
>
> On a side note, I'm pretty sure we could make the CQ rewrite even
> non-commiter authors. At some point we decided to only do committers, but I
> do not believe there is any technical reason preventing us from rewriting
> everyone.
>

I think that would be awesome.

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

Re: [webkit-dev] Frustrated at inconsiderate behavior

[William Siegrist]

On Jul 7, 2010, at 7:42 PM, Maciej Stachowiak wrote:

> 
> On Jul 7, 2010, at 7:32 PM, Oliver Hunt wrote:
> 
>> My opinion is that if people want to use the commit-queue to land patches 
>> they should be happy to drop their commit privileges thus mooting this 
>> entire issue.
> 
> That would probably make things worse on net, since the commit queue would 
> then not mark the person as the committer in SVN.
> 

On a side note, I'm pretty sure we could make the CQ rewrite even non-commiter 
authors. At some point we decided to only do committers, but I do not believe 
there is any technical reason preventing us from rewriting everyone.

-Bill



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

Re: [webkit-dev] Does any port implements Navigator.registerProtocolHandler and Navigator.registerContentHandler?

[Jeremy Orlow]

That would be the standard thing to do.

The sooner someone gets started on the feature, the easier it'll be to
revert the patch that removes the code.  :-)

J

On Thu, Jul 8, 2010 at 10:55 AM, David Levin  wrote:

>
>
> On Wed, Jul 7, 2010 at 5:24 PM, Peter Kasting  wrote:
>
>> On Wed, Jul 7, 2010 at 5:00 PM, Dmitry Titov  wrote:
>>
>>> I'd lean to the removal, unless there is a port that has work ongoing or
>>> planned soon for those implementations.
>>>
>>> Does anybody vote for #ifdefs?
>>>
>>
>> I vote against removal if only because Chromium has really wanted these
>> badly for a long time and simply hasn't been able to find someone to
>> implement them.  Perhaps I could make it worth your while to implement
>> rather than remove the stubs?  :)
>>
>
> *Even if someone to implement them for chromium, it doesn't seem to fix
> the overall problem. *Dmitry indicated that the presences of these is
> breaking feature detection in browsers using WebKit (-- which is something
> being heard from web developers).
>
> A simple solution is to remove them. Later, any port (including chromium)
> who gets someone to work on them could re-add these methods back properly
> under ifdef's.
>
> dave
>
> ___
> 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] Does any port implements Navigator.registerProtocolHandler and Navigator.registerContentHandler?

[David Levin]

On Wed, Jul 7, 2010 at 5:24 PM, Peter Kasting  wrote:

> On Wed, Jul 7, 2010 at 5:00 PM, Dmitry Titov  wrote:
>
>> I'd lean to the removal, unless there is a port that has work ongoing or
>> planned soon for those implementations.
>>
>> Does anybody vote for #ifdefs?
>>
>
> I vote against removal if only because Chromium has really wanted these
> badly for a long time and simply hasn't been able to find someone to
> implement them.  Perhaps I could make it worth your while to implement
> rather than remove the stubs?  :)
>

*Even if someone to implement them for chromium, it doesn't seem to fix the
overall problem. *Dmitry indicated that the presences of these is breaking
feature detection in browsers using WebKit (-- which is something being
heard from web developers).

A simple solution is to remove them. Later, any port (including chromium)
who gets someone to work on them could re-add these methods back properly
under ifdef's.

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

Re: [webkit-dev] Frustrated at inconsiderate behavior

[Maciej Stachowiak]

On Jul 7, 2010, at 7:32 PM, Oliver Hunt wrote:

> 
> webkit-patch land-safely does the job of running the tests automatically, 
> that said if you have commit privileges you should be running the tests 
> yourself otherwise you're wasting the reviewers time.
> 
> Pushing a patch through the normal review path will have it built on multiple 
> platforms (though it is annoying that once you get r+ those builders don't 
> run).
> 
> The only benefit of the commit-queue (as i see it) is that it will make sure 
> that the patch still applies in the many hours between it being reviewed and 
> it being landed.

You can roll out the patch and work on something else, which might be a benefit 
to some.

Also, the track record of the commit queue seems to be that people using it are 
less likely to break the tree in practice. I'm not naturally enthusiastic about 
the commit queue approach (I like to be around when my patch actually lands), 
but you can't argue with results. The only remaining downside (in my opinion) 
is sometimes making people overly frustrated when it's blocked, and 
occasionally leading to inelegant fixes for tree redness.

> My opinion is that if people want to use the commit-queue to land patches 
> they should be happy to drop their commit privileges thus mooting this entire 
> issue.

That would probably make things worse on net, since the commit queue would then 
not mark the person as the committer in SVN.

Personally, I don't think we need to either mandate or discourage use of the 
commit queue at this time.

Regards,
Maciej

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

Re: [webkit-dev] Frustrated at inconsiderate behavior

[Oliver Hunt]

On Jul 7, 2010, at 7:26 PM, Jeremy Orlow wrote:

> On Thu, Jul 8, 2010 at 10:19 AM, Oliver Hunt  wrote:
> 
> On Jul 7, 2010, at 7:16 PM, Tony Gentilcore wrote:
> 
>> 
>> 
>> On Wed, Jul 7, 2010 at 6:50 PM, Mo, Zhenyao  wrote:
>> Maybe I should complain this in a different threads, but recently the commit 
>> bot waiting time is way too long.  Several times a patch of mine got the r+ 
>> and cq+ and it landed two days later.  This is really frustrating.
>> 
>> I am very tempted to use svn directly to commit patches, but that means the 
>> patch only gets tested in my local environments. Like one time my patch 
>> breaks the leopard bot, turns out the failed test is skipped on leopard, 
>> which is exactly my OS.  If I land it through the commit bots, I could 
>> identify the issue earlier.
>> 
>> I agree they are closely related. A greener tree means a faster commit queue 
>> and a faster commit queue means less people subvert it and break the tree. 
>> The hard problem is figuring out how to fix the incentives so subverting the 
>> queue isn't so desirable.
> 
> What do you mean by subvert the queue?  The commit queue is a tool to 
> streamline commits from contributors who do not have commit access to the 
> repository.  If you have the ability to commit you should not be using the 
> commit queue to land your patches.
> 
> That is the opinion of a few contributors, yes.  But even when there were 
> some big downsides to committers using the commit queue, there was definitely 
> no definitive direction to not use the queue.  And now that pretty much all 
> the problems with the queue have been systematically eliminated, I would 
> argue that--if anything--we should actually ask everyone to use the queue 
> when practical.

webkit-patch land-safely does the job of running the tests automatically, that 
said if you have commit privileges you should be running the tests yourself 
otherwise you're wasting the reviewers time.

Pushing a patch through the normal review path will have it built on multiple 
platforms (though it is annoying that once you get r+ those builders don't run).

The only benefit of the commit-queue (as i see it) is that it will make sure 
that the patch still applies in the many hours between it being reviewed and it 
being landed.

My opinion is that if people want to use the commit-queue to land patches they 
should be happy to drop their commit privileges thus mooting this entire issue.

--Oliver

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

Re: [webkit-dev] Frustrated at inconsiderate behavior

[Maciej Stachowiak]

On Jul 7, 2010, at 7:22 PM, James Robinson wrote:

> 
> 
> On Wed, Jul 7, 2010 at 7:19 PM, Oliver Hunt  wrote:
> 
> On Jul 7, 2010, at 7:16 PM, Tony Gentilcore wrote:
> 
>> 
>> 
>> On Wed, Jul 7, 2010 at 6:50 PM, Mo, Zhenyao  wrote:
>> Maybe I should complain this in a different threads, but recently the commit 
>> bot waiting time is way too long.  Several times a patch of mine got the r+ 
>> and cq+ and it landed two days later.  This is really frustrating.
>> 
>> I am very tempted to use svn directly to commit patches, but that means the 
>> patch only gets tested in my local environments. Like one time my patch 
>> breaks the leopard bot, turns out the failed test is skipped on leopard, 
>> which is exactly my OS.  If I land it through the commit bots, I could 
>> identify the issue earlier.
>> 
>> I agree they are closely related. A greener tree means a faster commit queue 
>> and a faster commit queue means less people subvert it and break the tree. 
>> The hard problem is figuring out how to fix the incentives so subverting the 
>> queue isn't so desirable.
> 
> What do you mean by subvert the queue?  The commit queue is a tool to 
> streamline commits from contributors who do not have commit access to the 
> repository.  If you have the ability to commit you should not be using the 
> commit queue to land your patches.
> 
>  
> That's not my understanding of the commit queue.  I use the commit queue to 
> land my patches when possible so that the patch receives further testing 
> before it hits the tree and potentially affects a large number of 
> contributors.  Why do you think this is a bad idea?  Is this preference 
> codified somewhere (formally or informally)?

Previously the commit queue had a problem whereby it would show incorrect 
committer information (every patch committed by Eric). Now that is fixed - 
every patch submitted by a committer will show the proper committer, and those 
submitted by a non-committer will show up as committed by commit-queue. I think 
it's a choice of which approach to use.

In addition to the obvious benefit of testing your patch for you, I think one 
positive externality of the commit queue is that people who use it are more 
motivated to keep the tree green. One negative externality is that it sometimes 
makes people excessively upset about tree redness, and sometimes makes them 
want to fix redness in a way that papers over problems (e.g. by adding to the 
skipped list).

On the whole, I suspect the benefits of automated testing before landing 
probably outweigh these concerns.

Regards,
Maciej


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

[webkit-dev] Frustrated at inconsiderate behavior

[Jeremy Orlow]

On Thu, Jul 8, 2010 at 10:19 AM, Oliver Hunt  wrote:

>
> On Jul 7, 2010, at 7:16 PM, Tony Gentilcore wrote:
>
>
>
> On Wed, Jul 7, 2010 at 6:50 PM, Mo, Zhenyao  wrote:
>
>> Maybe I should complain this in a different threads, but recently the
>> commit bot waiting time is way too long.  Several times a patch of mine got
>> the r+ and cq+ and it landed two days later.  This is really frustrating.
>>
>> I am very tempted to use svn directly to commit patches, but that means
>> the patch only gets tested in my local environments. Like one time my patch
>> breaks the leopard bot, turns out the failed test is skipped on leopard,
>> which is exactly my OS.  If I land it through the commit bots, I could
>> identify the issue earlier.
>>
>
> I agree they are closely related. A greener tree means a faster commit
> queue and a faster commit queue means less people subvert it and break the
> tree. The hard problem is figuring out how to fix the incentives so
> subverting the queue isn't so desirable.
>
>
> What do you mean by subvert the queue?  The commit queue is a tool to
> streamline commits from contributors who do not have commit access to the
> repository.  If you have the ability to commit you should not be using the
> commit queue to land your patches.
>

That is the opinion of a few contributors, yes.  But even when there were
some big downsides to committers using the commit queue, there was
definitely no definitive direction to not use the queue.  And now that
pretty much all the problems with the queue have been systematically
eliminated, I would argue that--if anything--we should actually ask everyone
to use the queue when practical.

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

Re: [webkit-dev] Frustrated at inconsiderate behavior

[Tony Gentilcore]

On Wed, Jul 7, 2010 at 7:22 PM, James Robinson  wrote:

>
>
> On Wed, Jul 7, 2010 at 7:19 PM, Oliver Hunt  wrote:
>
>>
>> On Jul 7, 2010, at 7:16 PM, Tony Gentilcore wrote:
>>
>>
>>
>> On Wed, Jul 7, 2010 at 6:50 PM, Mo, Zhenyao  wrote:
>>
>>> Maybe I should complain this in a different threads, but recently the
>>> commit bot waiting time is way too long.  Several times a patch of mine got
>>> the r+ and cq+ and it landed two days later.  This is really frustrating.
>>>
>>> I am very tempted to use svn directly to commit patches, but that means
>>> the patch only gets tested in my local environments. Like one time my patch
>>> breaks the leopard bot, turns out the failed test is skipped on leopard,
>>> which is exactly my OS.  If I land it through the commit bots, I could
>>> identify the issue earlier.
>>>
>>
>> I agree they are closely related. A greener tree means a faster commit
>> queue and a faster commit queue means less people subvert it and break the
>> tree. The hard problem is figuring out how to fix the incentives so
>> subverting the queue isn't so desirable.
>>
>>
>> What do you mean by subvert the queue?  The commit queue is a tool to
>> streamline commits from contributors who do not have commit access to the
>> repository.  If you have the ability to commit you should not be using the
>> commit queue to land your patches.
>>
>>
> That's not my understanding of the commit queue.  I use the commit queue to
> land my patches when possible so that the patch receives further testing
> before it hits the tree and potentially affects a large number of
> contributors.  Why do you think this is a bad idea?  Is this preference
> codified somewhere (formally or informally)?
>

Interesting. I'm a very new committer and it is possible I've completely
misunderstood it. I thought of it as a useful tool to help make sure our
patches don't break the tree. But given James' response I'm now very
interested to hear what others think.


>
> - James
>
>
>> --Oliver
>>
>>
>> ___
>> 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] Frustrated at inconsiderate behavior

[James Robinson]

On Wed, Jul 7, 2010 at 7:19 PM, Oliver Hunt  wrote:

>
> On Jul 7, 2010, at 7:16 PM, Tony Gentilcore wrote:
>
>
>
> On Wed, Jul 7, 2010 at 6:50 PM, Mo, Zhenyao  wrote:
>
>> Maybe I should complain this in a different threads, but recently the
>> commit bot waiting time is way too long.  Several times a patch of mine got
>> the r+ and cq+ and it landed two days later.  This is really frustrating.
>>
>> I am very tempted to use svn directly to commit patches, but that means
>> the patch only gets tested in my local environments. Like one time my patch
>> breaks the leopard bot, turns out the failed test is skipped on leopard,
>> which is exactly my OS.  If I land it through the commit bots, I could
>> identify the issue earlier.
>>
>
> I agree they are closely related. A greener tree means a faster commit
> queue and a faster commit queue means less people subvert it and break the
> tree. The hard problem is figuring out how to fix the incentives so
> subverting the queue isn't so desirable.
>
>
> What do you mean by subvert the queue?  The commit queue is a tool to
> streamline commits from contributors who do not have commit access to the
> repository.  If you have the ability to commit you should not be using the
> commit queue to land your patches.
>
>
That's not my understanding of the commit queue.  I use the commit queue to
land my patches when possible so that the patch receives further testing
before it hits the tree and potentially affects a large number of
contributors.  Why do you think this is a bad idea?  Is this preference
codified somewhere (formally or informally)?

- James


> --Oliver
>
>
> ___
> 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] Frustrated at inconsiderate behavior

[Oliver Hunt]

On Jul 7, 2010, at 7:16 PM, Tony Gentilcore wrote:

> 
> 
> On Wed, Jul 7, 2010 at 6:50 PM, Mo, Zhenyao  wrote:
> Maybe I should complain this in a different threads, but recently the commit 
> bot waiting time is way too long.  Several times a patch of mine got the r+ 
> and cq+ and it landed two days later.  This is really frustrating.
> 
> I am very tempted to use svn directly to commit patches, but that means the 
> patch only gets tested in my local environments. Like one time my patch 
> breaks the leopard bot, turns out the failed test is skipped on leopard, 
> which is exactly my OS.  If I land it through the commit bots, I could 
> identify the issue earlier.
> 
> I agree they are closely related. A greener tree means a faster commit queue 
> and a faster commit queue means less people subvert it and break the tree. 
> The hard problem is figuring out how to fix the incentives so subverting the 
> queue isn't so desirable.

What do you mean by subvert the queue?  The commit queue is a tool to 
streamline commits from contributors who do not have commit access to the 
repository.  If you have the ability to commit you should not be using the 
commit queue to land your patches.

--Oliver

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

Re: [webkit-dev] Frustrated at inconsiderate behavior

[Tony Gentilcore]

On Wed, Jul 7, 2010 at 6:50 PM, Mo, Zhenyao  wrote:

> Maybe I should complain this in a different threads, but recently the
> commit bot waiting time is way too long.  Several times a patch of mine got
> the r+ and cq+ and it landed two days later.  This is really frustrating.
>
> I am very tempted to use svn directly to commit patches, but that means the
> patch only gets tested in my local environments. Like one time my patch
> breaks the leopard bot, turns out the failed test is skipped on leopard,
> which is exactly my OS.  If I land it through the commit bots, I could
> identify the issue earlier.
>

I agree they are closely related. A greener tree means a faster commit queue
and a faster commit queue means less people subvert it and break the tree.
The hard problem is figuring out how to fix the incentives so subverting the
queue isn't so desirable.

There is also a smaller but more concrete problem. Older bugs cut in front
of newer bugs in the commit queue. So when the queue is moving slowly,
patches with recent bug IDs could spend a long time getting bumped before
finally landing.
https://bugs.webkit.org/show_bug.cgi?id=41791


>
> If there is any way to improve the situation, I'd really appreciate it.
>
> mo
>
>
> On Wed, Jul 7, 2010 at 12:47 AM, Adam Barth  wrote:
>
>> If you're tired of my complaining about the tree being red, you can
>> skip this message.
>>
>> Today Alexey checked in ,
>> which broke two tests on every port.  12 hours later, these failures
>> remained in the tree until I cleaned them up.  This mess could have
>> been avoided in a number of ways:
>>
>> 1) He could have run-webkit-tests before committing his change.
>> 2) If he didn't have time to run the tests locally, he could have used
>> the commit-queue to run-webkit-tests before it landed his patch.
>> 3) He could have looked at the tree when sheriff-bot informed him that
>> he might have broken Leopard Intel Debug by pinging him in #webkit and
>> commenting on his bug:
>> .
>>
>> Is this acceptable behavior?
>>
>> http://webkit.org/coding/contributing.html clearly says to "run the
>> layout tests using the run-webkit-tests script and make sure they all
>> pass."  That page also says:
>>
>> [[
>> In either case, your responsibility for the patch does not end with
>> the patch landing in the tree. There may be regressions from your
>> change or additional feedback from reviewers after the patch has
>> landed. You can watch the tree at build.webkit.org to make sure your
>> patch builds and passes tests on all platforms. It is your
>> responsibility to be available should regressions arise and to respond
>> to additional feedback that happens after a check-in.
>> ]]
>>
>> Are there consequences for breaking these rules?
>>
>> 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
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Frustrated at inconsiderate behavior

[Mo, Zhenyao]

Maybe I should complain this in a different threads, but recently the commit
bot waiting time is way too long.  Several times a patch of mine got the r+
and cq+ and it landed two days later.  This is really frustrating.

I am very tempted to use svn directly to commit patches, but that means the
patch only gets tested in my local environments. Like one time my patch
breaks the leopard bot, turns out the failed test is skipped on leopard,
which is exactly my OS.  If I land it through the commit bots, I could
identify the issue earlier.

If there is any way to improve the situation, I'd really appreciate it.

mo

On Wed, Jul 7, 2010 at 12:47 AM, Adam Barth  wrote:

> If you're tired of my complaining about the tree being red, you can
> skip this message.
>
> Today Alexey checked in ,
> which broke two tests on every port.  12 hours later, these failures
> remained in the tree until I cleaned them up.  This mess could have
> been avoided in a number of ways:
>
> 1) He could have run-webkit-tests before committing his change.
> 2) If he didn't have time to run the tests locally, he could have used
> the commit-queue to run-webkit-tests before it landed his patch.
> 3) He could have looked at the tree when sheriff-bot informed him that
> he might have broken Leopard Intel Debug by pinging him in #webkit and
> commenting on his bug:
> .
>
> Is this acceptable behavior?
>
> http://webkit.org/coding/contributing.html clearly says to "run the
> layout tests using the run-webkit-tests script and make sure they all
> pass."  That page also says:
>
> [[
> In either case, your responsibility for the patch does not end with
> the patch landing in the tree. There may be regressions from your
> change or additional feedback from reviewers after the patch has
> landed. You can watch the tree at build.webkit.org to make sure your
> patch builds and passes tests on all platforms. It is your
> responsibility to be available should regressions arise and to respond
> to additional feedback that happens after a check-in.
> ]]
>
> Are there consequences for breaking these rules?
>
> 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] Frustrated at inconsiderate behavior

[Jeremy Orlow]

On Thu, Jul 8, 2010 at 2:03 AM, Alexey Proskuryakov  wrote:

>
> 07.07.2010, в 9:49, Jeremy Orlow написал(а):
>
> Why did not one of those people roll the patch out when it was clear that
> there were failures and Alexey wasn't in the process of fixing them?
>
>
> Just to avoid any misunderstanding, the best thing to do would have been to
> tell me about the problem on IRC. I wasn't around at midnight, when Adam
> noticed the problem, but I was on IRC for many hours after landing that
> patch.
>

Surewell, why did neither happen?  Can any committers who saw the
redness but didn't work to resolve the problem comment on how the process
broke down?

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

Re: [webkit-dev] Does any port implements Navigator.registerProtocolHandler and Navigator.registerContentHandler?

[Peter Kasting]

On Wed, Jul 7, 2010 at 5:00 PM, Dmitry Titov  wrote:

> I'd lean to the removal, unless there is a port that has work ongoing or
> planned soon for those implementations.
>
> Does anybody vote for #ifdefs?
>

I vote against removal if only because Chromium has really wanted these
badly for a long time and simply hasn't been able to find someone to
implement them.  Perhaps I could make it worth your while to implement
rather than remove the stubs?  :)

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

[webkit-dev] Does any port implements Navigator.registerProtocolHandler and Navigator.registerContentHandler?

[Dmitry Titov]

Hi,

I'm looking to disable/remove the methods exposed on Navigator for
registering the protocol handler and content handler (HTML5 spec is
here
).
It was implemented a while ago, unfortunately neither Chrome nor Safari
don't actually implement these. So they are exposed to JS and do nothing
when called. There is some level of checks for parameter values but past
those checks there is no implementation for Chrome. I've tested Safari 5 and
it does not implement it. FF has the implementation since v3 I believe.

It is not optimal to expose the methods but dont't have actual
implementation (it screws up the feature detection), so I'm thinking about
either removing those altogether (until the time someone wants to implement
them for real, they are easy to add back) or adding a pair of #ifdefs around
each of those methods. I'd lean to the removal, unless there is a port that
has work ongoing or planned soon for those implementations.

Does anybody vote for #ifdefs?

Thanks,
Dmitry



These are the methods in question:

Navigator.idl


> interface [

] *Navigator* {


> 


> void *registerProtocolHandler*(in DOMString scheme, in DOMString
> url, in DOMString title)

raises(DomException);



void *registerContentHandler*(in DOMString mimeType, in DOMString
> url, in DOMString title)

raises(DomException);

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

Re: [webkit-dev] increase the number of tests before bailing?

[Ojan Vafai]

On Wed, Jun 16, 2010 at 3:27 PM, Maciej Stachowiak  wrote:

> On Jun 16, 2010, at 2:04 PM, Eric Seidel wrote:
>
> > We could add a separate option to DumpRenderTree to disable
> > ReportCrash (sign up for all the crashing signals and simply exit(2)
> > or similar).  That would be useful in many instances besides the bots.
> >
> > Yes, --exit-after-N-failures was designed to prevent crashers from
> > eating the bots.
>
> I think --exit-after-n-crashes is probably the most expedient solution to
> the problem.
>

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

Re: [webkit-dev] Chromium bots red; does someone know how to fix it?

[David Levin]

Mr. Glazkov is on it.


On Wed, Jul 7, 2010 at 12:41 PM, Adam Barth  wrote:

> I think Yaar might be a good contact person.
>
> Adam
>
>
> On Wed, Jul 7, 2010 at 12:40 PM, Darin Adler  wrote:
> > Who has the knowledge and access needed to fix problems like this?
> >
> > svn: Working copy
> '/Users/cltbld/Desktop/BuildSlaveData/WebKit-BuildSlave/chromium-mac-release/build/WebKit/chromium/sdch/open-vcdiff'
> locked
> > svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
> details)
> >
> > svn: Working copy
> '/WebKit-BuildSlave/chromium-linux-release/build/WebKit/chromium/third_party'
> locked
> > svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
> details)
> >
> > svn: Working copy
> '/WebKit-BuildSlave/chromium-linux-release-tests/build/WebKit/chromium/tools/gyp'
> locked
> > svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
> details)
> >
> > Because of this the Chromium bots aren’t building, so I may be breaking
> Chromium left and right!
> >
> >-- Darin
> >
> > ___
> > 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] Chromium bots red; does someone know how to fix it?

[Dimitri Glazkov]

I'll fix. Sorry about that.

:DG<

On Wed, Jul 7, 2010 at 12:40 PM, Darin Adler  wrote:
> Who has the knowledge and access needed to fix problems like this?
>
> svn: Working copy 
> '/Users/cltbld/Desktop/BuildSlaveData/WebKit-BuildSlave/chromium-mac-release/build/WebKit/chromium/sdch/open-vcdiff'
>  locked
> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
>
> svn: Working copy 
> '/WebKit-BuildSlave/chromium-linux-release/build/WebKit/chromium/third_party' 
> locked
> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
>
> svn: Working copy 
> '/WebKit-BuildSlave/chromium-linux-release-tests/build/WebKit/chromium/tools/gyp'
>  locked
> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
>
> Because of this the Chromium bots aren’t building, so I may be breaking 
> Chromium left and right!
>
>    -- Darin
>
> ___
> 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] On adding 'console.memory' API (and about the whole 'console' object.)

[Mikhail Naganov]

Hi Sam,

Can you please look at https://bugs.webkit.org/show_bug.cgi?id=41617
where I'm making memory stats reporting controlled by a preference,
and turning it off by default. You are in the CC list but for some
reason Bugzilla excluded you from the notification list when I
uploaded updated patches.

On Sat, Jun 5, 2010 at 13:24, Mikhail Naganov  wrote:
> OK, no problem with rolling it back. My apologies for acting too fast,
> I strongly believe in RERO philosophy.
>
> Can you please provide more info on how native APIs can be used for
> reporting memory usage data? That is, how a web app can signal that a
> measurement is needed to be taken at a certain point in its code?
>
> On Fri, Jun 4, 2010 at 23:26, Sam Weinig  wrote:
>>
>>
>> On Fri, Jun 4, 2010 at 12:02 PM, Ojan Vafai  wrote:
>>>
>>> On Fri, Jun 4, 2010 at 11:27 AM, Sam Weinig  wrote:

 After talking it over with some folks here at Apple, I want to formally
 object to adding the Console.memory extension to the Console object and I
 think we should remove support for Console.profiles as soon as we can.  
 They
 both provide information to users that are not generally useful (beyond the
 "continuous integration/buildbot" use-case which I think is of limited
 utility) and therefore should not be exposed to the web.
>>>
>>> Why is the continuous integration/buildbot use-case of limited utility? Or
>>> are you saying that Console.memory doesn't really support that use-case
>>> well? I think we want to make it as easy as possible for complex apps (e.g.
>>> email apps, mapping apps, etc.) to care about and monitor memory use.
>>
>> I am not saying that this API doesn't support the continuous
>> integration/buildbot use-case, or support it well, I am saying that I don't
>> think this is a use case we should be supporting in a web facing API.
>>>
>>> While I'm not convinced by the utility argument, I do buy the security
>>> argument. How would you feel about leaving the code in, but disabling it by
>>> default? Then it could be enabled by command-line or via a preference.
>>> That said, I'm OK with rolling back for now given that the code was
>>> committed without this discussion actually coming to a conclusion.
>>
>> I would rather we didn't add more #ifdefs.  Instead, this functionality
>> should be available to native APIs (I believe it already is)
>> -Sam
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Chromium bots red; does someone know how to fix it?

[Adam Barth]

I think Yaar might be a good contact person.

Adam


On Wed, Jul 7, 2010 at 12:40 PM, Darin Adler  wrote:
> Who has the knowledge and access needed to fix problems like this?
>
> svn: Working copy 
> '/Users/cltbld/Desktop/BuildSlaveData/WebKit-BuildSlave/chromium-mac-release/build/WebKit/chromium/sdch/open-vcdiff'
>  locked
> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
>
> svn: Working copy 
> '/WebKit-BuildSlave/chromium-linux-release/build/WebKit/chromium/third_party' 
> locked
> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
>
> svn: Working copy 
> '/WebKit-BuildSlave/chromium-linux-release-tests/build/WebKit/chromium/tools/gyp'
>  locked
> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
>
> Because of this the Chromium bots aren’t building, so I may be breaking 
> Chromium left and right!
>
>    -- Darin
>
> ___
> 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] Chromium bots red; does someone know how to fix it?

[Darin Adler]

Who has the knowledge and access needed to fix problems like this?

svn: Working copy 
'/Users/cltbld/Desktop/BuildSlaveData/WebKit-BuildSlave/chromium-mac-release/build/WebKit/chromium/sdch/open-vcdiff'
 locked
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)

svn: Working copy 
'/WebKit-BuildSlave/chromium-linux-release/build/WebKit/chromium/third_party' 
locked
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)

svn: Working copy 
'/WebKit-BuildSlave/chromium-linux-release-tests/build/WebKit/chromium/tools/gyp'
 locked
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)

Because of this the Chromium bots aren’t building, so I may be breaking 
Chromium left and right!

-- Darin

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

Re: [webkit-dev] WebKit2 process model

[Maciej Stachowiak]

On Jul 7, 2010, at 4:41 AM, ARaj wrote:

> Hi,
> The latest WebKit2 Windows port creates a single process for any
> number of tabs that are opened.
> Will this be changed to something like a one-process-per-tab mode?

Our short-term plans are to make the threaded and single-web-process modes of 
WebKit2 work really well - there's still significant work to make the port 
feature-complete. Once that is done, we plan to work on multiple-web-process 
mode. That mode will have some unique additional challenges.

Regards,
Maciej

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

Re: [webkit-dev] How to properly create some element nodes within webcore?

[Matt 'Murph' Finnicum]

That was it.
Thanks a million!

On Wed, Jul 7, 2010 at 12:34 PM, Sam Weinig  wrote:
>
>
> On Wed, Jul 7, 2010 at 8:30 AM, Matt 'Murph' Finnicum 
> wrote:
>>
>> I know this sounds a bit silly, but it's a simplified version of what i'm
>> doing.
>>
>> Let's say I decided to replace every webpage with "hello world". I
>> decided to do this from finishedParsing() within dom/Document.cpp:
>>
>> void Document::finishedParsing()
>> {
>>    ExceptionCode ec = 0;
>>    HTMLBodyElement* body_node = new HTMLBodyElement(bodyTag, this);
>>    setBody(body_node, ec);
>>
>>    RefPtr new_node = Text::create(this, "Hello, World");
>>    body_node -> appendChild(new_node,ec);
>>
>>    -- rest of finishedParsing as usual --
>>
>> That works fine.
>>
>> Now lets say I want it to be blue:
>>
>> void Document::finishedParsing()
>> {
>>    ExceptionCode ec = 0;
>>    HTMLBodyElement* body_node = new HTMLBodyElement(bodyTag, this);
>>    setBody(body_node, ec);
>>
>>    RefPtr new_font_node =
>> HTMLElementFactory::createHTMLElement(QualifiedName(nullAtom,
>> String("font"),nullAtom), this, 0, false);
>>
>>  static_cast(new_font_node.get())->setAttribute(String("bolor"),String("blue"),ec);
>>    RefPtr new_text_node = Text::create(this, "Hello, World");
>>    new_font_node -> appendChild(new_text_node,ec);
>>    body_node -> appendChild(new_font_node,ec);
>>
>>    --rest of finshedParsing as usual --
>>
>> Again, this works fine.
>>
>> But blue is too flashy for my taste, and I now want it to just be bolded.
>> void Document::finishedParsing()
>> {
>>    ExceptionCode ec = 0;
>>    HTMLBodyElement* body_node = new HTMLBodyElement(bodyTag, this);
>>    setBody(body_node, ec);
>>
>>    RefPtr new_bold_node =
>> HTMLElementFactory::createHTMLElement(QualifiedName(nullAtom,
>> String("b"),nullAtom), this, 0, false);
>>    RefPtr new_text_node = Text::create(this, "Hello, World");
>>    new_bold_node -> appendChild(new_text_node,ec);
>>    body_node -> appendChild(new_bold_node,ec);
>>
>>    --rest of finishedParsing as usual --
>>
>> ... nothing is bold. Other, similar elements like 'strong' 'em' 'u'
>> 'i' don't do anything.
>>
>> What am I doing wrong?
>>
>
> This is probably not working because you are not creating an Element with
> the HTML namespace.
> One thing you could try is instead of using
>  "QualifiedName(nullAtom, String("b"),nullAtom)", use HTMLNames::bTag.
> -Sam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Frustrated at inconsiderate behavior

[Maciej Stachowiak]

On Jul 7, 2010, at 9:45 AM, Alexey Proskuryakov wrote:

> 
>> I think we can improve this by having sheriff-bot say which tests
>> broke.  I bet if you saw these tests listed, you'd have realized what
>> was going one.
> 
> 
> That would be very useful indeed! It currently takes some effort to find out 
> what exactly the bot complains about.

Another possibility is for it to link to the test results page when it reports 
a failure - not as obvious as reporting the failing tests inline, but this 
would make it very convenient to look into the details of the failure.

Regards,
Maciej


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

Re: [webkit-dev] WebKit2 build system

[Kenneth Christiansen]

Currently it seems that at least icecc does not. Also, qmake which is
the build system for the Qt port does not support prefix headers
directly and we thus have to emulate it using the precompiled header
support.

Kenneth

On Wed, Jul 7, 2010 at 2:27 PM, Sam Weinig  wrote:

> It should not be necessary to use WebKitPrefix.h as a precompiled header, it
> is only necessary for it to be used a prefix header.  Does discc also not
> support prefix headers?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] STIX Fonts and MathML Tests

[Dan Bernstein]

On Jul 7, 2010, at 11:17 AM, Sausset François wrote:

> If every is OK with licenses, how DumpRenderTree needs to be modified to use 
> custom fonts?

This is where the Mac version activates test fonts:
http://trac.webkit.org/browser/trunk/WebKitTools/DumpRenderTree/mac/DumpRenderTree.mm#L218

and this is where the Windows version does it:
http://trac.webkit.org/browser/trunk/WebKitTools/DumpRenderTree/win/DumpRenderTree.cpp#L275

You will also need to modify the build system to copy the additional fonts to 
the right places.

> And where the fonts have to be stored?

Most are here:
http://trac.webkit.org/browser/trunk/WebKitTools/DumpRenderTree/fonts

Ahem is currently in
http://trac.webkit.org/browser/trunk/WebKitTools/DumpRenderTree/qt/fonts
but had better be moved to the cross-platform location.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] STIX Fonts and MathML Tests

[Sausset François]

If every is OK with licenses, how DumpRenderTree needs to be modified to use 
custom fonts?
And where the fonts have to be stored?

François Sausset


Le 7 juil. 2010 à 20:51, Dan Bernstein a écrit :

> 
> On Jul 7, 2010, at 9:57 AM, Alex Milowski wrote:
> 
>> The STIX fonts are relatively small (2.6MB for the full download) and
>> we probably don't need all of them.  Would it be acceptable to check these 
>> in like the Ahem font?
> 
> Subject to WebKit’s licensing requirements, yes.
> ___
> 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] Proposal: Rect based HitTest for a better touch experience

[Grace Kloba]

If we want to return all the nodes, it is actually a simple change as
we just remove the code to check the enclosure. But this may affect
the hit test performance.

thanks,
Grace



On Wed, Jul 7, 2010 at 5:59 AM, Antonio Gomes (:tonikitoo)
 wrote:
> In the later sample output, note that it did not reach  , whose
> boundary obvious intersects any possible given Z rect. That would
> happen if the  in case encloses the rect Z completely, and it
> would be the stop point for the hit test.
>
> In Mozilla's implementation, nodesFromRect does not care if a node
> encloses the hit test rect completely or partially. The test will
> continue until the .
>
> What would be the preferable behavior for our implementation?

 The latter behavior may actually make the method useful for things other
 than hit testing, if that sways your decision at all. I can imagine page
 authors finding it useful to be able to find out all the elements that are 
 under
 a given point (which in turn suggests that elementsFromRect with zero 
 padding
 should still find all the hit elements in z-order).
>>>
>>> Exactly the point. For hit test matters, stopping as soon as it gets
>>> fully enclosed makes total sense to me. On the other hand, as you
>>> said, I bet there might be use cases like "give me all nodes under X,
>>> Y, with padding W, H" (where they can be '0'). I thought about making
>>> this "stop" an optional flag for HitTestResult or HitTestRequest.
>>> Would it be acceptable?
>>
>> I'd resist adding this until we have a use case for it.
>
> Maybe you've already have a internal use case (see below :)
>
> Jun 16 18:04:01         tonikitoo: i need to talk to some people here
> at apple too
> Jun 16 18:04:12         tonikitoo: we've gotten a request for e.g.,
> all the nodes that intersect the visible rect
> Jun 16 18:04:16         that's a common desire
> Jun 16 18:04:20         this api kind of does that
> Jun 16 18:04:29         i think other browsers would be interested 
> too etc
>
> It would be great it we could use this opportunity to address this
> request. But, well, in order to make it work that way ("give *all*
> nodes under rect X"), there would be some less simple changes needed,
> so we can go first for with what we have working at the moment.
>
> Cheers,
>
> --
> --Antonio Gomes
> ___
> 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] Frustrated at inconsiderate behavior

[Alexey Proskuryakov]

07.07.2010, в 9:49, Jeremy Orlow написал(а):

Why did not one of those people roll the patch out when it was clear  
that there were failures and Alexey wasn't in the process of fixing  
them?



Just to avoid any misunderstanding, the best thing to do would have  
been to tell me about the problem on IRC. I wasn't around at midnight,  
when Adam noticed the problem, but I was on IRC for many hours after  
landing that patch.


- WBR, Alexey Proskuryakov

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

Re: [webkit-dev] STIX Fonts and MathML Tests

[Dan Bernstein]

On Jul 7, 2010, at 9:57 AM, Alex Milowski wrote:

> The STIX fonts are relatively small (2.6MB for the full download) and
> we probably don't need all of them.  Would it be acceptable to check these in 
> like the Ahem font?

Subject to WebKit’s licensing requirements, yes.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] How to properly create some element nodes within webcore?

[Sam Weinig]

On Wed, Jul 7, 2010 at 8:30 AM, Matt 'Murph' Finnicum wrote:

> I know this sounds a bit silly, but it's a simplified version of what i'm
> doing.
>
> Let's say I decided to replace every webpage with "hello world". I
> decided to do this from finishedParsing() within dom/Document.cpp:
>
> void Document::finishedParsing()
> {
>ExceptionCode ec = 0;
>HTMLBodyElement* body_node = new HTMLBodyElement(bodyTag, this);
>setBody(body_node, ec);
>
>RefPtr new_node = Text::create(this, "Hello, World");
>body_node -> appendChild(new_node,ec);
>
>-- rest of finishedParsing as usual --
>
> That works fine.
>
> Now lets say I want it to be blue:
>
> void Document::finishedParsing()
> {
>ExceptionCode ec = 0;
>HTMLBodyElement* body_node = new HTMLBodyElement(bodyTag, this);
>setBody(body_node, ec);
>
>RefPtr new_font_node =
> HTMLElementFactory::createHTMLElement(QualifiedName(nullAtom,
> String("font"),nullAtom), this, 0, false);
>
>  
> static_cast(new_font_node.get())->setAttribute(String("bolor"),String("blue"),ec);
>RefPtr new_text_node = Text::create(this, "Hello, World");
>new_font_node -> appendChild(new_text_node,ec);
>body_node -> appendChild(new_font_node,ec);
>
>--rest of finshedParsing as usual --
>
> Again, this works fine.
>
> But blue is too flashy for my taste, and I now want it to just be bolded.
> void Document::finishedParsing()
> {
>ExceptionCode ec = 0;
>HTMLBodyElement* body_node = new HTMLBodyElement(bodyTag, this);
>setBody(body_node, ec);
>
>RefPtr new_bold_node =
> HTMLElementFactory::createHTMLElement(QualifiedName(nullAtom,
> String("b"),nullAtom), this, 0, false);
>RefPtr new_text_node = Text::create(this, "Hello, World");
>new_bold_node -> appendChild(new_text_node,ec);
>body_node -> appendChild(new_bold_node,ec);
>
>--rest of finishedParsing as usual --
>
> ... nothing is bold. Other, similar elements like 'strong' 'em' 'u'
> 'i' don't do anything.
>
> What am I doing wrong?
>
>
This is probably not working because you are not creating an Element with
the HTML namespace.

One thing you could try is instead of using
 "QualifiedName(nullAtom, String("b"),nullAtom)", use HTMLNames::bTag.

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

Re: [webkit-dev] WebKit2 build system

[Sam Weinig]

Hi.

On Wed, Jul 7, 2010 at 7:02 AM, Balazs Kelemen  wrote:

>   Hi folks!
>
> While I worked on the Qt port of WebKit2, I faced with some build
> issues. To solve these problems it seems like common parts of WebKit2
> should change, that is why I thought that discussing them in the list
> would be useful.
> There are two main problem I see:
>  * Usage of precompiled header. Without using WebKitPrefix.h as a
> precompiled header it seems like includes are broken. The reason why I
> dislike precompiled header is that distcc does not support it.
>

It should not be necessary to use WebKitPrefix.h as a precompiled header, it
is only necessary for it to be used a prefix header.  Does discc also not
support prefix headers?


>  * Include paths. The common files in WebKit2 includes headers in the
> form #include  while the real place of the file is for
> example WebKit2/UIProcess/API/C/xyz.h. We can workaround the problem by
> copying headers into the build dir and set the includepath to contain
> it, but I do not think it is a good practice.
>
>
We should probably change the mac to have forwarding headers (as we do with
WebCore for JavaScriptCore) to avoid this.

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

Re: [webkit-dev] STIX Fonts and MathML Tests

[Alex Milowski]

On Wed, Jul 7, 2010 at 5:31 PM, Dan Bernstein  wrote:
>
> On Jul 7, 2010, at 3:48 AM, Alex Milowski wrote:
>
>> Is there any precedence for this or default policy for tests requiring
>> fonts?
>
> Yes. Some tests require the Ahem font, so the font is checked into the 
> repository and—at least on Mac OS X and Windows—DumpRenderTree activates the 
> font while running the tests.

The STIX fonts are relatively small (2.6MB for the full download) and
we probably don't
need all of them.  Would it be acceptable to check these in like the Ahem font?



-- 
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Frustrated at inconsiderate behavior

[Jeremy Orlow]

I agree with Maciej's response, but at the same time I can understand why
Adam was so frustrated.  He (and others) have pointed out stuff like this on
and off list over and over again with little apparent change...

But that's not what I'm most worried about; why this was broken in the tree
for 12 hours??  It seems like, at the very least, every single person who
committed in that time frame should have taken a look at the tree after
committing [1].  Why did not one of those people roll the patch out when it
was clear that there were failures and Alexey wasn't in the process of
fixing them?

J

[1] Yeah, in theory looking before hand and not landing while it's on fire
is better, but I'm talking about the _bare minimum_ of what should have
happened.

On Thu, Jul 8, 2010 at 12:18 AM, Adam Barth  wrote:

> Sorry for singling you out Alexey.  I was just frustrated last night.
>
> On Wed, Jul 7, 2010 at 8:58 AM, Alexey Proskuryakov  wrote:
> > 07.07.2010, в 00:47, Adam Barth написал(а):
> >> If you're tired of my complaining about the tree being red, you can
> >> skip this message.
> >
> > I understand that you're frustrated, but I think that you're
> misinterpreting what happened.
> >
> >> 1) He could have run-webkit-tests before committing his change.
> >
> > I did that. I made the mistake of running a wrong subset though (forgot
> that local xmlhttprequest tests were no longer in fast/dom).
>
> Maybe the root cause here is that the test suite takes too long to
> run?  We can make run-webkit-tests faster...
>
> >> 2) If he didn't have time to run the tests locally, he could have used
> >> the commit-queue to run-webkit-tests before it landed his patch.
> >
> > Using commit-queue while it still doesn't provide correct svn blame is
> trading short term problems for longer term ones. Yes, one can still open a
> changeset by number, but having names really helps read svn blame.
>
> This problem is now fixed thanks to William Siegrist.  Patches written
> by committers show up correctly in SVN blame and trac even if they're
> landed by the commit-queue.
>
> >> 3) He could have looked at the tree when sheriff-bot informed him that
> >> he might have broken Leopard Intel Debug by pinging him in #webkit and
> >> commenting on his bug:
> >> .
> >
> > I worked with Qt guys on fixing tests on Qt, and I watched the tree,
> which didn't show any sign of a problem from my patch at the time. Perhaps
> I'm starting to rely on sheriff bot too much - it didn't complain about any
> platforms besides Leopard Intel Debug.
>
> It only complains once to avoid spamming when it makes a mistake.
>
> > Leopard builder was seriously broken yesterday, so I didn't pay attention
> when it complained about a problem many hours later. In retrospect, that was
> a mistake.
>
> I think we can improve this by having sheriff-bot say which tests
> broke.  I bet if you saw these tests listed, you'd have realized what
> was going one.
>
> >> these failures remained in the tree until I cleaned them up
> >
> > I see that Tiger bot still has a unique failure, and will investigate it
> as soon as possible.
>
> Thanks.
>
> 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] Frustrated at inconsiderate behavior

[Alexey Proskuryakov]

07.07.2010, в 9:18, Adam Barth написал(а):


This problem is now fixed thanks to William Siegrist.  Patches written
by committers show up correctly in SVN blame and trac even if they're
landed by the commit-queue.


That's good to know, I'll try that next time.


I think we can improve this by having sheriff-bot say which tests
broke.  I bet if you saw these tests listed, you'd have realized what
was going one.



That would be very useful indeed! It currently takes some effort to  
find out what exactly the bot complains about.


- WBR, Alexey Proskuryakov


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

Re: [webkit-dev] STIX Fonts and MathML Tests

[Dan Bernstein]

On Jul 7, 2010, at 3:48 AM, Alex Milowski wrote:

> Is there any precedence for this or default policy for tests requiring
> fonts?

Yes. Some tests require the Ahem font, so the font is checked into the 
repository and—at least on Mac OS X and Windows—DumpRenderTree activates the 
font while running the tests.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Frustrated at inconsiderate behavior

[Adam Barth]

Sorry for singling you out Alexey.  I was just frustrated last night.

On Wed, Jul 7, 2010 at 8:58 AM, Alexey Proskuryakov  wrote:
> 07.07.2010, в 00:47, Adam Barth написал(а):
>> If you're tired of my complaining about the tree being red, you can
>> skip this message.
>
> I understand that you're frustrated, but I think that you're misinterpreting 
> what happened.
>
>> 1) He could have run-webkit-tests before committing his change.
>
> I did that. I made the mistake of running a wrong subset though (forgot that 
> local xmlhttprequest tests were no longer in fast/dom).

Maybe the root cause here is that the test suite takes too long to
run?  We can make run-webkit-tests faster...

>> 2) If he didn't have time to run the tests locally, he could have used
>> the commit-queue to run-webkit-tests before it landed his patch.
>
> Using commit-queue while it still doesn't provide correct svn blame is 
> trading short term problems for longer term ones. Yes, one can still open a 
> changeset by number, but having names really helps read svn blame.

This problem is now fixed thanks to William Siegrist.  Patches written
by committers show up correctly in SVN blame and trac even if they're
landed by the commit-queue.

>> 3) He could have looked at the tree when sheriff-bot informed him that
>> he might have broken Leopard Intel Debug by pinging him in #webkit and
>> commenting on his bug:
>> .
>
> I worked with Qt guys on fixing tests on Qt, and I watched the tree, which 
> didn't show any sign of a problem from my patch at the time. Perhaps I'm 
> starting to rely on sheriff bot too much - it didn't complain about any 
> platforms besides Leopard Intel Debug.

It only complains once to avoid spamming when it makes a mistake.

> Leopard builder was seriously broken yesterday, so I didn't pay attention 
> when it complained about a problem many hours later. In retrospect, that was 
> a mistake.

I think we can improve this by having sheriff-bot say which tests
broke.  I bet if you saw these tests listed, you'd have realized what
was going one.

>> these failures remained in the tree until I cleaned them up
>
> I see that Tiger bot still has a unique failure, and will investigate it as 
> soon as possible.

Thanks.

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

Re: [webkit-dev] Frustrated at inconsiderate behavior

[Alexey Proskuryakov]

07.07.2010, в 00:47, Adam Barth написал(а):

> If you're tired of my complaining about the tree being red, you can
> skip this message.


I understand that you're frustrated, but I think that you're misinterpreting 
what happened.

> 1) He could have run-webkit-tests before committing his change.

I did that. I made the mistake of running a wrong subset though (forgot that 
local xmlhttprequest tests were no longer in fast/dom).

> 2) If he didn't have time to run the tests locally, he could have used
> the commit-queue to run-webkit-tests before it landed his patch.

Using commit-queue while it still doesn't provide correct svn blame is trading 
short term problems for longer term ones. Yes, one can still open a changeset 
by number, but having names really helps read svn blame.

> 3) He could have looked at the tree when sheriff-bot informed him that
> he might have broken Leopard Intel Debug by pinging him in #webkit and
> commenting on his bug:
> .

I worked with Qt guys on fixing tests on Qt, and I watched the tree, which 
didn't show any sign of a problem from my patch at the time. Perhaps I'm 
starting to rely on sheriff bot too much - it didn't complain about any 
platforms besides Leopard Intel Debug.

Leopard builder was seriously broken yesterday, so I didn't pay attention when 
it complained about a problem many hours later. In retrospect, that was a 
mistake.

> these failures remained in the tree until I cleaned them up


I see that Tiger bot still has a unique failure, and will investigate it as 
soon as possible.

- WBR, Alexey Proskuryakov

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

Re: [webkit-dev] STIX Fonts and MathML Tests

[Antonio Gomes (:tonikitoo)]

Hi Alex.

On QtWebKit, it is requered a set of fonts to be available on the
local system, and WEBKIT_TESTFONT environment variable to be exported
pointing to the font location path. See [1].

[1] 
http://trac.webkit.org/wiki/QtWebKitContrib#InstallingthelayouttestfontsUsingrun-webkit-tests

In case it is unset, all tests will just crash. For that to go smooth,
we provide a git repository for the requered fonts, so one can easily
clone and do the set up steps by himself.

Would something like this work in your case?

On Wed, Jul 7, 2010 at 6:48 AM, Alex Milowski  wrote:
> Sausset François has been looking at using the newly released STIX
> fonts [1] for the MathML implementation.  If we start requiring STIX
> font support for MathML, how do we guarantee:
>
>   * these fonts exist in the build process so the tests will succeed,
>   * these fonts exist on the target platform.
>
> Certainly, we can create a stylesheet that degrades when the
> fonts are missing.  We could also do something with web fonts [2]
> but that seems like a bad idea for WebKit as a core platform for
> a variety of browsers.
>
> In general, we're working towards a point where we'd like to turn
> on MathML by default and, at that point, the tests must be run.  For
> the tests to succeed, we'd need the STIX fonts available.
>
> Is there any precedence for this or default policy for tests requiring
> fonts?
>
> [1] http://www.stixfonts.org/
> [2] http://hublog.hubmed.org/archives/001931.html
>
> --
> --Alex Milowski
> "The excellence of grammar as a guide is proportional to the paucity of the
> inflexions, i.e. to the degree of analysis effected by the language
> considered."
>
> Bertrand Russell in a footnote of Principles of Mathematics
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>



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

[webkit-dev] How to properly create some element nodes within webcore?

[Matt 'Murph' Finnicum]

I know this sounds a bit silly, but it's a simplified version of what i'm doing.

Let's say I decided to replace every webpage with "hello world". I
decided to do this from finishedParsing() within dom/Document.cpp:

void Document::finishedParsing()
{
ExceptionCode ec = 0;
HTMLBodyElement* body_node = new HTMLBodyElement(bodyTag, this);
setBody(body_node, ec);

RefPtr new_node = Text::create(this, "Hello, World");
body_node -> appendChild(new_node,ec);

-- rest of finishedParsing as usual --

That works fine.

Now lets say I want it to be blue:

void Document::finishedParsing()
{
ExceptionCode ec = 0;
HTMLBodyElement* body_node = new HTMLBodyElement(bodyTag, this);
setBody(body_node, ec);

RefPtr new_font_node =
HTMLElementFactory::createHTMLElement(QualifiedName(nullAtom,
String("font"),nullAtom), this, 0, false);

static_cast(new_font_node.get())->setAttribute(String("bolor"),String("blue"),ec);
RefPtr new_text_node = Text::create(this, "Hello, World");
new_font_node -> appendChild(new_text_node,ec);
body_node -> appendChild(new_font_node,ec);

--rest of finshedParsing as usual --

Again, this works fine.

But blue is too flashy for my taste, and I now want it to just be bolded.
void Document::finishedParsing()
{
ExceptionCode ec = 0;
HTMLBodyElement* body_node = new HTMLBodyElement(bodyTag, this);
setBody(body_node, ec);

RefPtr new_bold_node =
HTMLElementFactory::createHTMLElement(QualifiedName(nullAtom,
String("b"),nullAtom), this, 0, false);
RefPtr new_text_node = Text::create(this, "Hello, World");
new_bold_node -> appendChild(new_text_node,ec);
body_node -> appendChild(new_bold_node,ec);

--rest of finishedParsing as usual --

... nothing is bold. Other, similar elements like 'strong' 'em' 'u'
'i' don't do anything.

What am I doing wrong?

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

[webkit-dev] WebKit2 build system

[Balazs Kelemen]

   Hi folks!

While I worked on the Qt port of WebKit2, I faced with some build
issues. To solve these problems it seems like common parts of WebKit2
should change, that is why I thought that discussing them in the list
would be useful.
There are two main problem I see:
  * Usage of precompiled header. Without using WebKitPrefix.h as a
precompiled header it seems like includes are broken. The reason why I
dislike precompiled header is that distcc does not support it.
  * Include paths. The common files in WebKit2 includes headers in the
form #include  while the real place of the file is for
example WebKit2/UIProcess/API/C/xyz.h. We can workaround the problem by
copying headers into the build dir and set the includepath to contain
it, but I do not think it is a good practice.

I think WebKit2 would be more portable if we could solve these problems.
Please share your thoughts with me!
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Proposal: Rect based HitTest for a better touch experience

[Antonio Gomes (:tonikitoo)]

 In the later sample output, note that it did not reach  , whose
 boundary obvious intersects any possible given Z rect. That would
 happen if the  in case encloses the rect Z completely, and it
 would be the stop point for the hit test.

 In Mozilla's implementation, nodesFromRect does not care if a node
 encloses the hit test rect completely or partially. The test will
 continue until the .

 What would be the preferable behavior for our implementation?
>>>
>>> The latter behavior may actually make the method useful for things other
>>> than hit testing, if that sways your decision at all. I can imagine page
>>> authors finding it useful to be able to find out all the elements that are 
>>> under
>>> a given point (which in turn suggests that elementsFromRect with zero 
>>> padding
>>> should still find all the hit elements in z-order).
>>
>> Exactly the point. For hit test matters, stopping as soon as it gets
>> fully enclosed makes total sense to me. On the other hand, as you
>> said, I bet there might be use cases like "give me all nodes under X,
>> Y, with padding W, H" (where they can be '0'). I thought about making
>> this "stop" an optional flag for HitTestResult or HitTestRequest.
>> Would it be acceptable?
>
> I'd resist adding this until we have a use case for it.

Maybe you've already have a internal use case (see below :)

Jun 16 18:04:01 tonikitoo: i need to talk to some people here
at apple too
Jun 16 18:04:12 tonikitoo: we've gotten a request for e.g.,
all the nodes that intersect the visible rect
Jun 16 18:04:16 that's a common desire
Jun 16 18:04:20 this api kind of does that
Jun 16 18:04:29 i think other browsers would be interested too 
etc

It would be great it we could use this opportunity to address this
request. But, well, in order to make it work that way ("give *all*
nodes under rect X"), there would be some less simple changes needed,
so we can go first for with what we have working at the moment.

Cheers,

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

[webkit-dev] WebKit2 process model

[ARaj]

Hi,
The latest WebKit2 Windows port creates a single process for any
number of tabs that are opened.
Will this be changed to something like a one-process-per-tab mode?

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

[webkit-dev] Add support for RefTest

[Hayato Ito]

Hi,

I'm planning to add support for 'Reftest' to WebKit.

Reftest is currently used in Mozilla and makes it possible to write HTML
tests where the reference rendering is also in HTML.
You can easily write tests that work no matter what fonts are present, or
what the platform the form controls look like, and so on.

For more information, please see the related bugzilla entry and a draft
plan.
https://bugs.webkit.org/show_bug.cgi?id=36065
https://docs.google.com/document/edit?id=1bwAzqOKfyB97rSIyLQ5ER6YG6-cEUa34xJ8KKgvdc0o&hl=en&authkey=CL39hMMB

Any suggestions and advice are welcome.


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

[webkit-dev] STIX Fonts and MathML Tests

[Alex Milowski]

Sausset François has been looking at using the newly released STIX
fonts [1] for the MathML implementation.  If we start requiring STIX
font support for MathML, how do we guarantee:

   * these fonts exist in the build process so the tests will succeed,
   * these fonts exist on the target platform.

Certainly, we can create a stylesheet that degrades when the
fonts are missing.  We could also do something with web fonts [2]
but that seems like a bad idea for WebKit as a core platform for
a variety of browsers.

In general, we're working towards a point where we'd like to turn
on MathML by default and, at that point, the tests must be run.  For
the tests to succeed, we'd need the STIX fonts available.

Is there any precedence for this or default policy for tests requiring
fonts?

[1] http://www.stixfonts.org/
[2] http://hublog.hubmed.org/archives/001931.html

-- 
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Frustrated at inconsiderate behavior

[Maciej Stachowiak]

Thank you for fixing the problem.

Did you try talking to Alexey directly about this? Or to someone else who may 
be familiar with the situation? It's usually better to try steps like that 
before calling someone out on the mailing list. And if you do need to bring 
something to wider attention, perhaps you could consider a less strident tone. 
In the WebKit project, we prefer to resolve disputes calmly and respectfully, 
especially among longtime valued contributors such as Alexey and yourself. I 
realize that at times, contributors can feel frustrated, but let's try to keep 
the project mailing list a happy place.

Sincerely,
Maciej

On Jul 7, 2010, at 12:47 AM, Adam Barth wrote:

> If you're tired of my complaining about the tree being red, you can
> skip this message.
> 
> Today Alexey checked in ,
> which broke two tests on every port.  12 hours later, these failures
> remained in the tree until I cleaned them up.  This mess could have
> been avoided in a number of ways:
> 
> 1) He could have run-webkit-tests before committing his change.
> 2) If he didn't have time to run the tests locally, he could have used
> the commit-queue to run-webkit-tests before it landed his patch.
> 3) He could have looked at the tree when sheriff-bot informed him that
> he might have broken Leopard Intel Debug by pinging him in #webkit and
> commenting on his bug:
> .
> 
> Is this acceptable behavior?
> 
> http://webkit.org/coding/contributing.html clearly says to "run the
> layout tests using the run-webkit-tests script and make sure they all
> pass."  That page also says:
> 
> [[
> In either case, your responsibility for the patch does not end with
> the patch landing in the tree. There may be regressions from your
> change or additional feedback from reviewers after the patch has
> landed. You can watch the tree at build.webkit.org to make sure your
> patch builds and passes tests on all platforms. It is your
> responsibility to be available should regressions arise and to respond
> to additional feedback that happens after a check-in.
> ]]
> 
> Are there consequences for breaking these rules?
> 
> 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

[webkit-dev] Frustrated at inconsiderate behavior

[Adam Barth]

If you're tired of my complaining about the tree being red, you can
skip this message.

Today Alexey checked in ,
which broke two tests on every port.  12 hours later, these failures
remained in the tree until I cleaned them up.  This mess could have
been avoided in a number of ways:

1) He could have run-webkit-tests before committing his change.
2) If he didn't have time to run the tests locally, he could have used
the commit-queue to run-webkit-tests before it landed his patch.
3) He could have looked at the tree when sheriff-bot informed him that
he might have broken Leopard Intel Debug by pinging him in #webkit and
commenting on his bug:
.

Is this acceptable behavior?

http://webkit.org/coding/contributing.html clearly says to "run the
layout tests using the run-webkit-tests script and make sure they all
pass."  That page also says:

[[
In either case, your responsibility for the patch does not end with
the patch landing in the tree. There may be regressions from your
change or additional feedback from reviewers after the patch has
landed. You can watch the tree at build.webkit.org to make sure your
patch builds and passes tests on all platforms. It is your
responsibility to be available should regressions arise and to respond
to additional feedback that happens after a check-in.
]]

Are there consequences for breaking these rules?

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