This list is about development of the WebKit rendering engine. This is not
a relevant question.
If you want to hack on WebKit in some future career, no reason to not just
start now: http://webkit.org/coding/contributing.html
We don't care if you have a masters or not. Then again, nor do most
If you're currently using svn commit or git svn dcommit to commit your
patches, please consider using bugzilla-tool land-diff instead.
Why?
1. bugzilla-tool updates (and optionally closes) the bug for you when
you're done.
2. bugzilla-tool makes a nice commit entry automatically for you (not
Yes, there are bugs, like all software. Your flippant response seems
inappropriate.
On Mon, Aug 17, 2009 at 11:41 AM, Mark Rowe mr...@apple.com wrote:
On 2009-08-17, at 11:36, Eric Seidel wrote:
If you're currently using svn commit or git svn dcommit to commit your
patches, please
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
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
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 ander...@apple.com wrote:
I rolled that patch out.
The commit-queue is back up and running on my machine. I've fixed a few
bugs along the way and will be posting more bug fix patches this afternoon.
There is a lot of backlog from this weekend (which is good! it means people
have been using the commit queue). It will be a while before the queue
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 aba...@webkit.org 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
Wrong list. webkit-h...@lists.webkit.org is what you want.
On Fri, Aug 7, 2009 at 10:12 AM, Piotr Dobrogost p...@2009.gmane.dobrogost.pl
wrote:
Hi
What level of CSS selectors does WebKit support?
Thanks in advance.
--
Piotr Dobrogost
*** curlpp.org - c++ wrapper for libcurl ***
, 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 e...@webkit.org 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-0-0
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 e...@webkit.org wrote:
I went through every patch in the queue again today (obviously
The queue is out of control again. :(
https://bugs.webkit.org/buglist.cgi?field0-0-0=flagtypes.nametype0-0-0=equalsvalue0-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
, Eric Seidel e...@webkit.org wrote:
The queue is out of control again. :(
https://bugs.webkit.org/buglist.cgi?field0-0-0=flagtypes.nametype0-0-0=equalsvalue0-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
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 m...@apple.com wrote:
On Aug 1, 2009, at 8:41 PM, Adam Barth wrote:
On Sat, Aug 1, 2009 at 1:13 PM,
Stachowiak m...@apple.com 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 bugzilla-tool).
I'm very interested in any suggestions folks
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.
Ojan
On Sat, Aug 1, 2009 at 12:49 PM, Eric Seidel e...@webkit.org wrote:
Yeah, I stared a slowest run before going to bed, and got the following:
The 10
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
search bugs.webkit.orghttps://bugs.webkit.org/show_bug.cgi?id=3251
On Wed, Jul 29, 2009 at 11:29 AM, Chi-Wai Lau myonm...@gmail.com 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
Seems like --clean needs to know how to delete Debug/DerivedSources/*
On Tue, Jul 28, 2009 at 8:57 AM, Alexey Proskuryakova...@webkit.org 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.
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
AM, Darin Adlerda...@apple.com 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?
Yes, Maciej is saying that the document
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_castJSHTMLFormElement*(asObject(slot.slotBase()));
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 Seidele...@webkit.org wrote:
Is it possible to move a name getter onto a different JavaScript object?
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)
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 Stachowiakm...@apple.com wrote:
On Jul 23, 2009, at 5:38 PM, Eric Seidel wrote:
I'm trying
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 Stachowiakm...@apple.com wrote:
On Jul 23, 2009, at 5:23 PM, Eric Seidel wrote:
It seems all lookups
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 Freytherze...@selfish.org 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,
Now from the right email address.
On Wed, Jul 22, 2009 at 5:34 PM, Eric Seidelesei...@google.com 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 createStructure and making all
Never mind. I've looked at the source, and understand enough to see
that that looks like a bad idea. Autogen'd constructors seem to
always assume that the ConstructorTable will be non-empty, and thus
they need to have a custom getOwnPropertySlot. So I'll leave the
autogen'd code for now. It
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 Pinkertonpinker...@chromium.org wrote:
Note that Firefox is moving towards a similar out of process model
for plugins and rendering
On
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 Garengga...@apple.com wrote:
Also, once we've
Re-sending from correct address.
On Mon, Jul 13, 2009 at 1:23 PM, Eric Seidelesei...@google.com 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
associated
On Mon, Jul 13, 2009 at 1:36 PM, Geoffrey Garengga...@apple.com 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
On Mon, Jul 13, 2009 at 2:18 PM, Sam Weinigsam.wei...@gmail.com 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
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.
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
Oh, I did really like the idea of a prepare-ChangeLog wizard which
someone suggested. Where it might ask you some of the relevant
questions instead of filling in boilerplate.
I continue to find it frustrating that I have to r- patches with bad
ChangeLogs. :) I don't think that's so much
Re-sent from the proper email address.
On Mon, Jul 6, 2009 at 5:37 PM, Eric Seidel macd...@gmail.com 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
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
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 Proskuryakova...@webkit.org wrote:
02.07.2009, в 9:44, Eric Seidel написал
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 Seidele...@webkit.org wrote:
Be
/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 e...@webkit.org
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
Wrong email address.
On Mon, Jun 29, 2009 at 4:15 PM, Eric Seidelmacd...@gmail.com 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?
The two patches on
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
.)
./reviewers.py WebCore/ChangeLog WebCore/ChangeLog-2009-06-16
Darin Adler 609
Sam Weinig 319
Eric Seidel 313
David Hyatt 236
Dan Bernstein 208
Oliver Hunt 202
Simon Fraser 159
Timothy Hatcher 147
Alexey Proskuryakov 139
Mark Rowe 116
Dimitri Glazkov 101
Simon Hausmann 99
Holger Hans Peter
wrote:
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/editflagtypes.cgi
(only accessible to bugzilla users with edit
Oh how I wish that my @webkit.org address and gmail would get along...
-eric
-- Forwarded message --
From: Eric Seidel macd...@gmail.com
Date: Thu, Jun 18, 2009 at 7:02 PM
Subject: Re: [webkit-dev] Review queue needs love
To: Adam Treat tr...@kde.org
Cc: webkit-dev
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 Steinerrolandstei...@google.com
(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
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
*
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.
15 of those are Gtk-only bugs. Need some help from the Gtk 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 e...@webkit.org wrote:
Reviewed more before bed. We're down to:
https://bugs.webkit.org/buglist.cgi
.
Thanks again to those who have pitched in so far.
-eric
On Sat, May 23, 2009 at 12:20 AM, Eric Seidel e...@webkit.org wrote:
Reviewed more before bed. We're down to:
https://bugs.webkit.org/buglist.cgi?field0-0-0=flagtypes.nametype0-0-0=equalsvalue0-0-0=review%3F
50
and
curl -s https
, May 22, 2009 at 7:40 PM, Maciej Stachowiak m...@apple.com 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 -s https://bugs.webkit.org/request.cgi; | grep PDT | wc -l]
74
object 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 da...@apple.com:
On May 21, 2009, at 7:12 AM, naixuan guan wrote:
when I open the HTML page like follow:
OBJECT id=StormPlayer width = 800 height = 400 src =
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
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 m...@apple.com wrote:
On May 21, 2009, at 7:27 PM, Eric Seidel wrote:
Our review process seems to be failing. As a reviewer
, 2009 at 12:48 PM, Maciej Stachowiak m...@apple.com wrote:
On May 21, 2009, at 7:27 PM, Eric Seidel wrote:
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
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 the
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 e...@puidokas.com wrote:
I've noticed Safari 3.2.1
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
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 during
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 e...@webkit.org:
Oh
is just much slower?
-eric
On Thu, Mar 26, 2009 at 4:56 PM, Eric Seidel e...@webkit.org 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/repaint/lines
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) |
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 macd...@gmail.com wrote:
The SVG stuff relates to dumping the focus rect. From the diffs it
seems that somehow the text
Sigh. Bounced again, silly gmail, the original message:
On Mon, Jan 26, 2009 at 12:09 AM, Eric Seidel macd...@gmail.com 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
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 p...@chromium.org wrote:
On Sat, Jan 3, 2009 at 11:41 AM, Darin Adler da...@apple.com wrote:
Looking at the buildbot I see a few broken regression tests:
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
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-dev
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,
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,
As
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
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
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 PROTECTED]:
If you search the web for WEBKIT_TESTFONTS you may
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
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,
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
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
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, we should perform some of
the cleanup that we've been
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
___
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
, 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
functionality are *already* in webkit, it seems a shame for me (and
all
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
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
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,
it
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,
Not yet.
On Tue, Apr 8, 2008 at 8:03 AM, Scott Thompson [EMAIL PROTECTED] wrote:
With the recent speed improvements show by JavaScript in the WebKit
builds... has JavaScript Core changed to use a byte code interpreter (as
suggested at the web site
You should be able to attach an onerror event handler and catch the
SVG ErrorEvent, however I don't believe we correctly support SVG's
ErrorEvent yet.
http://bugs.webkit.org/show_bug.cgi?id=8519
http://bugs.webkit.org/show_bug.cgi?id=15363
-eric
On Thu, Mar 20, 2008 at 1:11 AM, Marco Pifferi
James,
Glad to see you interested in WebKit GSoC. My primary suggestion
would be that you join #webkit and meet the team. From there we can
help you find areas of interest to you which should be doable by
someone of your experaince in the GSoC timeframe.
-eric
(MacDome on #webkit or eseidel
As far as I know, none of those features are required by WebKit. You
should be fine to link against a version of libXML2 which does not
include those.
-eric
On Tue, Mar 25, 2008 at 10:48 AM, Leonid Romanov [EMAIL PROTECTED] wrote:
Hi,
I'm trying to minimize WebKit and dependents libraries
tell
me so and I'll repost it to the mailing list as followup.
On Tue, 2008-03-25 at 13:25 -0700, Eric Seidel wrote:
As far as I know, none of those features are required by WebKit. You
should be fine to link against a version of libXML2 which does not
include those.
-eric
More complete instructions on how to register as a mentor:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators
-eric
On Mon, Mar 17, 2008 at 4:00 PM, Eric Seidel [EMAIL PROTECTED] wrote:
WebKit has been accepted
%202008
-eric
On Tue, Feb 26, 2008 at 12:31 AM, Eric Seidel [EMAIL PROTECTED] wrote:
I think WebKit should consider participating in Google's Summer of
Code this year.
To facilitate such, I have created a wiki page, where potential
mentors, as well as project ideas can be placed:
http
You may be missing the required fonts. (And thus be getting the wrong
metrics for text runs). Safari bundles some fonts with it. The Apple
developers all have these custom fonts installed on their system.
Other external contributers use some special instructions to get the
fonts step
PROTECTED] wrote:
On Feb 25, 2008, at 11:31 PM, Eric Seidel wrote:
I think WebKit should consider participating in Google's Summer of
Code this year.
To facilitate such, I have created a wiki page, where potential
mentors, as well as project ideas can be placed:
http
I think WebKit should consider participating in Google's Summer of
Code this year.
To facilitate such, I have created a wiki page, where potential
mentors, as well as project ideas can be placed:
http://trac.webkit.org/projects/webkit/wiki/Google%20Summer%20of%20Code%202008
I have added a
It is not possible to do this today.
However it would be neat to add such to testkjs. We've talked about
renaming testkjs to something like jscshell or jsshell or js.
Starting to add things like argument handling might be further
justification for renaming it to a name that would make sense were
701 - 800 of 807 matches
Mail list logo
