On Wed, Jul 1, 2009 at 7:50 PM, Maciej Stachowiakm...@apple.com wrote:
We generally wouldn't accept WebKit features that only work with V8, even if
other ports may not immediately plan to use them.
I support this principle.
I haven't thought through whether this particular feature
should be
On Jul 1, 2009, at 10:59 PM, Adam Barth wrote:
On Wed, Jul 1, 2009 at 7:50 PM, Maciej Stachowiakm...@apple.com
wrote:
We generally wouldn't accept WebKit features that only work with
V8, even if
other ports may not immediately plan to use them.
I support this principle.
I haven't
02.07.2009, в 9:44, Eric Seidel написал(а):
DETAILED DESCRIPTION OF THE CHANGES GOES HERE. (OOPS!) SEE:
http://webkit.org/coding/contributing.html FOR MORE INFORMATION
Tests: fast/foo.html
* foo.cpp: Added.
|n most cases, detailed description of changes would
On Jul 1, 2009, at 10:47 PM, Dan Bernstein wrote:
On Jul 1, 2009, at 10:44 PM, Eric Seidel wrote:
prepare-ChangeLog should have a --bug= argument and use it for
url autofill
https://bugs.webkit.org/show_bug.cgi?id=26383
I would much prefer if the bug URL came first. I believe
Agreed. Although, Darin Adler is about the only person I ever see
fill in per-file/per-function information. :)
But you're right, that the message could be made more clear. Maybe
something like:
CHANGE DESCRIPTION GOES HERE. (OOPS!) SEE:
http://webkit.org/coding/contributing.html FOR MORE
On Thu, Jul 02, 2009 at 01:01:09AM -0700, Adam Barth aba...@webkit.org wrote:
On Thu, Jul 2, 2009 at 12:50 AM, Mike Hommeymh+web...@glandium.org wrote:
I've always wondered, in the days of atomic commits and advanced SCM, why
fill changelogs at all ? Except for CVS, RCS or SCCS, any SCM
I have difficulty seeing peter as a reviewer he has historically
demonstrated a bad attitude wrt other ports, is reticent about fixing
regressions in other ports.
I also think expert on how image decoders work is overrated as he is
the only person who has done any work on them, and has
On 2009-07-02, at 01:10, Eric Seidel wrote:
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
On Wednesday, July 1, 2009 10:44:16 PM, Eric Seidel e...@webkit.org wrote:
Results in:
2009-07-01 Eric Seidel e...@webkit.org
Reviewed by NOBODY (OOPS!).
prepare-ChangeLog should have a --bug= argument and use it for
url autofill
Hi
How does text drawing is handled inside text editor ( or input
type=text ) in Zoomed mode ?
I am confused how selection controllers work in this case and update
cursor position is updated.
Any insight on this will be great !!
Thanks Regards
Niilesh
On Jul 2, 2009, at 9:14 AM, David Kilzer wrote:
On Wednesday, July 1, 2009 10:44:16 PM, Eric Seidel
e...@webkit.org wrote:
Results in:
2009-07-01 Eric Seidel e...@webkit.org
Reviewed by NOBODY (OOPS!).
prepare-ChangeLog should have a --bug= argument and use it
for
On Jul 2, 2009, at 4:07 AM, Mike Hommey wrote:
On Thu, Jul 02, 2009 at 01:01:09AM -0700, Adam Barth aba...@webkit.org
wrote:
On Thu, Jul 2, 2009 at 12:50 AM, Mike Hommeymh
+web...@glandium.org wrote:
I've always wondered, in the days of atomic commits and advanced
SCM, why
fill changelogs
Maciej Stachowiak wrote:
With SVN at least, it's a lot faster and easier to do a text search on
the ChangeLog than to retrieve and search the commit log history.
Searching the actual commit logs is very slow online and doesn't work at
all offline. The ChangeLog also ends up in static tarball
On Jul 2, 2009, at 12:40 AM, Eric Seidel wrote:
Agreed. Although, Darin Adler is about the only person I ever see
fill in per-file/per-function information. :)
But you're right, that the message could be made more clear. Maybe
something like:
CHANGE DESCRIPTION GOES HERE. (OOPS!) SEE:
Seconded.
On Jul 2, 2009, at 3:10 AM, Eric Seidel wrote:
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
Hello,
I am trying to write a JavaScript to find the word user moused over.
FireFox supports event.rangeOffset, which is the *character* offset the
cursor is at within the element. Given English word, using this offset, I
can find the previous and next spaces and know the word under the cursor.
I also agree and that is the style I use.
On Jul 2, 2009, at 7:05 AM, Adam Roben wrote:
- I generally move the Reviewed by line after the bug number/
description/URL. When you're reading a ChangeLog entry/commit
message (especially an older one), it's generally much more
interesting which
On Jul 2, 2009, at 2:50 PM, Timothy Hatcher wrote:
Having it all on the dateline is not the best for git users either.
We usually remove that line, since git shows the first line of the
commit log in many places.
In retrospect, committing to SVN also usually removes this line so I
When viewing patches on bugs.webkit.org, either with the review tool or
prettydiff, I regularly find the 3 lines of context provided to
be insufficient to really understand the code change. This may be because I
am new to the code base, or because I am used to review tools like Rietveld,
but I
On Jul 2, 2009, at 4:33 PM, Julie Parent wrote:
When viewing patches on bugs.webkit.org, either with the review tool
or prettydiff, I regularly find the 3 lines of context provided to
be insufficient to really understand the code change. This may be
because I am new to the code base, or
Good day, everyone,
As a web developer, I've tried to find an explanation of when
Webkit/Safari decides that the page is done loading, but come up
empty-handed.
I want to issue a long-lived XHR relatively soon after page load to
receive events from a server. Unfortunately, if I do this even a
While clearly a personal preference, I don't like the default
prepare-changelog default text and would much rather we revert to the old
one. I don't think the new text adds anything and will likely be ignored by
most. Can we leave the --bug= option and revert to the old template?
-Sam
On Wed,
On Jul 2, 2009, at 4:52 PM, Sam Weinig wrote:
While clearly a personal preference, I don't like the default
prepare-changelog default text and would much rather we revert to
the old one. I don't think the new text adds anything and will
likely be ignored by most. Can we leave the --bug=
Hi all,
The Tiger, Leopard and Windows build slaves will be offline for most
of the day tomorrow while networking upgrades are performed in the
building where they are hosted. We'll aim to get them back online as
quickly as possible after the upgrade is complete. build.webkit.org
itself
Hello folks,
Based on popular demand, we have created two new mailing lists to
handle some content that's off-topic for webkit-dev. The new lists are:
webkit-help -- requests for help with building webkit, using WebKit's
APIs, embedding WebKit, porting WebKit, and so forth
I suggest
The WebKit Security Group has adopted a new policy on security bugs
and security group membership: http://webkit.org/security/
I encourage vendors who are shipping WebKit or individuals with a
particular interest in security to study this policy. The purpose of
the policy is to enable us
On 2009-07-02, at 21:42, Simone Manganelli wrote:
On that note, I've also been exploring taking over control of the
display of the image/gif MIME type, but what's puzzling is that it
seems that WebKit handles this MIME type internally, regardless of
whether another plug-in registers for
I had another question - I'm looking at JSWorkerConstructor code, but this
pattern exists elsewhere as well:
JSWorkerConstructor::JSWorkerConstructor(ExecState* exec)
:
DOMObject(JSWorkerConstructor::createStructure(exec-lexicalGlobalObject()-objectPrototype()))
{
On Jul 2, 2009, at 10:12 PM, Drew Wilson wrote:
I had another question - I'm looking at JSWorkerConstructor code,
but this pattern exists elsewhere as well:
JSWorkerConstructor::JSWorkerConstructor(ExecState* exec)
: DOMObject(JSWorkerConstructor::createStructure(exec-
29 matches
Mail list logo