to turn on editing delegate?
Ryosuke Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
-- Forwarded message --
From: Ryosuke Niwa rn...@google.com
Date: Wed, Jun 10, 2009 at 3:49 PM
Subject: Re: [webkit-dev] Slow scrolling on certain pages
To: Adam Bryzak abry...@gmail.com
Hi,
It seems like that's happening with Chrome (3.0.183.1) as well. Can anyone
else confirm
This might be related to https://bugs.webkit.org/show_bug.cgi?id=19650 I
played around with the code, and it seems like safari.css is causing the
trouble. Adam, are planning to create a new bug?
Ryosuke
On Wed, Jun 10, 2009 at 3:50 PM, Ryosuke Niwa rn...@google.com wrote
Hi,
I think there should be a link to
http://trac.webkit.org/wiki/BuildingOnWindows
either from http://webkit.org/building/build.html or
http://webkit.org/building/debug.html
Alternatively, we can integrate that to either one.
Ryosuke Niwa
___
webkit
Hi,
I'm trying to debug DumpRenderTree but keep getting
CFURLConnectionScheduleWithCurrentMessageQueue: NO LONGER NEEDED TO BE
CALLED -
done by CFURLConnectionScheduleWithCurrentMessageQueue: NO LONGER NEEDED TO
BE CALLED -
done by CFURLConnectionScheduleWithRunLoop (4) (see
Instead of trying to build from Visual Studio, try
WebKitTools/Scripts/build-webkit --debug on cygwin.
Ryosuke
On Tue, Jun 16, 2009 at 8:55 PM, 张雷 zhang@kortide.com.cn wrote:
I tried several times, but failed always! God damn!
I read all the instructions detailedly. These are my steps:
the problem.
Is there anyone familiar with this message?
Ryosuke
On Wed, Jun 17, 2009 at 1:02 AM, Alexey Proskuryakov a...@webkit.org wrote:
17.06.2009, в 7:06, Ryosuke Niwa написал(а):
CFURLConnectionScheduleWithCurrentMessageQueue: NO LONGER NEEDED TO BE
CALLED -
done
Hi,
I'm currently working on the patch for 21712 (Bug 21712: Indent on li
creates new ol instead of merging with existing ol, numbering
incorrect.) But because Firefox gave me unexpected result for
https://bugs.webkit.org/show_bug.cgi?id=21712, I'm wondering whether I
should copy the behavior of
error on window.getSelection(), but the visual
display is here:
-Original Message-
From: webkit-dev-boun...@lists.webkit.org
[mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Ryosuke Niwa
Sent: Monday, June 22, 2009 4:00 PM
To: WebKit Development
Subject: [webkit-dev
Does this help?http://www.kirupa.com/forum/showthread.php?t=273849
Ryosuke
On Wed, Jun 24, 2009 at 2:43 PM, Eric Brunstad webkit-l...@ericbrunstad.com
wrote:
Hi Marshall,
I appreciate your response but I would appreciate it if you could be a
little more specific. I looked through the
trying to understand this part of the webcore code, I faced a possibly
wrong impl:
(...)
VisiblePosition logicalStartOfLine(const VisiblePosition c)
{
VisiblePosition visPos = logicalStartPositionForLine(c);
if (visPos.isNull())
return
For editing/selection/extend-selection.html,
It seems like the bottleneck is testExtendingSelection, in particular,
positionExtendingInDirection and checkSameOrder:
function positionsExtendingInDirection(sel, direction, granularity)
{
var positions = [];
while (true) {
, Ryosuke Niwa rn...@google.com wrote:
For editing/selection/extend-selection.html,
It seems like the bottleneck is testExtendingSelection, in particular,
positionExtendingInDirection and checkSameOrder:
function positionsExtendingInDirection(sel, direction, granularity)
{
var positions
Use the newest Nightly build and visit
http://en.wikipedia.org/wiki/Main_Page
You see the sidebar showing up below the main pane.
This is a regression in the past 12 hours.
Ryosuke
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
Filed as https://bugs.webkit.org/show_bug.cgi?id=28350Seems to be caused by
http://trac.webkit.org/changeset/47255
Ryosuke
On Sat, Aug 15, 2009 at 8:23 PM, Ryosuke Niwa rn...@google.com wrote:
Use the newest Nightly build and visit
http://en.wikipedia.org/wiki/Main_Page
You see the sidebar
I realized that all patches I submitted in the past 17 hours were lost as
well.
Ryosuke
On Thu, Aug 20, 2009 at 10:14 PM, William Siegrist wsiegr...@apple.comwrote:
Mac OS Forge experienced database corruption during our maintenance reboot
this evening and had to roll back to a backup from
On Sun, Jan 24, 2010 at 8:15 PM, Nikolas Zimmermann
zimmerm...@physik.rwth-aachen.de wrote:
Am 25.01.2010 um 05:07 schrieb Maciej Stachowiak:
On Jan 24, 2010, at 7:42 PM, David Kilzer wrote:
On Sun, January 24, 2010 at 7:09:26 PM, Maciej Stachowiak wrote:
I don't think we're looking to
,
beginningOfNode, endOfNode. The only exception is that we'll still need
offsets for offsets into text nodes.
I like the idea of getting rid of node/offset pairs but how do those four
node correspond to the existing node/offset or Position / VisiblePosition?
Best,
Ryosuke Niwa
360-366
of WebKit/gtk/tests/testwebview.c:
http://build.webkit.org/builders/GTK%20Linux%2032-bit%20Debug/builds/5190/steps/compile-webkit/logs/warnings
Best regards,
Ryosuke Niwa
(rn...@webkit.org)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
to affect the other parts of WebKit,
I have to watch waterfall and commit myself to see all builders pass all the
tests so that I can FIX them as needed.
I didn't take Alex's post offensive though.
Best,
Ryosuke Niwa
___
webkit-dev mailing list
webkit
On Mon, Jul 12, 2010 at 9:20 AM, Peter Beverloo pe...@lvp-media.com wrote:
I decided to take this issue to the mailing lists before posting a
patch for such reasons. The Apple documentation which is referred
to[1] in that bug has been updated to use WebKit's own vendor prefix,
so I suspect
agree that having a really large review queue isn't ideal. Maybe we can
customize the review queue so that it only shows patches of your expertise.
Best,
Ryosuke Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman
information out of the svn blame will solve
this problem as well. I'd also recommend to provide a way to list
committers who recently touched that code as well because they are also
likely to be able to find problems with new patches.
Best,
Ryosuke Niwa
I don't think option 1 really is
an option.
Best Regards,
Ryosuke Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
by the change and start nagging other
vendors to fix their browsers instead.
Best,
Ryosuke Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On Mon, Jul 26, 2010 at 12:06 AM, Darin Adler da...@apple.com wrote:
Sounds like some differences are:
1) The blur event in Opera and IE will see the new focused node as the
active element, but in WebKit and Firefox will see no active element at all.
2) Same for DOMFocusOut, but IE and
Thanks a lot for the feedback!
On Sun, Jul 25, 2010 at 5:07 PM, Maciej Stachowiak m...@apple.com wrote:
I think the key question here is what counts as as formatting. That needs
to be determined empirically by testing other browsers, not just by reading
their docs.
I agree, it's crucial
SCRIPT window.getSelection().selectAllChildren(foo); /SCRIPT
#text
/#text
/BODY
/HTML
See Writing DumpAsMarkup
Testshttp://trac.webkit.org/wiki/Writing%20DumpAsMarkup%20Testsfor
more ways you can use dump-as-markup.js
Best regards,
Ryosuke Niwa
On Mon, Jul 26, 2010 at 1:10 PM, Maciej Stachowiak m...@apple.com wrote:
I agree. We should test and see what other browsers do in various cases.
But since it's impossible for us to enumerate every possible formatting, I
propose to just remove text-decoration, font-weight, etc... and the
Filed as Bug 43017 - removeFormant needs to be
reimplementedhttps://bugs.webkit.org/show_bug.cgi?id=43017
.
Best,
Ryosuke
On Mon, Jul 26, 2010 at 4:27 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Mon, Jul 26, 2010 at 1:10 PM, Maciej Stachowiak m...@apple.com wrote:
I agree. We should test
. Once we convert
all the tests, we can drop the layoutTestController name entirely.
But I'm not sure if converting all the existing tests is feasible or worth
the effort. Is there any practical problem other than being semantically
wrong?
Best,
Ryosuke Niwa
On Wed, Aug 4, 2010 at 2:54 PM, Geoffrey Garen gga...@apple.com wrote:
And if we did provide a good set of APIs such that web developers
themselves can implement their own editing commands, then there's no reason
we can't implement our editing commands in terms of those public APIs,
putting
-Ensures that editing code never crashes (outside of JSC/V8 bugs)
JavaScript can still crash -- you just get an unhandled exception instead
of a segfault. It's not clear to me why that would be better.
I think the kind of crashes Ojan is talking about are ones caused by DOM
mutation
, but would
probably still serve the key use cases.
Agreed.
Ditto.
Best,
Ryosuke Niwa
Software Engineer
Google Inc.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
());
return;
}
...
IMHO, new code is easier to read and has very little drawbacks (possible
slowdown use to construction of QualifiedName).
I could have used htmlTag or any other qualified name different from the
four names used above,
but that wouldn't be semantically correct.
Ryosuke Niwa
Software
?
Ryosuke Niwa
Software Engineer
Google Inc.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Hi,
On Tue, Aug 31, 2010 at 7:56 AM, TAMURA, Kent tk...@chromium.org wrote:
Do we have any recommendation of programming language for scripts such as
WebKitTools/Scripts?
It seems new scripts are written by Python and Ruby code is very rare.
Is it reasonable to port a Ruby script to Python?
Oh, I didn't see your second post either. Sounds like porting everything
into Python would speed up new-run-webkit-tests? Then I'm all for it. I
think other folks would be equally convinced as well if you could kindly
measure the time difference between Ruby + Python + shell script
are 5-10
hours behind, it's really hard for me to realize any brokerage I caused or
follow up later because even if I attempted a fix, I won't see the results
for another 5-10 hours.
Is there anyway we can upgrade these two bots so that it won't be a burden
for WebKit developers?
Best,
Ryosuke Niwa
I meant Leopard Debug (Tests) and Windows Debug (*WebKit2* Tests).
- Ryosuke
On Thu, Sep 9, 2010 at 11:17 PM, Ryosuke Niwa rn...@webkit.org wrote:
Hi,
It came to my attention that Leopard Debug (Tests) and Windows Debug (Test)
are always behind by a significant amount (5-10 hours). Since
On Tue, Sep 14, 2010 at 10:38 AM, Jeremy Orlow jor...@chromium.org wrote:
It's worth noting that Android also uses v8 and skia. They only have one
reviewer at the moment, but it still might be best to not associate Chromium
with skia/v8 changes.
As for the original questions: does anyone
On Mon, Sep 20, 2010 at 11:12 AM, David Hyatt hy...@apple.com wrote:
This is going to be tricky. You basically want to walk the line box tree
rather than the renderobject tree and then look at surrounding text.
About turning off the underline if the ruby is in a link: I've looked at
the
Mn... I realized something strange here.
RTE2-AC_JF_TEXT-1_SC fails on WebKit TOT and the test is: JustifyFull on
foo^bar. However, it clearly works on WebKit when I test it manually. It
generates div style=text-align: justify;foobarbr/div. I'm not sure
why the test claims that WebKit fails on
But thanks to your test suite, I noticed some very embarrassing fact:
https://bugs.webkit.org/show_bug.cgi?id=46954
- Ryosuke
On Thu, Sep 30, 2010 at 6:58 PM, Roland Steiner rolandstei...@google.comwrote:
On Fri, Oct 1, 2010 at 10:49 AM, Ryosuke Niwa rn...@webkit.org wrote:
Mn... I realized
However, we pass JustifyLeft, JustifyRight, JustifyCenter even though we
also add BR in those cases. I don't quite understand the difference
there...
- Ryosuke
On Thu, Sep 30, 2010 at 6:58 PM, Roland Steiner rolandstei...@google.comwrote:
On Fri, Oct 1, 2010 at 10:49 AM, Ryosuke Niwa rn
, using CSS styling (should be noop)
Isn't supposed to be fontname 'arial' instead? There are 4 other tests
below this one with the seemingly the same problem.
- Ryosuke
On Fri, Oct 1, 2010 at 1:07 PM, Ryosuke Niwa rn...@webkit.org wrote:
However, we pass JustifyLeft, JustifyRight, JustifyCenter
the
computed style value of the text instead.
- Ryosuke
On Fri, Oct 1, 2010 at 1:14 PM, Ryosuke Niwa rn...@webkit.org wrote:
I also noticed:
RTE2-CC_FN:a_FONTf:a-1_SI fontname 'courier' y y y y FAIL font
face=arialfoo[bar]baz/font font face=arialfoo[bar]baz/font font
face=arialfoo
Yay! http://trac.webkit.org/changeset/68904 fixed the last failing tests in
queryCommandState queryCommandIndeterminate. Now we pass all the sub
tests.
- Ryosuke
On Fri, Oct 1, 2010 at 2:04 PM, Ryosuke Niwa rn...@webkit.org wrote:
I think we shouldn't be hard-coding 18px here:
{'value
-- Forwarded message --
From: Ryosuke Niwa ryosuke.n...@gmail.com
Date: Tue, Oct 5, 2010 at 2:29 AM
Subject: Re: [webkit-dev] Supporting css ime-mode property
To: Alexey Proskuryakov a...@webkit.org
Cc: Kenichi Ishibashi ba...@google.com, webkit-dev@lists.webkit.org
+1
-- Forwarded message --
From: Ryosuke Niwa ryosuke.n...@gmail.com
Date: Tue, Oct 5, 2010 at 10:45 AM
Subject: Re: [webkit-dev] Supporting css ime-mode property
To: Alexey Proskuryakov a...@webkit.org
Cc: Kenichi Ishibashi ba...@google.com, webkit-dev@lists.webkit.org
On Tue, Oct
On Tue, Oct 5, 2010 at 10:38 AM, Alexey Proskuryakov a...@webkit.org wrote:
There are big questions remaining:
- Do we really want to implement an IE extension in a way that's way
different from IE?
We support many features that IE initially implemented; HTML editing is a
good example.
On Tue, Oct 5, 2010 at 11:26 AM, Alexey Proskuryakov a...@webkit.org wrote:
Also, I don't think the difference between IE and Firefox's
implementation affects CJK websites, which presumably will be the primary
users of ime-mode.
I think it does. An example that was given by Kenichi
On Tue, Oct 5, 2010 at 3:04 PM, Alexey Proskuryakov a...@webkit.org wrote:
As far as I checked on Firefox 4.0b6, it is implemented and works as
expected. Do you have a different version of Firefox?
I tested https://www.aeoncredit.co.jp/NetBranch/cardinit.do with 3.6.10
on Mac.
It works
On Tue, Oct 5, 2010 at 3:18 PM, James Su james...@gmail.com wrote:
Though this property is useful in some situation, it's very confusing
regarding to its real purpose. If I understand correctly, this property is
mostly used for restricting the input character set of an input box.
Not quite.
On Tue, Oct 5, 2010 at 5:48 PM, Alexey Proskuryakov a...@webkit.org wrote:
What I see on baidu.com right now seems much different from an input
method though - they are just making a guess at what the user intended to
type. Google search works exactly the same, as long as the page language is
-select
events
in any context deemed appropriate, including text selections outside of form
controls, or image or markup selections such as in SVG.
Best regards,
Ryosuke Niwa
Software Engineer
Google Inc.
___
webkit-dev mailing list
webkit-dev
or it is a bug?
Best regards,
Ryosuke Niwa
Software Engineer
Google Inc.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On Fri, Oct 8, 2010 at 5:51 PM, Darin Adler da...@apple.com wrote:
On Oct 8, 2010, at 3:47 PM, Ryosuke Niwa wrote:
Does anyone know if this was a UI / functionality decision or it is a
bug?
This undo behavior you describe in Safari is what is automatically
implemented by Cocoa’s
On Sat, Oct 9, 2010 at 3:49 PM, Alexey Proskuryakov a...@webkit.org wrote:
09.10.2010, в 15:07, Ryosuke Niwa написал(а):
IMHO, the current behavior of Safari is very confusing to developers.
Can we add a new editor command (e.g. UndoUntilLastUserInitiatedAction) to
support the current
On Sat, Oct 9, 2010 at 4:43 PM, Alexey Proskuryakov a...@webkit.org wrote:
Please correct me if you misunderstood your solution but doesn't that
change the behavior of Safari if website executed multiple execCommand's in
a single user initiated action? Suppose we had the following senario:
On Mon, Oct 11, 2010 at 11:34 AM, Darin Adler da...@apple.com wrote:
It seems that if our aim is to be compatible with the IE event, we should
make our implementation as close to the IE one as possible. I’m not sure
that firing the same event, but with a different target, will be good for
Cocoa app, NSApplication would set up a root autorelease pool
that those would fall into. In something like DRT it would need to do so
itself before using them.
Is this a known problem? If not, can someone work on this issue?
Best,
Ryosuke Niwa
Software Engineer
Google Inc
, Ryosuke Niwa wrote:
A lot of tests in fast/workers/storage/ seem to have the following error
message:
2010-10-17 21:17:04.268 DumpRenderTree[42509:bd9b] ***
_NSAutoreleaseNoPool(): Object 0x218a8890 of class NSCFString autoreleased
with no pool in place - just leaking
Stack: (0x955d2f4f
On Tue, Oct 19, 2010 at 9:20 AM, Ryosuke Niwa ryosuke.n...@gmail.comwrote:
Ins't this due to the fact Chromium bots run pixel tests and others don't?
- Ryosuke
On Tue, Oct 19, 2010 at 9:17 AM, Eric Seidel e...@webkit.org wrote:
That does not sound expected or desired. Could you point me
Submit a patch to modify this page:
http://trac.webkit.org/browser/trunk/WebKitSite/building/tools.html
- Ryosuke
On Tue, Oct 19, 2010 at 9:30 AM, Jenn Braithwaite (胡慧鋒) je...@google.comwrote:
Apparently DirectX SDK is now a required tool to get building on Windows.
I fought for 2 days with
Hi,
I think I talked with this person on IRC last night, and I suggested him to
modify EditorClientQt::shouldChangeSelectedRange to always return false.
FYI, there is a bug to add this feature on Qt ports:
https://bugs.webkit.org/show_bug.cgi?id=38520
- Ryosuke
On Tue, Oct 19, 2010 at 10:17
at 10:27 AM, Ryosuke Niwa rn...@webkit.org wrote:
Hi,
I think I talked with this person on IRC last night, and I suggested him
to modify EditorClientQt::shouldChangeSelectedRange to always return false.
FYI, there is a bug to add this feature on Qt ports:
https://bugs.webkit.org/show_bug.cgi
A patch has been submitted to https://bugs.webkit.org/show_bug.cgi?id=45712.
- Ryosuke
On Mon, Oct 11, 2010 at 6:21 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Mon, Oct 11, 2010 at 11:34 AM, Darin Adler da...@apple.com wrote:
It seems that if our aim is to be compatible with the IE event, we
-- Forwarded message --
From: Ryosuke Niwa ryosuke.n...@gmail.com
Date: Wed, Oct 27, 2010 at 2:31 PM
Subject: Re: [webkit-dev] Platform specific editing behaviors
To: Antonio Gomes toniki...@gmail.com
Cc: webkit-dev Development webkit-dev@lists.webkit.org
On Wed, Oct 27, 2010
I think 5px is way too small. Maybe 7 or 8 at least but even those are
really hard to read in high-resolution displays. See
I frequently copy paste function names, variable names, etc... into my
comment so I like the new behavior.
- Ryosuke
On Wed, Nov 10, 2010 at 10:18 AM, Adam Barth aba...@webkit.org wrote:
Yeah, Darin and Alexey asked for this change. I thought about
emailing webkit-dev, but I was worried
Hi,
Can we modify the bugzilla so that we can edit the details of attachments
without opening the attachments on the right pane? When the attachment is
crash reproduction, I can't edit the details on WebKit / Chromium because it
crashes my browser as soon as I open the details.
Best,
Ryosuke
On Fri, Dec 3, 2010 at 1:37 PM, David Hyatt hy...@apple.com wrote:
The only exception I would make to this rule is if all the call sites use
variables and never pass in raw true or false. In that case there's no loss
of readability, and whether you use an enum vs. a bool is irrelevant.
I
On Fri, Dec 3, 2010 at 1:55 PM, Nico Weber tha...@chromium.org wrote:
Out of curiosity, what do people think of
doSomethingElse(/*paramName=*/true);
when calling an existing function that takes a bool?
Why don't we just change it to take enum instead? Adding a comment to
repeat the
On Fri, Dec 3, 2010 at 2:08 PM, Alexey Proskuryakov a...@webkit.org wrote:
I think that Dave's rule is best here
I second that.
- Ryosuke
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On Fri, Dec 3, 2010 at 2:30 PM, Darin Adler da...@apple.com wrote:
I think in general the rule should be Keep your call sites readable,
and convert to enums if you find that the call sites are becoming
inscrutable.
Beyond the enum guidelines, it’s also true that functions with these
Isn't this a problem with http://build.webkit.org/?
http://build.webkit.org/xmlrpc is 404 on my browser.
- Ryosuke
On Tue, Dec 7, 2010 at 10:19 AM, Andy Estes aes...@apple.com wrote:
I see the same issue when running 'webkit-patch failure-reason'. Here's the
traceback:
Traceback (most
Hi all,
Since this would require a lot of rebaselines anyways, can we also add some
enhancements to DRT?
I propose to an option to dump as text with images. In many editing tests,
we don't need render tree dumps because we care more about how DOM looks
like before and after editing operations.
On Wed, Dec 8, 2010 at 11:04 PM, Nikolas Zimmermann
zimmerm...@physik.rwth-aachen.de wrote:
Hi Ryosuke,
this feature is already available. I've implemented it for the
svg/dynamic-updates test, DRT hooks are available.
dumpAsText() takes an optional boolean parameter that toggles this.
//
On Fri, Dec 10, 2010 at 2:21 PM, Darin Adler da...@apple.com wrote:
On Dec 10, 2010, at 2:05 PM, Ryosuke Niwa wrote:
If Ahem allows us to have the same pixel expected results for all
platforms. Why don't we switch the default font of DRT to Ahem?
Ahem is a testing font where characters
On Thu, Dec 16, 2010 at 9:05 AM, William Siegrist wsiegr...@apple.comwrote:
Our buildbot allows for anonymous people to trigger things on the slaves,
and it is like this on purpose for ease of use. However, that means it is
possible for a malicious person to do things like shutdown all of the
Didn't we have a discussion about this and concluded that RegressionTests is
the best choice?
Ryosuke Niwa
Software Engineer
Google Inc.
On Sat, Dec 18, 2010 at 2:37 AM, Zoltan Herczeg zherc...@inf.u-szeged.huwrote:
LayoutTests = Tests
That would kill the new Ttab is enough to enter
Thanks for the rename! I love the fact I can access Tools in just 2 key
strokes (T + tab).
- Ryosuke
On Fri, Dec 17, 2010 at 4:09 PM, Dan Bernstein m...@apple.com wrote:
Done in r74301.
On Nov 20, 2010, at 11:29 PM, Dan Bernstein wrote:
WebKit developers,
I am going to commit the patch
On Mon, Dec 20, 2010 at 11:22 PM, Adam Barth aba...@webkit.org wrote:
Do we want to move LayoutTests = RegressionTests? My sense is that
would be more disruptive than the other moves. Last time we discussed
this question, Darin encouraged us to view the future as larger than
the past and to
On Tue, Dec 21, 2010 at 6:16 PM, Mihai Parparita mih...@chromium.orgwrote:
On Tue, Dec 21, 2010 at 6:12 PM, Ryosuke Niwa rn...@webkit.org wrote:
Why don't we do this as we change the format of render tree dumps. We
can
remove expected tests from LayoutTests, move tests to RegressionTests
On Thu, Jan 6, 2011 at 8:31 PM, Darin Fisher da...@chromium.org wrote:
On Thu, Jan 6, 2011 at 4:39 PM, Ojan Vafai o...@chromium.org wrote:
Some ideas:
-Use the svn revision number. That has the downside of being tied to SVN
should we want to change version control systems.
-Have a file
On Mon, Jan 10, 2011 at 12:09 PM, Ryosuke Niwa ryosuke.n...@gmail.comwrote:
This might be due to my first patch for
https://bugs.webkit.org/show_bug.cgi?id=51389
Best,
Ryosuke
On Mon, Jan 10, 2011 at 11:42 AM, Darin Adler da...@apple.com wrote:
On Jan 10, 2011, at 11:05 AM, Jia Pu wrote
I can access #webkit as of now.
- Ryosuke
On Mon, Jan 10, 2011 at 11:19 PM, Eric Seidel e...@webkit.org wrote:
As of this afternoon I'm unable to connect o #webkit.
I'm attempting to connect to irc.freenode.net (I was using port 8000,
but now I'm using 7000 w/ SSL).
NICK eseidel
USER
On Thu, Jan 13, 2011 at 5:23 PM, William Siegrist wsiegr...@apple.comwrote:
Some people have asked for a way to get email from build.webkit.org for
build events/results. The simplest and easiest-to-maintain way I think to do
this is to make a new mailing list and have the master use that for
Getting build bots result for every single revision seems quite noisy. Will
be possible to have a page where I can signup for an email or is it too hard
to maintain?
e.g. If I'm the author of revision X, and I'd like to make sure X passed on
all the bots but don't want to waste time by staring
On my second thought, it seems like all usage could be addressed by WebKit
changing IME status based on lang attribute. e.g. in a page where
lang=ja, we'd expect Japanese IME to be enabled and if any input/textarea
has lang=en, then we can automatically switch to English IME (e.g. IME is
turned
On Tue, Jan 18, 2011 at 4:30 PM, Darin Adler da...@apple.com wrote:
It seems that a lot of people are making script tests with non-standard
wrappers. And not adding exceptions to the make-script-test-wrappers
script. I ran the script and it created 4 files, and modified 33 others.
Any ideas
that is neither before nor after the
node. If a caller of node() is aware of these differences and has a
different logic for each type, then it should be calling anchorNode()
instead.
Best regards,
Ryosuke Niwa
Software Engineer
Google Inc.
___
webkit-dev
Go to Project setting and set the build directory to be Project
root/WebKitBuild. By default, it's at Source/WebCore/build and it won't
just work.
- Ryosuke
On Mon, Jan 24, 2011 at 11:12 PM, Won J Jeon wjj...@gmail.com wrote:
Thanks for your response.
I have no problem to build WebKit from
On Thu, Jan 27, 2011 at 3:46 PM, Eric Seidel e...@webkit.org wrote:
My personal preference (and I'd love to hear from other contributors)
is that code should ideally be self-documenting.
I strongly agree with this point. One pit-fall of adding comments is that
it gives an illusion of the
I'm surprised that you don't use Tools/Scripts/webkit-patch upload bug
number.
- Ryosuke
On Thu, Jan 27, 2011 at 9:43 PM, Jia Pu j...@apple.com wrote:
On Jan 27, 2011, at 9:07 PM, Jia Pu wrote:
I just tried again, and got the same failure.
There two things I can think of that are
On Sun, Jan 30, 2011 at 4:41 PM, Ryan Leavengood leaveng...@gmail.comwrote:
Maybe the solution here is better documentation outside the source
code. I hope some of the more experienced WebKit developers can agree
that there are parts of the code that are harder for new developers to
dig into.
On Fri, Jan 28, 2011 at 10:21 AM, Peter Kasting pkast...@google.com wrote:
On Fri, Jan 28, 2011 at 10:14 AM, Alexey Proskuryakov a...@webkit.orgwrote:
Do you have any specific mechanism in mind for keeping global comments
accurate?
No more than I have for keeping API usage or function
2011/1/31 Konstantin Tokarev annu...@yandex.ru
You can document A as function calling B, B as function calling C, and keep
documentation of C up to date when it's behavior changes
I don't see how that can substitute my comment that Because A does X, do
Y. Saying do Y because we call A isn't
On Mon, Jan 31, 2011 at 4:54 PM, Aaron Boodman a...@chromium.org wrote:
It seems like the one line patch to C just broke A. It had a
dependency on the behavior of C that was worth documenting. Now you
have changed C and the behavior of A is probably wrong (or at least
wasteful).
Not
1 - 100 of 1336 matches
Mail list logo
