Adam Barth announced last week that he'd wrapped bugzilla-tool in a
shell-script and created the commit-queue. We're now running this queue
every day, but not overnight yet.
The commit-queue script is super-simple. It wakes up every 10 minutes and
runs:
bugzilla-tool bugs-to-commit | xargs -n1 b
There were a couple patches which contributed to today's redness. Thanks
for the rollout!
the commit-queue is back up and running. I'm still fixing bugs in it to
make it more robust.
-eric
On Wed, Aug 12, 2009 at 3:04 PM, Anders Carlsson wrote:
> I rolled that patch out.
>
> Anders
>
> On Au
I just closed out many of the GDOM bugs for patch spam after emailing the
author of these patches.
The proper process for getting code into WebKit does not involve uploading
15 unexplained patches at once. That tends to result only in annoying
reviewers and getting you banned from the bug tracker.
The tree is just too red today for the commit queue to work. :(
Waiting for things to green up before I try again.
-eric
On Tue, Aug 11, 2009 at 12:20 PM, Eric Seidel wrote:
> The commit-queue is back up and running on my machine. I've fixed a few
> bugs along the way and will be p
webkit-help is the list you want, not webkit-dev.
But to answer your question, see Document::elementAtPoint(x, y).
-eric
On Wed, Aug 12, 2009 at 12:32 AM, Chris Mumford wrote:
> Hi:
>
> I'm trying to figure out the DOM element at a certain (x,y) point. To do
> this I'm using Document::prepareMo
Didn't we just have a thread about this a couple weeks ago, and decided that
it's better if the Compiler checked/documented this sort of thing? Oliver
had worked on some classes to enforce null checking iirc...
On Tue, Aug 11, 2009 at 3:55 PM, Maciej Stachowiak wrote:
>
> On Aug 11, 2009, at 3:
queue is
back down to 0. Hopefully by end of day.
-eric
On Sat, Aug 8, 2009 at 10:32 AM, Adam Barth wrote:
> Thanks Eric. You're in a good position to improve the tool in the process.
> :)
>
> Adam
>
>
> On Sat, Aug 8, 2009 at 10:28 AM, Eric Seidel wrote:
> > I
It sounds like this mail is specifically requesting one thing: that .lib
files be included in windows nightlies. Is that correct? (I don't know
what a .lib file is enough to know if this is a good idea or not.)
If that is your request, please file a bug.
http://webkit.org/quality/reporting.html
I'll take care of it. I have bugzilla-tool bugs to fix anyway.
-eric
On Sat, Aug 8, 2009 at 9:50 AM, Adam Barth wrote:
> Hi webkit-dev,
>
> I'm going to be in Canada next week for USENIX Security, so I won't be
> able to run the commit-queue script. If you'd like to try your hand
> at running
I should also note, that kudos to the Haiku folks, the patches have gotten
better (and smaller!) even over the last 24 hours after a few rounds of
r-'ing
-eric
On Fri, Aug 7, 2009 at 2:51 PM, Eric Seidel wrote:
> I went through every patch in the queue again today (obviously others hav
geLog, and impossible to post a patch that doesn't pass
check-webkit-style.
-eric
On Thu, Aug 6, 2009 at 7:57 PM, Eric Seidel wrote:
> We're down to 60 now. 84 when I started my crusade (shortly before sending
> the previous mail).
> https://bugs.webkit.org/buglist.cgi?field0
Wrong list. webkit-h...@lists.webkit.org is what you want.
On Fri, Aug 7, 2009 at 10:12 AM, Piotr Dobrogost wrote:
> Hi
>
> What level of CSS selectors does WebKit support?
> Thanks in advance.
>
>
> --
> Piotr Dobrogost
> *** curlpp.org - c++ wrapper for libcurl ***
>
>
ug 6, 2009 at 6:32 PM, Eric Seidel wrote:
> The queue is out of control again. :(
>
> https://bugs.webkit.org/buglist.cgi?field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=review%3F
>
> I've tried. But I just can't bring it down alone. :( It's full of l
Why do we have patches for WAP support?
WAP is big in asian markets, yes?
Can someone provide some data as to how big? Is the market for WAP growing?
It seems that the various posted -wap- patches have limited utility for the
rest of WebKit. It seems to me (although I am the first to admit ignor
The queue is out of control again. :(
https://bugs.webkit.org/buglist.cgi?field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=review%3F
I've tried. But I just can't bring it down alone. :( It's full of lots of
port and other fringe related patches. Many of which need to be r-'d.
-eric
__
OK, per the discussion, I will add a commit-queue=? flag for Adam's testing.
If we like it, we can keep it. If not, we can kill it.
-eric
On Mon, Aug 3, 2009 at 9:43 AM, Maciej Stachowiak wrote:
>
> On Aug 1, 2009, at 8:41 PM, Adam Barth wrote:
>
> On Sat, Aug 1, 2009 at 1:13 PM, David Kilzer
LayoutTests\fast took 378.7 seconds to run 3695 tests.
> LayoutTests\http took 396.9 seconds to run 632 tests.
> LayoutTests\media took 596.3 seconds to run 84 tests.
>
> This might be Chromium specific, but I'm seeing many of the the media
> layout tests taking 8-10 seconds
2009 at 11:21 PM, Maciej Stachowiak wrote:
>
> On Jul 31, 2009, at 10:25 PM, Eric Seidel wrote:
>
> 681.70s total testing time
>>
>> That's 11.5 minutes for every patch I want to land. (because I run the
>> layout tests before landing anything, as part of bugzil
681.70s total testing time
That's 11.5 minutes for every patch I want to land.
(because I run the layout tests before landing anything, as part of
bugzilla-tool).
I'm very interested in any suggestions folks have to make that number
smaller. I know Chromium runs the layout tests in parallel usi
search bugs.webkit.orghttps://bugs.webkit.org/show_bug.cgi?id=3251
On Wed, Jul 29, 2009 at 11:29 AM, Chi-Wai Lau wrote:
> Hello there,
>
> I am new here. I am interested in the current progress of integrating
> MathML in Webkit. Could somebody give me a quick update?
>
> Thanks in advance!
>
> C
It just occurred to me that we have a lot of places in WebKit were we
ASSERT(foo) (where foo is some passed in Foo* pointer which should never be
NULL).
Maybe it would be cleaner/better/whatever if we instead used a template to
do this ASSERTing in a centralized place. The primary advantage would
Seems like --clean needs to know how to delete Debug/DerivedSources/*
On Tue, Jul 28, 2009 at 8:57 AM, Alexey Proskuryakov wrote:
>
> 28.07.2009, в 8:51, Thomas Brodt написал(а):
>
>> Should I cleanup more than --clean?
>
>
> I just wipe the WebKitBuild directory when I need to rebuild.
>
> - WBR,
at 10:07 AM, Darin Adler wrote:
> On Jul 23, 2009, at 5:56 PM, Eric Seidel wrote:
>
>> It sounds like you agree with me, that the Document should have a way to
>> get to the JSDOMGlobalObject w/o having to go through the Frame. Am I
>> understanding correctly?
>
> Y
Zecke, you are great
you made my day with your note
k, thx, bai. -eric
On Thu, Jul 23, 2009 at 7:27 PM, Holger Freyther wrote:
> On Thursday 23 July 2009 18:31:32 Luke Kenneth Casson Leighton wrote:
>
>> i trust that this comprehensive answer illustrates to you that it was,
>> although extremely
understanding correctly?
Currently Document owns the DOMWindow. However there is no way to get
from DOMWindow* to JSDOMWindow* w/o going through the Frame.
-eric
On Thu, Jul 23, 2009 at 5:50 PM, Maciej Stachowiak wrote:
>
> On Jul 23, 2009, at 5:38 PM, Eric Seidel wrote:
>
>> I&#x
I'm trying to get a JSDOMGlobalObject from a Node*. A Node* should
always have one, but our current path through Frame* can sometimes
fail.
-eric
On Thu, Jul 23, 2009 at 5:33 PM, Maciej Stachowiak wrote:
>
> On Jul 23, 2009, at 5:23 PM, Eric Seidel wrote:
>
> It seems all looku
It seems all lookups of the current globalObject go through the frame.
document()->frame()->script()->globalObject() is one example.
Another:
JSValue toJS(ExecState*, DOMWindow* domWindow)
{
if (!domWindow)
return jsNull();
Frame* frame = domWindow->frame();
if (!frame)
Ah! Nevermind. nameGetter is static.
static JSC::JSValue nameGetter(JSC::ExecState*, const
JSC::Identifier&, const JSC::PropertySlot&);
-eric
On Thu, Jul 23, 2009 at 3:04 PM, Eric Seidel wrote:
> Is it possible to move a name getter onto a different JavaScript object?
&g
Is it possible to move a name getter onto a different JavaScript object?
Example:
JSValue JSHTMLFormElement::nameGetter(ExecState* exec, const
Identifier& propertyName, const PropertySlot& slot)
{
JSHTMLElement* jsForm =
static_cast(asObject(slot.slotBase()));
HTMLFormElement* form = stat
;d code for now. It doesn't hurt that a superclass also
overrides createStructure().
Almost seems like these flags should be in a separate function, and
that there should be one shared createStructure().
On Wed, Jul 22, 2009 at 5:35 PM, Eric Seidel wrote:
> Now from the right email address.
Now from the right email address.
On Wed, Jul 22, 2009 at 5:34 PM, Eric Seidel wrote:
> http://trac.webkit.org/changeset/45938 added DOMConstructorObject, but
> did not change most constructors (the autogen'd ones).
>
>
> I'm now removing the autogen'd
Ideally you should be able to just register JavaScript ondrop
listeners. Depends on what you need to listen for.
-eric
On Fri, Jul 17, 2009 at 1:15 PM, Mike Pinkerton wrote:
> Note that Firefox is moving towards a similar "out of process" model
> for plugins and rendering
>
> On Fri, Jul 17, 200
I've made some initial stabs:
https://bugs.webkit.org/show_bug.cgi?id=27276
The bindings need a bunch more cleanup before we can do much more than
that. I've started filing bugs about the cleanup.
On Tue, Jul 14, 2009 at 12:41 PM, Geoffrey Garen wrote:
>>> Also, once we've established the model,
On Mon, Jul 13, 2009 at 2:18 PM, Sam Weinig wrote:
> I discussed this a bit with Darin and Geoff, and we came to the conclusion
> that the correct fix is to have each JS DOMObject store a JSGlobalObject
> pointer and augment the toJS methods to pass a global object instead of an
> ExecState (close
On Mon, Jul 13, 2009 at 1:36 PM, Geoffrey Garen wrote:
> I'm not sure what you guys have been meaning by the phrase "correct heap."
> Barring workers, all WebCore objects are allocated from the same heap.
We had wrongly assumed that each window got its own. OK. This
invalidates using heaps as a
Re-sending from correct address.
On Mon, Jul 13, 2009 at 1:23 PM, Eric Seidel wrote:
> I'm looking at this more today.
>
> I'm first fixing JSCell::new subclasses to make sure they're always
> allocating in the correct heap. If we're to map from objects to the
&
Geoff, Gavin, Sam, Maciej (and any other JSC experts):
Adam and I are fixing:
https://bugs.webkit.org/show_bug.cgi?id=27088
Fix: toJS needs to use the correct global object. The correct global
object should come from whatever "this" is calling into the native
code which is using toJS.
(e.g. docu
that's so much contributer failure as it
is tools failure. The tools should make it easy to do the "right
thing" and hard to post patches which are just gonna get r-'d.
-eric
On Tue, Jul 7, 2009 at 10:42 AM, Eric Seidel wrote:
> I had intended to summarize this long thread which
I had intended to summarize this long thread which I started. But
I've since realized that we're mostly bikeshedding here, so there
isn't much actionable takeaway. :( Thank you to all of you for your
thoughtful responses!
I'm not at all attached to the current YELLING CHANGELOG TEMPLATE. :)
But
Re-sent from the proper email address.
On Mon, Jul 6, 2009 at 5:37 PM, Eric Seidel wrote:
> Adam and I talked about this feature more in person last night.
> I agree with Oliver. Like any feature added to WebCore, it should work
> with the default compiled JS engine JavaScriptCore.
&
I wondered after auto-complete failed me this week, and I accidentally
sent Peter's nomination to webkit-dev instead of webkit-reviewers, why
do we have webkit- at the start of all are lists? That's just 6 more
characters I have to type to make sure that I auto-complete correctly.
:)
Couldn't the
I would like to nominate Peter Kasting as a WebKit reviewer.
Peter is most well known for all his work on the Image Decoders. At
this point, I believe he's webkit's #1 expert on how they work. Peter
also worked on other random bits of WebCore under the Don Gibson
pseudonym before Chrome was publ
MORE INFORMATION
FILE AND FUNCTION CHANGES SHOULD BE DESCRIBED NEXT TO NAMES BELOW
Seems kinda verbose. Hopefully people will actually read
http://webkit.org/coding/contributing.html
-eric
On Thu, Jul 2, 2009 at 12:22 AM, Alexey Proskuryakov wrote:
>
> 02.07.2009, в 9:44, Eric Seide
t.org/changeset/45464
prepare-ChangeLog now takes an optional --bug= argument and is able to
fill in more than before:
% prepare-ChangeLog --bug=26383
Running status to find changed, added, or removed files.
Reviewing diff to determine which lines changed.
Change author: Eric Seidel .
Description
This will not affect most developers. Only casual contributers who
were manually editing their ChangeLog entries to include their email
address and real names (and often forgetting to do so, thus resulting
in a r-).
-eric
On Wed, Jul 1, 2009 at 4:34 PM, Eric Seidel wrote:
> Be aware of t
Be aware of this change:
http://trac.webkit.org/changeset/45455
prepare-ChangeLog will now fail if it can't determine your email
address or full name.
This will hopefully prevent your patches from being r-'d for lack of
email address or full name in the future. :)
-eric
_
Wrong email address.
On Mon, Jun 29, 2009 at 4:15 PM, Eric Seidel wrote:
> Before I review the patches, I would like to see responses from other
> WebKit reviewers as to whether they agree it's OK to accept this Haiku
> port given this information.
>
> Folks?
>
>
In general we mimic native controls on all platforms. I don't think
WebKit has ever invented any controls before, but I could be wrong.
I think more interesting than a comprehensive document is individual
bugs and patches to add these. These are small features. I don't
think there is much that
400k is too large of a patch for anyone to review.
I would suggest you start by splitting out the layout test changes
from the rest of the patch. I would also suggest that you try to post
the code changes in smaller chunks. Ideal patch review size is <20k,
but that's not always possible for feat
I think this is great!
I'm a bit confused by this though:
This indicates that the src DOM attribute reflects a content attribute
named src, but that the result is a completed URL, not the raw
attribute value:
attribute [ReflectURL] DOMString src;
Why a special case for absolute URL conversio
te:
>
> On 2009-06-19, at 15:24, Gustavo Noronha wrote:
>
>> On Wed, 2009-06-17 at 11:13 -0700, Eric Seidel wrote:
>>>
>>> It would appear bugzilla is too lame to support changing flag values
>>> +/-/? are all we get. :(
>>> https://bugs.webkit.org/
nice names for all
reviewers. :)
Either way, back to real work...
-eric
On Fri, Jun 19, 2009 at 12:27 AM, Eric Seidel wrote:
> There really is no other way to describe it. Thanks to Darin for his
> un-ending reviews!
>
> (Reviews to WebCore since 2008-08-10, aka the last 10 months.)
There really is no other way to describe it. Thanks to Darin for his
un-ending reviews!
(Reviews to WebCore since 2008-08-10, aka the last 10 months.)
./reviewers.py WebCore/ChangeLog WebCore/ChangeLog-2009-06-16
Darin Adler 609
Sam Weinig 319
Eric Seidel 313
David Hyatt 236
Dan Bernstein 208
Agreed. That should just be a virtual call. I don't see any reason
for that to need to be a bit on the baseclass. I do not think that
changing ti to be a virtual call would cause a noticeable performance
change.
-eric
On Thu, Jun 18, 2009 at 7:29 PM, Roland Steiner wrote:
>
> Hi all,
>
> As I'
Oh how I wish that my @webkit.org address and gmail would get along...
-eric
-- Forwarded message --
From: Eric Seidel
Date: Thu, Jun 18, 2009 at 7:02 PM
Subject: Re: [webkit-dev] Review queue needs love
To: Adam Treat
Cc: webkit-dev@lists.webkit.org
I've gone throug
don't think Rietveld supports any sort of flags either though. I've
not looked at review board.
-eric
On Wed, Jun 17, 2009 at 8:14 AM, Maciej Stachowiak wrote:
>
> On Jun 17, 2009, at 1:39 AM, Mark Rowe wrote:
>
>>
>> On 2009-06-17, at 00:41, Eric Seidel wrote
(Maciej and I chatted about this briefly over IRC a while back.)
I think we need a new r+ state. Or at least we need more than just r=?, r-, r+.
Why? Currently r+ means at least 3 things:
1. Ready to commit if you make some mods and re-post [non-committers]
2. Ready to commit if you make some
There are 8 tests failing on windows:
* fast/dom/Window/window-onFocus.html
* fast/events/frame-click-focus.html
* http/tests/history/back-to-post.php
* http/tests/loading/deleted-host-in-resource-load-delegate-callback.html
* http/tests/media/video-play-stall.html
* media/video-loop.html
* media/v
> This something of a non-sequiter, since it is trivial to create a script to
> do the same with Bugzilla. I've heard mentions of a git-send-bugzilla
> script that does most of this already, and I'm sure it could easily be
> adapted for those preferring SVN.
https://bugs.webkit.org/show_bug.cgi?i
) empty if it were kept separate.
-eric
On Fri, May 22, 2009 at 11:22 PM, Eric Seidel wrote:
> We're down to 30 bugs:
> https://bugs.webkit.org/buglist.cgi?field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=review%3F
>
> With 36 patches total:
> curl -s "https
k reviewers
on this one.
Thanks again to those who have pitched in so far.
-eric
On Sat, May 23, 2009 at 12:20 AM, Eric Seidel wrote:
> Reviewed more before bed. We're down to:
>
> https://bugs.webkit.org/buglist.cgi?field0-0-0=flagtypes.name&type0-0-0=equals&value0-
n yesterday.
-eric
On Fri, May 22, 2009 at 7:40 PM, Maciej Stachowiak wrote:
>
> On May 22, 2009, at 2:19 AM, Eric Seidel wrote:
>
>> Update: We're down to 74 patches now.
>>
>> Thanks especially to Maciej for all his reviewing this evening:
>>
>> curl
Update: We're down to 74 patches now.
Thanks especially to Maciej for all his reviewing this evening:
curl -s "https://bugs.webkit.org/request.cgi"; | grep PDT | wc -l]
74
Still a long way to go.
-eric
On Fri, May 22, 2009 at 12:27 PM, Eric Seidel wrote:
> Our review p
Interesting analogy. However, closing means to me that the community
is done with the bug. Denying a patch because no one's working on it
anymore (aka, no one is there to respond to review comments even if
you make them) is not the same as closing a bug. There is a
"forgotten patches" link on th
g that the reviewer believes
the feature should never be committed to the tree. The review process
can consist of multiple iterations between you and the reviewer as
revisions are made to your patch.
On Fri, May 22, 2009 at 1:22 PM, Maciej Stachowiak wrote:
>
> On May 21, 2009, at 7:57 PM, E
I think it's better to get things out of the queue then to leave them rot.
Your review are most welcome. :)
-eric
On Fri, May 22, 2009 at 12:48 PM, Maciej Stachowiak wrote:
>
> On May 21, 2009, at 7:27 PM, Eric Seidel wrote:
>
>> Our review process seems to be failing. A
Our review process seems to be failing. As a reviewer, let me extend
my apologies to the WebKit community as I am part of this failure.
We have over 100 patches in the review queue at the moment:
http://webkit.org/pending-review
I've started going through the list and reviewing what patches I ca
tags use data="" not src="". Blame HTML 4.
http://www.w3.org/TR/REC-html40/struct/objects.html#h-13.3
-eric
2009/5/22 Darin Adler :
> On May 21, 2009, at 7:12 AM, naixuan guan wrote:
>
>> when I open the HTML page like follow:
>>
>>
>>
>> alert(document.StormPlayer.src);
>>
>>
>> the warning
Using google to compute the log base 2 (lg) = lg(16777271) gave me the answer.
It must have been a 24-bit bitfield. I expect this would have been
on RenderLayer, and was for saving space.
-eric
On Fri, May 15, 2009 at 2:38 AM, Eric Puidokas wrote:
> I've noticed Safari 3.2.1 has a maximum z-i
Please file a bug if you believe WebKit's behavior to be incorrect.
https://bugs.webkit.org/show_bug.cgi?id=25179
https://bugs.webkit.org/show_bug.cgi?id=14004
https://bugs.webkit.org/show_bug.cgi?id=18572
are 3 existing FPZ + SVG bugs.
-eric
On Thu, May 7, 2009 at 7:45 PM, rod wrote:
> Hi,
>
Dave, Simon, and other rendering gurus:
bool RenderObject::nodeAtPoint(const HitTestRequest&, HitTestResult&
result, int _x, int _y, int tx, int ty, HitTestAction hitTestAction)
_x, _y, tx, ty are very confusing.
As far as I can tell, _x, _y are relative to the root layer (which can
change durin
Dave, Simon (and the larger community):
I've been looking at fixing:
https://bugs.webkit.org/show_bug.cgi?id=20769
https://bugs.webkit.org/show_bug.cgi?id=14015
in SVG. A large part of the mis-match between SVG renderers and the
HTML/CSS rendering tree is the use of transforms.
In SVG, transform
I filed the hanging tests on the PPC bot under this bug:
https://bugs.webkit.org/show_bug.cgi?id=24888
I think they all may be caused by one AX crasher? But I'm not sure.
run-webkit-tests doesn't seem to be properly reporting the crasher.
-eric
2009/3/26 Eric Seidel :
> Oh, an
Seems we just got a whole bunch of leaks in WebCore:
WebCore::HTMLHtmlElement::insertedIntoDocument() |
WebCore::ApplicationCacheGroup::selectCache(WebCore::Frame*,
WebCore::KURL const&) |
WebCore::ApplicationCacheStorage::findOrCreateCacheGroup(WebCore::KURL
const&) | WebCore::ApplicationCacheSto
is just much slower?
-eric
On Thu, Mar 26, 2009 at 4:56 PM, Eric Seidel wrote:
> Seems we have quite a bit of tree redness atm. Enough that I'm a
> little scared to check in. ;)
>
> http://build.webkit.org/results/trunk-mac-intel-pixel/2933/results.html
> - fast/repai
Seems we have quite a bit of tree redness atm. Enough that I'm a
little scared to check in. ;)
http://build.webkit.org/results/trunk-mac-intel-pixel/2933/results.html
- fast/repaint/lines-with-layout-delta.htmlexpected image image
diffs 1.90% // Mitz? Hyatt?
PPC shows a bunch of failur
Sigh. Bounced again, silly gmail, the original message:
On Mon, Jan 26, 2009 at 12:09 AM, Eric Seidel wrote:
> I suggest we turn them off. I can do that from our side.
>
> The bots should also be re-configured to not try and run the layout
> tests. They could run the JavaScriptCor
By "focus rect" I of course meant "selection rects". :)
And below is my original email which probably bounced from the list:
On Mon, Jan 26, 2009 at 12:05 AM, Eric Seidel wrote:
> The SVG stuff relates to dumping the focus rect. From the diffs it
> seems that some
I'll bring them back online when I return to work on Tuesday.
-eric
On Sun, Jan 4, 2009 at 3:57 PM, Pam Greene wrote:
> On Sat, Jan 3, 2009 at 11:41 AM, Darin Adler wrote:
>> Looking at the buildbot I see a few broken regression tests:
>> fast/text/find-case-folding.html — Looks like I brok
Checking for updates as part of the WebKit Launcher (the application
which is what you run when you double-click on a nightly build) w/o
slowing down startup or modifying Safari.app is non-trivial. All the
WebKit Launcher really does is set the DYLD_FRAMEWORK_PATH correctly
to the included framewo
Performance of what? On what test?
http://trac.webkit.org/changeset/38760
doesn't touch any code. :)
-eric
On Tue, Nov 25, 2008 at 5:46 PM, Dave Cronk <[EMAIL PROTECTED]> wrote:
> webkit r38760 (11/25) degrades performance by about 5%.
> ___
> webkit
All of our chromium platform/ files are off in a separate part of our
repository, but will be moved into our WebKit vendor branch, and thus will
appear on that page soon.
http://src.chromium.org/viewvc/chrome/trunk/src/webkit/port/ (note in
particular the platform/ subdirectory)
-eric
On Wed, No
This mail displays incorrectly for me in Gmail. I'm not sure if it's
a WebKit bug or a Gmail bug. I suspect WebKit.
His bullet items are indented to the left, outside of the normal message region.
-eric
On Tue, Nov 18, 2008 at 11:11 PM, Laxmi Kumar Sahu <[EMAIL PROTECTED]> wrote:
> Hi,
>
>
>
>
I noticed today that I was the only core WebKit dev in #chromium on
FreeNode. That's *totally* fine, but I was surprised by this. I
figured we'd have more lurkers from #webkit.
I figure some of this might be due our our confusion re: the chromium
IRC channel. #chromium was over-run in the fir
e of the "required" fonts
installed, you'd get results which neither match the Apple-WebKit-Win
results or some theoretical
Apple-WebKit-using-only-windows-default-fonts results.
My apologies for any confusion my statements may have caused.
-eric
2008/10/7 Eric Seidel <[EMAIL PROT
If you search the web for WEBKIT_TESTFONTS you may be able to find a
copy of the fonts you need.
It's kinda lame that the current set of windows layout tests requires
these fonts. Eventually I would like to see a set of results checked
in which do not require Apple-provided fonts, but right now t
Neat.
Related, here are the graphs which Chromium uses:
http://build.chromium.org/buildbot/perf/dashboard/overview.html
Those are generated by Google's buildbots. As you can see there was a
major regression yesterday when we landed the WebKit merge. :) Our
tree is closed until we fix it.
I lik
According to the WebKit style http://webkit.org/coding/coding-style.html
Names: 10. Enum members should user InterCaps with an initial capital letter.
Our enums seem to use every style imaginable:
enum EditorDeleteAction {
deleteSelectionAction,
deleteKeyAction,
forwardDeleteKeyActio
Sam and I talked about this at length over coffee this evening.
He and I agreed, this conversation should be less about #ifdefs and
more about abstractions. I'm sure I'm clear on which abstractions we
need for Chromium (beyond ScriptController, and GraphicsContext),
certainly not as clear as Dari
I think this is best discussed as individual patches. I would
encourage Amanda (and others) to make patches as necessary and mark
them for review.
I would also encourage the rest of WebKit to be rather lenient about
getting these #ifdefs into our source. I think that the benefit of
getting all o
On Sun, Sep 7, 2008 at 2:22 PM, Eric Seidel <[EMAIL PROTECTED]> wrote:
> Yay for matching style!
>
> My vote is for JSC.
>
> -eric
>
> On Sun, Sep 7, 2008 at 1:56 PM, Cameron Zwarich <[EMAIL PROTECTED]> wrote:
>> Now that SquirrelFish Extreme has landed, w
Trac.webkit.org was down last night for an upgrade (which is great!)
But now it's super-duper slow. Loading pages like:
http://trac.webkit.org/browser/trunk/WebCore
or browsing around, takes much longer than before.
Any idea what's wrong?
-eric
___
we
This will show you a list of all commits:
http://trac.webkit.org/
Or these:
http://trac.webkit.org/browser/trunk/WebCore/ChangeLog
http://trac.webkit.org/browser/trunk/JavaScriptCore/ChangeLog
There is nothing more high-level than that. You'll have to read
through the logs on your own.
-eric
I think it's wrong for JSC to assume pthreads. Gtk seems to have its
own threading system. Windows does too. It's unclear to me (aside
from the comment below) why it needs them long term.
>From wtf/ThreadingWin.cpp (why is this not in wtf/win/?)
#if PLATFORM(WIN)
// Currently, Apple's Windows
I would also like such an explanation.
And would certainly encourage Brady to do a blog post on the subject. :)
-eric
On Tue, Jul 29, 2008 at 7:01 PM, Tau After <[EMAIL PROTECTED]> wrote:
> Brady,
> Thank you very much for the answer.
> to be more specific:
> 1, what's the intention of FrameLoade
rote:
>
> On Jul 21, 2008, at 12:53 PM, Eric Seidel wrote:
>
>> Would be very easy to build for yourself.
>>
>> You could build it from our HTMLEntityNames.in or from the HTML DTD.
>
>
> Right, however that's what I'm trying to avoid. Since the data and
git-send-bugzilla (attached), is possibly the best thing since sliced
bread. Maybe even better than sliced bread. It's how I submit all my
patches to bugzilla.
There is an actually git branch somewhere on the interwebs (one of the
gtk-webkit guys maintains it). But I don't remember the URL off h
My apologies.
I misread your message. You are correct. Our behavior seems wrong to
me too. Please file a bug.
-eric
On Thu, Apr 10, 2008 at 10:20 PM, Keith Kowalczykowski
<[EMAIL PROTECTED]> wrote:
> Hi Eric,
>
> Thanks for the quick response. Based upon the way I interpret the spec,
> i
The FF/IE behavior looks to be in disagreement with the spec:
http://www.w3.org/TR/XMLHttpRequest/#send
So it seems like both the spec and our code should be changed.
Please file a bug:
http://webkit.org/quality/reporting.html
Bugs reported on the mailing list are unlikely to be fixed unless al
There has not been a checkin to the S60 port in over 8 months:
http://trac.webkit.org/projects/webkit/browser/S60
As far as I can tell, the port is dead.
There are even 12 patches which were approved but never landed:
http://tinyurl.com/5bt4rk
Does anyone know the status of the port? IIRC, Noki
801 - 900 of 926 matches
Mail list logo
