I have a (non-sustainable) hack in place where I have downgraded the
version number on the commit-queue's CoreVideo.framework to trick
WebKit into disabling hardware compositing (due to radar 7969612), and
I've hacked the commit-queue not to run compositing/iframes tests
(since they fail when HW co
It seems reasonable to me that the autofilled property is only cleared when the
text is modified by the user. Since it is a visible change in the behavior,
there's always a chance that it will not sit well with everyone and we might
eventually have to allow for both behaviors somehow. But it see
In the last 3 days the commit-queue has not been keeping up. Due
partially to tree redness, and partially to graphics card troubles on
the machine (https://bugs.webkit.org/show_bug.cgi?id=38912) . The
tree is green now, but I do not expect the commit-queue to be able to
keep up until we solve the
On Tue, May 11, 2010 at 10:06 AM, David Levin wrote:
>
>- Also, I like the stability of my revision control system and
>prepare-ChangeLog (neither of which is changed very often or much) --
> unlike
>webkit-patch which changes frequently.
>
> Having tools frequently change out from u
http://build.webkit.org/console
If someone with a Gtk build could post come baselines that would be fantastic!
-eric
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On Tue, May 11, 2010 at 2:30:45 PM, Geoffrey Garen wrote:
> I don't know how to do either of these steps in an easy way:
>
> 1. Once I have a patch with a ChangeLog, say, "File a new
> bug and upload this patch for review." (Bonus points if the
> tool automatically made the first line of the Cha
On Tue, May 11, 2010 at 10:11 PM, Geoffrey Garen wrote:
> > We require a ChangeLog for every patch. Isn't that a TPS report?
>
> No. A ChangeLog is much less time-consuming to manage.
>
For me, letting webkit-patch make the bug for me and post updates to the bug
is maybe 10-15 seconds longer th
7 matches
Mail list logo
