On Wed, Apr 3, 2013 at 2:02 PM, Eric Seidel e...@webkit.org wrote:
p.s. Adam and I are happy to work with other reviewers to remove
PLATFORM(CHROMIUM) code and other messes we may have caused over the
years from webkit.org. Adam and I are still running queues.webkit.org
and associated
On Sat, Feb 9, 2013 at 7:41 PM, Maciej Stachowiak m...@apple.com wrote:
Hi Peter,
On Feb 9, 2013, at 3:48 PM, Peter Kasting pkast...@google.com wrote:
On Sat, Feb 9, 2013 at 11:52 AM, Maciej Stachowiak m...@apple.com wrote:
There are certainly pros and cons to merging. It would be great
If you expand diff context and then publish comments, the review tool might
drop some of your comments. I'll have this fixed today. In the meantime, if
you avoid expanding context or reload the page before publishing, you
should avoid hitting this bug.
Should be fixed. Let me know if you see problems.
On Wed, Jan 2, 2013 at 11:41 AM, Ojan Vafai o...@chromium.org wrote:
If you expand diff context and then publish comments, the review tool
might drop some of your comments. I'll have this fixed today. In the
meantime, if you avoid expanding
On Tue, Dec 11, 2012 at 12:17 PM, Emil A Eklund e...@chromium.org wrote:
I'll have to disagree with you here.
If the build is broken and the gardener/build cop has a strong reason
to suspect that it was caused by a specific patch and the author is
unavailable then rolling that patch out is
On Tue, Dec 11, 2012 at 1:11 PM, Emil A Eklund e...@chromium.org wrote:
On Tue, Dec 11, 2012 at 12:19 PM, Ojan Vafai o...@chromium.org wrote:
On Tue, Dec 11, 2012 at 12:17 PM, Emil A Eklund e...@chromium.org
wrote:
I'll have to disagree with you here.
If the build is broken
On Tue, Nov 27, 2012 at 1:47 PM, Ojan Vafai o...@chromium.org wrote:
As I said on the thread you link to, I don't think this element addresses
any real use-cases. I think people are far too likely to misuse this for it
to be useful for things like readability to use.
If Apple really wants
As I said on the thread you link to, I don't think this element addresses
any real use-cases. I think people are far too likely to misuse this for it
to be useful for things like readability to use.
If Apple really wants this, I won't object, but my preference would be to
not implement this.
On
I don't have strong opinions on this, but one advantage of using the
keywords and getting rid of the dedicated TestExpectations files would be
to make the fallback graph actually be a tree instead of a DAG. This would
simplify the rebaselining tooling considerably and allow us to make a bunch
of
though. Fewer flags == better. We already have too many flags.
-Z
On Thu, Nov 8, 2012 at 10:43 AM, Balazs Kelemen kbal...@webkit.orgwrote:
On 11/08/2012 02:51 AM, Ojan Vafai wrote:
On Wed, Nov 7, 2012 at 12:41 PM, Dirk Pranke dpra...@chromium.orgwrote:
On Tue, Nov 6, 2012 at 11:58
On Thu, Nov 1, 2012 at 10:13 AM, Elliott Sprehn espr...@chromium.orgwrote:
On Thu, Nov 1, 2012 at 4:42 AM, Maciej Stachowiak m...@apple.com wrote:
I like the idea of being more like native control behavior.
I agree. I'll update the patch to match Gecko's mostly native, but web
friendly
On Thu, Nov 1, 2012 at 12:32 PM, Peter Kasting pkast...@chromium.orgwrote:
It seems worth noting over here that on the whatwg discussion for this,
native really means Mac and Ubuntu. Notably it's not clear whether
this matches Windows, which is 90+% of the userbase for Chrome. I am a
little
I'd like to r+ https://bugs.webkit.org/show_bug.cgi?id=96335, but wanted to
give a heads up in case anyone wants to object.
Every native platform that has scrollbars does *not* move focus when you
click on them. Every browser engine, except Gecko, moves focus when you
click on scrollbars *unless*
On Wed, Oct 31, 2012 at 2:29 PM, Peter Kasting pkast...@chromium.orgwrote:
On Wed, Oct 31, 2012 at 1:32 PM, Ojan Vafai o...@chromium.org wrote:
Every native platform that has scrollbars does *not* move focus when you
click on them. Every browser engine, except Gecko, moves focus when you
On Wed, Oct 31, 2012 at 3:14 PM, Peter Kasting pkast...@chromium.orgwrote:
On Wed, Oct 31, 2012 at 2:40 PM, Ojan Vafai o...@chromium.org wrote:
On Wed, Oct 31, 2012 at 2:29 PM, Peter Kasting pkast...@chromium.orgwrote:
Is there rationale for Gecko's behavior? It sounds a bit strange
FWIW, here's an example of something from the spec that I think is stable
enough to implement without further waiting:
https://bugs.webkit.org/show_bug.cgi?id=100785.
On Wed, Oct 24, 2012 at 5:10 PM, Ojan Vafai o...@chromium.org wrote:
On Thu, Oct 18, 2012 at 7:00 PM, Wez w...@chromium.org
I don't understand. The www-dom discussion ends with a clear consensus to
use a new property name. There were no objections to systemTime. The
public-web-perf discussion didn't have an objections and just wanted to
wait until the V2 spec:
When you do a scroll, we fire fake mouse events and update hover state. We
currently try to throttle those events, but do very little throttling in
practice.
The patch below makes it so that we only fire a single set of fake mouse
events and only update the hover state once during a scroll. This
TL;DR: We should add a NeedsRebaseline keyword to TestExpectations and add
garden-o-matic tooling for it for the cases where someone commits a
change/test that they know will need new results for different ports (e.g.
any patch that changes the rendering of pixel tests).
A common pattern that I
bcc: chromium-dev
If you are still running 10.7.4, you'll start getting pixel layout test
failures due to different anti-aliasing. See
http://trac.webkit.org/changeset/130233 for the list of tests that would
fail.
FWIW, the build.webkit.org Chromium Mac bot is 10.6.
better for web developers. It's actually not that big of a deal
if the error messages from different browsers are different.
On Mon, Oct 1, 2012 at 4:56 PM, Ojan Vafai o...@google.com wrote:
This isn't spec'ed anywhere. I agree it would be ideal to get a spec for
this, but I don't think we
Fixing the problem will likely take less time at this point than rolling
the patch out as there are a number of dependent patches. The fix should be
in soon.
On Thu, Sep 20, 2012 at 11:10 AM, Geoffrey Garen gga...@apple.com wrote:
I'd prefer to see the patch rolled out.
Geoff
On Sep 20,
In practice, with the chromium TestExpectations, I've found that it forces
people to document the history of why a test was added and gives a forum
for discussing fixes (e.g. for flaky tests). It's hard to do this with a
single comment. It has been a net positive in my opinion.
Take the following
On Thu, Sep 13, 2012 at 12:06 PM, Dirk Pranke dpra...@chromium.org wrote:
On Wed, Sep 12, 2012 at 11:00 PM, Maciej Stachowiak m...@apple.com wrote:
On Sep 12, 2012, at 10:36 PM, Ojan Vafai o...@chromium.org wrote:
On Wed, Sep 12, 2012 at 6:40 PM, Maciej Stachowiak m...@apple.com
wrote
On Wed, Sep 12, 2012 at 6:40 PM, Maciej Stachowiak m...@apple.com wrote:
- Is this approach substantially less time and effort than adding a
histogram-style metric? I expect you have added a histogram to Chrome at
some point, and so can comment on the relative difficulty and time to
produce
On Fri, Aug 24, 2012 at 11:19 PM, Benjamin Poulain benja...@webkit.orgwrote:
On Fri, Aug 24, 2012 at 10:18 PM, Adam Barth aba...@webkit.org wrote:
[[[
The difference between the version is if the length of the string is
included or not. Having the size given in the constructor makes the
On Fri, Aug 24, 2012 at 4:42 AM, Žan Doberšek zandober...@gmail.com wrote:
On Fri, Aug 24, 2012 at 4:35 AM, Dominik Röttsches
dominik.rottsc...@intel.com wrote:
Hi Dirk,
On 08/22/2012 10:49 PM, Dirk Pranke wrote:
The Chromium canaries now exit after 5000 failures or 1000
IIRC, the chromium bots no longer exit early due to a large number of
failures (right Dirk?), only due to a large number of crashes/timeouts. So,
it should be possible to commit this, wait for the bots to cycle, do all
the rebaselines at once and commit that. The only delay is that we'd have
to
On Mon, Aug 20, 2012 at 6:03 PM, Maciej Stachowiak m...@apple.com wrote:
Here's how I imagine the workflow when a sheriff or just innocent
bystander notices a deterministically failing test. Follow this two-step
algorithm:
1) Are you confident that the new result is an improvement or no
, 2012 at 6:47 PM, Ojan Vafai o...@chromium.org wrote:
Next week we plan to remove the CSS3_FLEXBOX define again. We had added
it
back in because the spec was about to change a lot (mostly renaming). At
this point the spec is stable and has been approved to go to CR.
Also, our implementation
Asserting a test case is 100% correct is nearly impossible for a large
percentage of tests. The main advantage it gives us is the ability to have
-expected mean unsure.
Lets instead only add -failing (i.e. no -passing). Leaving -expected to
mean roughly what it does today to Chromium folk
the following: are we agreeing that all current uses
of TEXT, IMAGE, and so forth in TestExpectations should be in the *very
near term* following Dirk's change be turned into -failing files?
-Filip
On Aug 17, 2012, at 5:01 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Fri, Aug 17, 2012 at 4:55 PM, Ojan
Next week we plan to remove the CSS3_FLEXBOX define again. We had added it
back in because the spec was about to change a lot (mostly renaming). At
this point the spec is stable and has been approved to go to CR.
Also, our implementation has been fuzz-tested for crashes/memory errors.
I'm fairly
, Ojan Vafai o...@chromium.org wrote:
+1
On Fri, Aug 17, 2012 at 5:36 PM, Ryosuke Niwa rn...@webkit.org wrote:
That's my expectation although we probably can't do that for flaky tests
:(
e.g. sometimes fails with image diff.
On Fri, Aug 17, 2012 at 5:35 PM, Filip Pizlo fpi...@apple.com
On Thu, Aug 16, 2012 at 2:32 PM, Filip Pizlo fpi...@apple.com wrote:
1) Switching to skipping flaky tests wholesale in all ports would be
great, and then we could get rid of the flakiness support.
Then you don't notice when a flaky tests stops being flaky. The cost of
flakiness support on the
I think this is the best compromise between the benefits of the
historically chromium approach (i.e. add to TestExpectations) and the
historically non-chromium approach (either skip the test or check in a
failing result, usually the latter). The only thing Dirk's proposal changes
for these ports
See https://bugs.webkit.org/show_bug.cgi?id=93195.
media/W3C/video/networkState/networkState_during_progress.html
and media/video-poster-blocked-by-willsendrequest.html are flaky on all
platforms because they behave differently if the loaded resource is cached.
Every time I've taken a stab at
On Tue, Jul 31, 2012 at 10:05 PM, Kihong Kwon vim...@gmail.com wrote:
Has a test suite been published we can test against?
I didn't see a test suite which is opened to everyone yet.
Is this a problem for dropping prefix?
It's not strictly required for dropping the prefix. But it would be
https://trac.webkit.org/wiki/Rebaseline
I've recently consolidated the various rebaseline commands and made the
tool work for non-Chromium ports.
I especially like webkit-patch rebaseline path/to/test/i/just/broke.html,
which lets you easily rebaseline the test for all ports once the bots have
If someone feels like doing extra hacking to improve this, I'm happy to
walk you through the code. It'd be awesome if you could expand out that
section to show which revision has been run on each bot.
https://bugs.webkit.org/show_bug.cgi?id=91163
On Thu, Jul 12, 2012 at 4:18 PM, Peter Kasting
On Wed, Jul 11, 2012 at 8:43 AM, John Mellor joh...@chromium.org wrote:
On Wed, Jul 11, 2012 at 4:21 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, Jul 11, 2012 at 6:54 AM, John Mellor joh...@chromium.org wrote:
Even obvious (to some) concepts like InlineBox have subtleties, for
example
On Thu, Jun 14, 2012 at 4:34 PM, Dirk Pranke dpra...@chromium.org wrote:
On Thu, Jun 14, 2012 at 4:22 PM, Maciej Stachowiak m...@apple.com wrote:
On Jun 14, 2012, at 1:47 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Thu, Jun 14, 2012 at 1:44 PM, Peter Kasting pkast...@chromium.org
On Thu, Jun 14, 2012 at 9:00 PM, Adam Barth aba...@webkit.org wrote:
On Thu, Jun 14, 2012 at 8:56 PM, Ojan Vafai o...@chromium.org wrote:
On Thu, Jun 14, 2012 at 4:34 PM, Dirk Pranke dpra...@chromium.org
wrote:
On Thu, Jun 14, 2012 at 4:22 PM, Maciej Stachowiak m...@apple.com
wrote
On Thu, Jun 14, 2012 at 9:20 PM, Maciej Stachowiak m...@apple.com wrote:
On Jun 14, 2012, at 9:06 PM, Adam Barth aba...@webkit.org wrote:
On Thu, Jun 14, 2012 at 9:02 PM, Ojan Vafai o...@chromium.org wrote:
Seems like it will be a common error to mark a reftest failure as
ImageOnlyFail
On Mon, Jun 11, 2012 at 9:32 PM, Filip Pizlo fpi...@apple.com wrote:
I think that a lot of the performance penalty can be alleviated by:
1) Moving rarely executed paths into non-inlineable methods.
2) Marking the various refing methods ALWAYS_INLINE, after you've moved as
much as possible
On Tue, Jun 12, 2012 at 9:50 AM, Darin Adler da...@apple.com wrote:
On Jun 11, 2012, at 7:33 PM, Mike Lawther wrote:
Does having the 'fast' directory still serve a useful purpose?
Not sure it does.
The original intent was to put more extensive complete tests that were
slow but had
On Tue, Jun 12, 2012 at 10:18 AM, Alexey Proskuryakov a...@webkit.org wrote:
12.06.2012, в 9:59, Ojan Vafai написал(а):
One more item I'd add to this list:
-Replace js-test-post.js with an onload handler in js-test-pre.js so we
can get rid of that file entirely.
I think
See https://bugs.webkit.org/show_bug.cgi?id=87772.
It's great to use a fuzzer in order to find cases where we're broken and
then make reduced layout tests from those. The viewspec-parser tests are
themselves just a fuzzer though. Granted, they are deterministic by
avoiding using an actual random
On Sun, Jun 10, 2012 at 4:54 AM, Balazs Kelemen kbal...@webkit.org wrote:
So the unit tests are superfluous. In particular, if I had to pick
between only having unit tests or only having regression tests, I might
pick unit tests. But if I already have regression tests then I'm unlikely
to
Can you just expand out FAIL to it's equivalent longform? FAIL == TEXT
IMAGE IMAGE+TEXT. I don't see a need to block the infrastructure change on
this as the semantics are exactly the same. You can just find/replace every
instance of FAIL.
On Fri, Jun 8, 2012 at 10:12 PM, Ryosuke Niwa
On Fri, Jun 8, 2012 at 12:46 AM, Osztrogonac Csaba o...@inf.u-szeged.huwrote:
Hi,
Dirk Pranke írta:
I believe most if not all of the ports have started using either
TestExpectations files or a combination of TestExpectations files
(except for the Apple Win port).
Can we explicitly
On Fri, Jun 8, 2012 at 9:25 AM, Filip Pizlo fpi...@apple.com wrote:
On Jun 8, 2012, at 9:16 AM, Balazs Kelemen wrote:
On 06/08/2012 05:21 PM, Filip Pizlo wrote:
On Jun 8, 2012, at 4:38 AM, Balazs Kelemenkbal...@webkit.org wrote:
On 06/08/2012 09:46 AM, Osztrogonac Csaba wrote:
Hi,
On Fri, Jun 8, 2012 at 10:14 AM, Zoltan Herczeg zherc...@webkit.org wrote:
Hi,
I don't see why it would make sense to keep two parallel tools for this
once all the workflow bugs people have are addressed.
The reason is easy. In the past when people tried to add new features to
NRWT, they
Speaking of differences between NRWT and ORWT, ORWT doesn't limit to n
failures by default. NRWT limits to 500 by default. It looks like all the
bots pass in --exit-after-n-failures=500. Any objection to making NRWT
match ORWT here? I don't think having this limit is useful/necessary for
local
On Fri, Jun 8, 2012 at 12:08 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Fri, Jun 8, 2012 at 12:05 PM, Ojan Vafai o...@chromium.org wrote:
We'll still default --exit-after-n-crashes-or-timeouts to 20. That seems
more useful to me since you'd rarely hit this case locally and want to
continue
testController seems fine to me. I agree it's an improvement.
On the other hand there are other tasks that have more benefit in terms of
code maintenance for people wanting to spend time working in this area. A
couple ideas:
- Move more APIs that only depend WebCore code to internals. Reduces
Darin, sorry for derailing this thread. I suppose I should have changed the
subject. :)
On Thu, May 31, 2012 at 1:51 PM, Jesus Sanchez-Palencia je...@webkit.orgwrote:
Just a heads-up: there is a meta bug tracking this at
https://bugs.webkit.org/show_bug.cgi?id=87284 .
A few folks have been
Do you just need to force a layout at the end of repaintTest, e.g.
document.body.offsetHeight;?
On Thu, May 24, 2012 at 6:34 AM, Andrei Bucur andrei.bu...@gmail.comwrote:
Hello WebKittens,
I'm trying to simplify the patch for a certain repaint bug (
, May 24, 2012 at 11:57 PM, Ojan Vafai o...@chromium.org wrote:
Do you just need to force a layout at the end of repaintTest, e.g.
document.body.offsetHeight;?
On Thu, May 24, 2012 at 6:34 AM, Andrei Bucur andrei.bu...@gmail.comwrote:
Hello WebKittens,
I'm trying to simplify the patch
On Thu, May 17, 2012 at 10:37 PM, Maciej Stachowiak m...@apple.com wrote:
On May 17, 2012, at 7:27 PM, Ojan Vafai o...@chromium.org wrote:
On Thu, May 17, 2012 at 4:29 PM, Maciej Stachowiak m...@apple.com wrote:
On May 17, 2012, at 1:42 PM, Ojan Vafai o...@chromium.org wrote:
On Thu, May
I have a proposal that hopefully addresses everyone's concerns, is
minimally different from the current format *and* unifies the format with
Skipped lists (i.e. Skipped lists as they exist today are valid
test_expectations.txt format). The changes from the current format are as
follows:
-Leaving
On Thu, May 17, 2012 at 1:37 PM, Peter Kasting pkast...@chromium.orgwrote:
On Thu, May 17, 2012 at 1:34 PM, Ojan Vafai o...@chromium.org wrote:
2. Make outcomes optional. If they are left out, then the test is skipped
(unless the test is marked SLOW, in which case it's expected to pass
On Thu, May 17, 2012 at 2:06 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Thu, May 17, 2012 at 2:05 PM, Ojan Vafai o...@chromium.org wrote:
On Thu, May 17, 2012 at 2:02 PM, Ryosuke Niwa rn...@webkit.org wrote:
Seems reasonable as the first step except:
On Thu, May 17, 2012 at 1:34 PM, Ojan
On Thu, May 17, 2012 at 2:16 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Thu, May 17, 2012 at 2:11 PM, Ojan Vafai o...@chromium.org wrote:
Oh, I supposed I misread Peter's earlier email as being opposed to this.
But, I for one am opposed to it. I find the jumble of modifiers in the
second
On Thu, May 17, 2012 at 2:29 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Thu, May 17, 2012 at 2:19 PM, Ojan Vafai o...@chromium.org wrote:
On Thu, May 17, 2012 at 2:16 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Thu, May 17, 2012 at 2:11 PM, Ojan Vafai o...@chromium.org wrote:
Oh, I
On Thu, May 17, 2012 at 3:37 PM, Dirk Pranke dpra...@chromium.org wrote:
On Thu, May 17, 2012 at 3:21 PM, Ryosuke Niwa rn...@webkit.org wrote:
Perhaps we can address these two problems using some tools. e.g. I don't
care about the format of test_expectations.txt at all if there was a GUI
On Thu, May 17, 2012 at 4:29 PM, Maciej Stachowiak m...@apple.com wrote:
On May 17, 2012, at 1:42 PM, Ojan Vafai o...@chromium.org wrote:
On Thu, May 17, 2012 at 1:37 PM, Peter Kasting pkast...@chromium.orgwrote:
On Thu, May 17, 2012 at 1:34 PM, Ojan Vafai o...@chromium.org wrote:
2. Make
Closing the loop...bug filed
https://bugs.webkit.org/show_bug.cgi?id=86796 minus
item 2 since that turned out to be controversial.
On Thu, May 17, 2012 at 1:34 PM, Ojan Vafai o...@chromium.org wrote:
We are arguing about too many orthogonal things at once. It seems like
there are a few things
The amount of spam we throw in the developer console has grown quite a bit.
spam == things logged to the console that web developers have no control
over
Unlike uncaught javascript exceptions (which can easily just be caught),
there is no way to prevent the following from cluttering your
On Fri, May 11, 2012 at 2:25 PM, Adam Barth aba...@webkit.org wrote:
On Fri, May 11, 2012 at 2:21 PM, Ojan Vafai o...@chromium.org wrote:
The amount of spam we throw in the developer console has grown quite a
bit.
spam == things logged to the console that web developers have no control
On Fri, May 11, 2012 at 2:39 PM, Maciej Stachowiak m...@apple.com wrote:
On May 11, 2012, at 2:21 PM, Ojan Vafai o...@chromium.org wrote:
The amount of spam we throw in the developer console has grown quite a
bit.
spam == things logged to the console that web developers have no control
On Fri, May 11, 2012 at 2:48 PM, Ojan Vafai o...@chromium.org wrote:
On Fri, May 11, 2012 at 2:39 PM, Maciej Stachowiak m...@apple.com wrote:
On May 11, 2012, at 2:21 PM, Ojan Vafai o...@chromium.org wrote:
The amount of spam we throw in the developer console has grown quite a
bit
Bugs filed.
Navigation warnings: https://bugs.webkit.org/show_bug.cgi?id=86263.
clientX/clientY: https://bugs.webkit.org/show_bug.cgi?id=86264. Would be
good for someone informed on that issue to chime in.
On Fri, May 11, 2012 at 3:08 PM, Ojan Vafai o...@chromium.org wrote:
On Fri, May 11
That's a great milestone. Congratulations!
On Thu, May 10, 2012 at 8:43 AM, Dominik Röttsches
dominik.rottsc...@intel.com wrote:
Hi all,
We're happy to share with you that yesterday the EFL Linux Debug Buildbot
has turned green for the first time.
, 2012 at 7:12 AM, Ojan Vafai o...@chromium.org wrote:
I see. That's unfortunate. I don't really know the best path forward
here.
I'm inclined to agree with Alexey that we should at least try to
st
ndardize
this before committing code. It's not clear to me where
Instead of UA faking, is it possible for you to pick an actual UA string
that is more compatible with the web at large? For Chromium we experimented
with making the most minimal UA string possible without a big loss in web
compatibility. To our disappointment, we found we had to match the Safari
that this is not a unique case and it will only be
solved the day content providers stop looking at the user agent
strings.
Kenneth
On Fri, May 4, 2012 at 11:32 PM, Ojan Vafai o...@chromium.org wrote:
Instead of UA faking, is it possible for you to pick an actual UA string
that is more
Good to know. I had stopped paying attention to many of the Apple bots for
the reason you mention.
It would be really helpful if someone could make the webkit-patch tooling
works correctly for the non-Chromium bots. Specifically, webkit-patch
rebaseline-test and webkit-patch garden-o-matic. They
Ossy, I think the right thing to do, in general, with failing reftests is
to skip them.
Dave, you can see the chromium win/linux failures here (it passes on
chromium mac):
On Thu, Apr 12, 2012 at 12:50 PM, Robert Hogan li...@roberthogan.netwrote:
On Thursday 12 April 2012 00:58:47 Ryosuke Niwa wrote:
On Wed, Apr 11, 2012 at 4:45 PM, Ojan Vafai o...@chromium.org wrote:
I agree with the sentiment that we should be upstreaming these to the
W3C, but I don't
:
Isn't the goal of writing a ref test that it is not platform specific?
From: Ryosuke Niwa rn...@webkit.org
Date: Thu, 12 Apr 2012 12:29:42 -0700
To: Ojan Vafai o...@chromium.org
Cc: Dirk Pranke dpra...@chromium.org, WebKit Development
webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev
, or is having
platform-specific ref tests acceptable? Doesn't that put us in the same
situation as having platform-specific pixel tests?
From: Ryosuke Niwa rn...@webkit.org
Date: Thu, 12 Apr 2012 13:43:26 -0700
To: Jacob Goldstein jac...@adobe.com
Cc: Ojan Vafai o...@chromium.org, Dirk Pranke dpra
Typically, if you're working on Chromium Linux or Win, you'd include the
new expected results for that platform in your initial commit/code-review
as well.
On Wed, Apr 11, 2012 at 2:09 PM, Tony Payne tpa...@chromium.org wrote:
All code I'm changing is inside of #if PLATFORM(CHROMIUM) blocks.
On Wed, Apr 11, 2012 at 3:48 PM, Dirk Pranke dpra...@chromium.org wrote:
On Wed, Apr 11, 2012 at 3:46 PM, Dirk Pranke dpra...@chromium.org wrote:
On Fri, Mar 9, 2012 at 2:49 PM, Sam Weinig wei...@apple.com wrote:
On Mar 7, 2012, at 4:41 PM, Ojan Vafai wrote:
I just did a first pass
I don't think we can come up with a hard and fast rule given current
tooling. In a theoretical future world in which it's easy to get expected
results off the EWS bots (or some other infrastructure), it would be
reasonable to expect people to incorporate the correct expected results for
any
One case where this matters: div
style=-webkit-user-select:nonefoo/divbar
If you mousedown on foo and drag right, you want to start selecting bar. In
the common case, we don't do any walking. The next position we grab from
the iterator is valid and we use it.
On Thu, Mar 29, 2012 at 7:27 AM,
Sometime this week or next, we plan to change the Chromium layout test
fallback order. We'll be changing it so all chromium ports fallback to
platform/chromium, then to platform/mac. They will never fallback to
platform/win or platform/mac-* as they do today.
The benefits of this change are that
I've recently been greening Chromium's expectations for css3/selectors3.
~10% of these test need interaction (e.g. hovering over a link or selecting
text). Given that this is an imported test suite does it make sense to add
the appropriate layoutTestController hooks? As it is, the tests aren't
Whoops. A lot of these were from me yesterday. Sorry, I didn't realize I
didn't have my subversion config set correctly.
I went to fix up my commits from yesterday and realized that a very large
percentage of the pngs in the LayoutTests tree have the wrong
svn:mime-type. Is anyone opposed to me
I just did a first pass a greening the Chromium Lion bot:
http://trac.webkit.org/changeset/110096. Of these hundreds of tests, ~99%
of them are perfect candidates for being reftests (e.g. they contain one
line of text and a solid box or two under the text), but most of them are
in the CSS
imported test suites. That will just make it
more confusing to update. Perhaps future CSS test suites will be changed to
a reftest model.
Regards,
Maciej
On Mar 7, 2012, at 1:41 PM, Ojan Vafai wrote:
I just did a first pass a greening the Chromium Lion bot:
http://trac.webkit.org/changeset
On Wed, Mar 7, 2012 at 4:50 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, Mar 7, 2012 at 4:44 PM, Darin Fisher da...@chromium.org wrote:
Hrm, if the test expectations are customized already for different ports
of WebKit, then why not support replacing a PNG file with a HTML file that
is
We have a lot of code (e.g. in ContainerNode.cpp or any of the editing
code) that needs to RefPtr nodes to make sure they're not destroyed due to
synchronous events like blur, mutation events, etc. For example,
ContainerNode::removeChild needs to RefPtr the parent to make it's not
destroyed during
ref rather than churning it or where we could use a
free list rather than a vector. I just wonder if there's a way to get
the benefits with a lower cost.
Adam
On Thu, Mar 1, 2012 at 4:50 PM, Ojan Vafai o...@chromium.org wrote:
We have a lot of code (e.g. in ContainerNode.cpp or any
On Wed, Feb 29, 2012 at 12:43 AM, Sergio Villar Senin svil...@igalia.comwrote:
En 29/02/12 09:33, Konstantin Tokarev escribiu:
Although I normally use it for cherry-picking a commit to upload, I have
always missed the option to upload a bunch of commits as a single patch.
Basically, as
On Mon, Feb 27, 2012 at 5:56 PM, Dirk Pranke dpra...@chromium.org wrote:
Hi all,
If you don't use webkit-patch and Git, you can stop reading now. Otherwise
...
Currently, webkit-patch -g has some special logic for figuring out
what to diff against for Git checkouts.
Specifically,
This seems fine to me. The most important thing here is standardizing what
we ship to the web platform.
On Thu, Feb 16, 2012 at 4:44 PM, Aaron Boodman a...@chromium.org wrote:
Hello again,
I'd like to revise my proposal on deprecating HTML notifications in
Chrome extensions: I would like to
On Mon, Feb 13, 2012 at 1:06 PM, Maciej Stachowiak m...@apple.com wrote:
On Feb 10, 2012, at 4:20 PM, Dirk Pranke wrote:
I think at one point Adam indicated he wanted to use them for the
Apple Win port, but he is still using the Skipped files since the Win
port is still using ORWT on the
On Mon, Feb 13, 2012 at 3:09 PM, Maciej Stachowiak m...@apple.com wrote:
On Feb 13, 2012, at 1:40 PM, Ojan Vafai wrote:
On Mon, Feb 13, 2012 at 1:06 PM, Maciej Stachowiak m...@apple.com wrote:
On Feb 10, 2012, at 4:20 PM, Dirk Pranke wrote:
For example, we might want to use only
On Fri, Feb 10, 2012 at 6:14 PM, Adam Barth aba...@webkit.org wrote:
On Fri, Feb 10, 2012 at 6:09 PM, Levi Weintraub le...@google.com wrote:
On Fri, Feb 10, 2012 at 6:03 PM, Adam Barth aba...@webkit.org wrote:
On Fri, Feb 10, 2012 at 5:49 PM, Levi Weintraub le...@google.com
wrote:
1 - 100 of 305 matches
Mail list logo
