Actually, the data is messed up. It's the windows bots. The path isn't being
made relative properly. It's getting full windows paths in the results.json
file. We'll need to do a cleanup pass. Dirk, you want to do that, or should
I?
On Thu, Jan 14, 2010 at 10:40 AM, Ojan Vafai o...@google.com
Ugh. It looks like the data all got clobbered as well. That should only
happen if the JSON file got corrupted somehow. Not really sure how that
happened. In either case, all there is to do right now is to fix the windows
paths.
On Thu, Jan 14, 2010 at 11:43 AM, Ojan Vafai o...@chromium.org wrote
, Ojan Vafai o...@chromium.org wrote:
Ugh. It looks like the data all got clobbered as well. That should only
happen if the JSON file got corrupted somehow. Not really sure how that
happened. In either case, all there is to do right now is to fix the windows
paths.
On Thu, Jan 14, 2010 at 11
I finally wrote a mini-design doc for the layout test
dashboardhttp://www.chromium.org/developers/design-documents/layout-tests-results-dashboard
.
Getting this to work for other tests (e.g. browser_tests, unit_tests, etc)
would be a pretty small amount of Python work. If anyone is interested in
Does this include the pending/ directory as well?
On Fri, Dec 18, 2009 at 6:59 PM, Dirk Pranke dpra...@chromium.org wrote:
I have either deleted or submitted patches to upstream all of the
remaining tests under chrome/ . There are a few that appear to be
platform-specific, but most weren't.
(3) forks run_webkit_tests.py upstream.
(4) Make it possible to run the tests with TestShell while
run_webkit_tests.py is upstream.
(5) Change the chromium bots to use the upstream run_webkit_tests.py
That all seems fine. But then we have to leave the forked copy in there
until the last step (13)
On Mon, Dec 14, 2009 at 10:55 AM, Ojan Vafai o...@google.com wrote:
On Mon, Dec 14, 2009 at 10:36 AM, David Levin le...@chromium.org wrote:
On Mon, Dec 14, 2009 at 10:24 AM, Scott Hess sh...@chromium.org wrote:
Also, last time I was looking through some valgrind suppressions, I
found
). I don't like
(9), and I like (10) even less, since both of these options actually
undo much of my previous work and produce test scripts that I want to
use less than the versions that exist now.
-- Dirk
On Mon, Dec 14, 2009 at 3:37 PM, Ojan Vafai o...@chromium.org wrote:
On Mon, Dec 14
. In a followup patch, I'll make it print out each shard as
we go for the default case of sharding by directory.
Ojan
On Mon, Dec 14, 2009 at 4:46 PM, Ojan Vafai o...@chromium.org wrote:
+chromium-dev
I don't think having a third mode makes sense. We should have terse
(default) and verbose (--verbose
Sigh. Now from the right email address.
On Fri, Dec 11, 2009 at 11:36 AM, Ojan Vafai o...@google.com wrote:
I thought we had agreed on printing out any unexpected failures in
real-time, no?
Also, I do think it would be worthwhile to print each directory as it
finishes. We're getting
Summary:
We're increasing sharding for running webkit tests and it's increasing test
flakiness a bit.
1. Is the tradeoff of (hopefully) temporary increased flakiness worth the
speed gains? We retry these failures, so they rarely actually turn the bots
red,
2. The flakiness is temporary only if we
On Thu, Dec 10, 2009 at 4:38 PM, Avi Drissman a...@google.com wrote:
On Thu, Dec 10, 2009 at 7:36 PM, Evan Martin ev...@google.com wrote:
Distributing binaries on Linux = sadness, as the Flash guys will tell
you.
[...]
In summary, all I offer you is more problems and the plea that we
at 10:07 AM, Ojan Vafai o...@google.com wrote:
The test is consistently crashing when run with all the other tests, but
passing when we retry it in isolation. Note that the test is listed as an
unexpected flaky test on the waterfall. This is one of the downsides of
retrying failing tests. We
As of yesterday, we now retry any unexpected webkit failures. If they pass
the second time around, then we turn the bot orange and list the unexpected
flaky tests on the waterfall and at the end of the stdio of
run_webkit_test.py. If they fail the second time around we turn the bot red
as usual.
A few changes to the layout test dashboard you might not be aware of if you
haven't used it in a while:
- You can see the expected results, actual results and diffs between the
two for a given test. This is especially useful when doing rebaseline code
reviews. The results shown are the
On Fri, Nov 13, 2009 at 1:25 PM, Peter Kasting pkast...@google.com wrote:
On Fri, Nov 13, 2009 at 1:15 PM, Finnur Thorarinsson fin...@google.comwrote:
If the sheriff load is too much for two people to devote 100% of their
time to, then there is something wrong with the process.
It's
This is a long-standing WebKit bug. The current behavior is correct for Mac.
Linux/Win should behave as you expect. Patches welcome. :)
On Thu, Nov 12, 2009 at 8:20 AM, John Tamplin j...@google.com wrote:
One thing that drives me nuts using GMail in Chrome compared to Firefox, is
the behavior
On Thu, Nov 12, 2009 at 9:46 AM, Peter Kasting pkast...@google.com wrote:
On Thu, Nov 12, 2009 at 9:41 AM, Ojan Vafai o...@google.com wrote:
This is a long-standing WebKit bug. The current behavior is correct for
Mac. Linux/Win should behave as you expect. Patches welcome. :)
Isn't
+chrome-devtools-team
I think this is a general UI problem that needs to be solved for the
inspector. There are increasingly more and more pages we have that don't
have a page visible to the developer (sharedworkers, extensions background
pages, etc.). I can't think of any good solutions off the
On Tue, Nov 3, 2009 at 1:53 PM, Nicolas Sylvain nsylv...@chromium.orgwrote:
This is really important to keep the tree green and open. The old saying
is Revert now, think later... If a change broke the build and the fix
would
take more than 1 or 2 minutes to be committed, or if the committer
Can you give example outputs for the common cases? It would be easier to
discuss those.
On Fri, Oct 23, 2009 at 3:43 PM, Dirk Pranke dpra...@chromium.org wrote:
If you've never run run_webkit_tests to run the layout test
regression, or don't care about it, you can stop reading ...
If you
LayoutTests/fast/loader/local-JavaScript-from-local.html
On Thu, Oct 15, 2009 at 6:38 PM, Ojan Vafai o...@google.com wrote:
There are a lot of tests that consistently (i.e. not flaky) timeout. They
eat up significant percentage (~10%!) of the cycle time for the test bots
(e.g., 1 minute on Windows
, Ojan Vafai o...@google.com wrote:
Thanks for everyone's help. Good overnight progress. 6 media tests
skipped. 2 tests marked SLOW. 5 assigned.
12 unassigned general tests.
10 unassigned Mac plugin tests.
Any takers?
WIN/LINUX/MAC
LayoutTests/fast/dom/cssTarget-crash.html
LayoutTests/fast
Replying off-list as requested...
Firstly, this is awesome!
On Wed, Oct 14, 2009 at 10:35 PM, Chase Phillips ch...@chromium.org wrote:
git-cl upload
Runs presubmit tests on upload, continues even if tests fail.
This latter part is different than the gcl version. Is that intentional? I
, Ojan Vafai o...@google.com wrote:
The data is stored in a single file per bot. For example, the webkit
release bot's results are at
http://build.chromium.org/buildbot/layout_test_results/webkit-rel/results.json.
That
file holds all the historical data for that bot and is copied over during
On Thu, Oct 15, 2009 at 11:19 AM, Chase Phillips ch...@chromium.org wrote:
On Thu, Oct 15, 2009 at 10:38 AM, Ojan Vafai o...@chromium.org wrote:
Replying off-list as requested...
Right! ;)
Doh.
However, my tests of gcl upload show they already have the same behavior
here: gcl uploads
There are a lot of tests that consistently (i.e. not flaky) timeout. They
eat up significant percentage (~10%!) of the cycle time for the test bots
(e.g., 1 minute on Windows release). If LTTF folk focus some effort on
fixing these first, it would help all of us move forward faster as the bot
For those of you who rely on the layout test dashboard for identifying
flakiness, my apologies. I accidentally checked in some test code (one
number was wrong!) and clobbered all but 10 of the runs of data for each
builder. There's no way to recover it. We'll just need to wait for enough
runs for
a volunteer! :D :D :D
On Wed, Oct 14, 2009 at 4:15 PM, Jeremy Orlow jor...@chromium.org
wrote:
I assume we're going to start backing this data up from now on?
On Wed, Oct 14, 2009 at 4:13 PM, Peter Kasting pkast...@google.com
wrote:
On Wed, Oct 14, 2009 at 3:58 PM, Ojan Vafai o
We could rerun any unexpected fail/crash/timeout tests. If they pass the
second time around, then the tree turns orange instead of red. This has come
up many times, but we've never agreed on whether it's a good idea.
Pros:
-Easier to distinguish between flakiness and new failures
-Tree will be
red. This will provide more immediate feedback to people
trying to green to tree as to whether tests are flaky or regressions. It
would help with sheriffing/gardening without the other downsides.
Ojan
On Tue, Oct 13, 2009 at 12:02 PM, Ojan Vafai o...@chromium.org wrote:
We could rerun any
On Tue, Oct 13, 2009 at 3:50 PM, Andrew Scherkus scher...@chromium.orgwrote:
What's happening is loadstart fires and the video reloads which should
cause an abort event. For some reason load will occasionally fire after
loadstart, ending the test.
I know we can patch the test, but I've been
This seems like a Google Code bug to me. Pasting stacktraces should be a
use-case Google Code cares about. Have you filed a bug with them?
Ojan
On Fri, Oct 9, 2009 at 11:17 AM, Jeremy Moskovich jer...@chromium.orgwrote:
crbug.com appears to wrap input to the width of it's textarea, that means
On Tue, Oct 6, 2009 at 1:49 PM, Peter Kasting pkast...@google.com wrote:
On Tue, Oct 6, 2009 at 1:44 PM, Andrew Scherkus scher...@chromium.orgwrote:
We're getting slightly different pixel results depending on the position
of the sun. We have some WebKit patches underway that address our
They are marked WONTFIX. We run them to ensure they don't crash. This looks
like a bug in run_webkit_tests to me. For tests that are WONTFIX, we
shouldn't care if the expected results are missing.
Seems a bit silly to me that we run them at all though. I would be a fan of
just skipping the
. Situations where we're
willing to ignore one type of failure for an extended time should be rare.
I'd vote for keeping FAIL meaning image and/or text, and IMAGEFAIL for
temporary use meaning image-only.
- Pam
On Wed, Sep 23, 2009 at 6:52 PM, Ojan Vafai o...@chromium.org wrote:
I prefer IMAGE
There is not. But adding it would be easy. There's been mention of
doing this for a while, but noone has made the effort to make it work.
All you'd have to do is:
-modify a few lines in TestExpectationsFile in
src/webkit/tools/layout_tests/layout_package/test_expectations.py to
add support for
and text-only failures. Then
we can gradually excise the FAIL lines from text_expectations.
I think this would be a good permanent change, but I can see arguments
to the contrary.
Ojan
On Wed, Sep 23, 2009 at 12:25 PM, Ojan Vafai o...@chromium.org wrote:
There is not. But adding it would be easy
really embarassing.. J/K ;)
On Wed, Sep 23, 2009 at 3:33 PM, Ojan Vafai o...@chromium.org wrote:
+pam, tc, darin in case they disagree with what I'm saying here.
Also a bunch of current expectations would need to be modified. All
the cases where there is currently FAIL would need
On Tue, Sep 22, 2009 at 10:26 AM, Jeffrey Chang jeffr...@google.com wrote:
- Fix all Windows layout tests: make test_expectations.txt only contain
items that we will never fix, features we have not yet implemented, or bugs
less than one week old that are a result of a recent WebKit
On Tue, Sep 15, 2009 at 4:26 AM, Dirk Pranke dpra...@chromium.org wrote:
I have just landed a patch that enables us to run layout tests on
Vista as well as XP.
Thanks for doing this! Needing to run the tests on a 32bit XP machine sucks.
I don't think we can call running the tests on Vista
On Tue, Sep 15, 2009 at 2:24 PM, Dirk Pranke dpra...@chromium.org wrote:
Well, practically, there's very little difference between XP and Vista
(about 10 baselines).
I see. Looking at your rebaseline checkin, it looks like it's entirely
complex font tests as well. I think given that, it will
I'm including at the top concrete tasks people can take to help identify and
reduce flakiness. Read below for more details.
1. Mark slow tests as SLOW and reduce the timeout on the bots to 2
seconds.
2. Look into the cause of the timeouts on HTTP tests, especially on
Mac/Windows
3.
On Wed, Aug 26, 2009 at 5:12 PM, Ojan Vafai o...@chromium.org wrote:
One final update.
1. The bogus results on windows are gone.
2. BUG*** now actually links to the bug.
3. Hides WONTFIX tests by default, with a checkbox to show them.
4. Linux release bot is now listed (debug coming
On Tue, Sep 1, 2009 at 6:42 PM, Peter Kasting pkast...@google.com wrote:
On Tue, Sep 1, 2009 at 5:15 PM, Ojan Vafai o...@chromium.org wrote:
I lied. Another update worth spamming about.
The dashboard now by default hides both WONTFIX tests and tests that match
their expectations. This way
On Tue, Aug 25, 2009 at 10:15 AM, Ojan Vafai o...@chromium.org wrote:
One more thing (since people are asking), you can see all the platforms'
expectations for a test from the view for any builder. The ones that don't
apply to this builder are greyed out. For example, see
LayoutTests/fast/dom
, Aug 24, 2009 at 6:42 PM, Ojan Vafai o...@chromium.org wrote:
A first version of the layout test flakiness dashboard is up.
http://src.chromium.org/viewvc/chrome/trunk/src/webkit/tools/layout_tests/flakiness_dashboard.html
Some of the key features:
- updates roughly as quickly
On Mon, Aug 24, 2009 at 10:37 AM, Pam Greene p...@chromium.org wrote:
On Sat, Aug 22, 2009 at 4:29 PM, Jeremy Orlow jor...@chromium.org wrote:
On Sat, Aug 22, 2009 at 4:00 PM, Peter Kasting pkast...@chromium.orgwrote:
On Fri, Aug 21, 2009 at 8:07 PM, Jeremy Orlow jor...@chromium.orgwrote:
A first version of the layout test flakiness dashboard is up.
http://src.chromium.org/viewvc/chrome/trunk/src/webkit/tools/layout_tests/flakiness_dashboard.html
Some of the key features:
- updates roughly as quickly as the bots have run the tests (no
post-processing, stdio parsing or
On Fri, Aug 21, 2009 at 4:54 PM, Peter Kasting pkast...@chromium.orgwrote:
On Fri, Aug 21, 2009 at 4:50 PM, Dirk Pranke dpra...@chromium.org wrote:
This is all good feedback, thanks! To clarify, though: what do you
think the cost will be? Perhaps you are assuming things about how I
would
On Mon, Aug 10, 2009 at 3:12 AM, Jeremy Orlow jor...@chromium.org wrote:
On Sun, Aug 9, 2009 at 9:07 AM, Nicolas Sylvain nsylv...@chromium.orgwrote:
2. The show stopper for any implementation of this feature is that the
machines running the layout tests don't have the pdbs for test_shell.
On Mon, Aug 10, 2009 at 1:39 PM, Nicolas Sylvain nsylv...@chromium.orgwrote:
On Mon, Aug 10, 2009 at 10:35 AM, Jeremy Orlow jor...@chromium.orgwrote:
On Mon, Aug 10, 2009 at 9:59 AM, Ojan Vafai o...@chromium.org wrote:
On Mon, Aug 10, 2009 at 3:12 AM, Jeremy Orlow jor...@chromium.orgwrote
On Thu, Aug 6, 2009 at 12:59 PM, Evan Martin e...@chromium.org wrote:
On Thu, Aug 6, 2009 at 9:55 AM, n179911n179...@gmail.com wrote:
I read this about git usage in chromium:
http://code.google.com/p/chromium/wiki/UsingGit
After following the instructions in that document trunk/src is
This is kind of off topic, but should we consider adding a
copy/cut-as-plain-text keyboard shortcut (ctrl+shift+c/x). That would be
nicely symmetrical with ctrl+shift+v for paste-as-plain-text.
Ojan
On Fri, Jul 31, 2009 at 4:57 PM, Scott Violet s...@chromium.org wrote:
I just happen to be
You are, in fact, on crack. :) It was never a presubmit script. We just
talked about making it one a lot.
On Tue, Jul 28, 2009 at 3:52 PM, Mike Pinkerton pinker...@chromium.orgwrote:
I'm almost positive we made it so because we had so much trouble when
we were bringing up the mac and linux
There are heuristics we can come up with that are fairly safe. They might be
too conservative to be useful though. For example, it should almost always
be safe to kill a page that:-has no unload/beforeunload listeners registered
-has had no user-interaction that caused JS to execute
-has had no
On Wed, Jul 22, 2009 at 10:07 AM, Darin Fisher da...@chromium.org wrote:
On Wed, Jul 22, 2009 at 10:03 AM, Adam Langley a...@chromium.org wrote:
* By having the ChangeLog in the review, reviewers can critique it.
Many of our commit messages are little brief. Some are far too brief.
But,
On Wed, Jul 22, 2009 at 12:26 PM, Jeremy Orlow jor...@chromium.org wrote:
On Wed, Jul 22, 2009 at 11:57 AM, Ojan Vafai o...@chromium.org wrote:
This is an understatement. We really do a poor job with commit
descriptions. There is a lot to be gained by having better commit
descriptions. We
:
DETAILED_DESCRIPTION_HERE
BUG=http://bugs.chromium.org/BUG_NUMBER_HERE
TEST=required
RELEASE_NOTES=optional
On Wed, Jul 22, 2009 at 1:28 PM, Jeremy Orlow jor...@chromium.org wrote:
On Wed, Jul 22, 2009 at 1:22 PM, Peter Kasting pkast...@google.comwrote:
On Wed, Jul 22, 2009 at 1:17 PM, Ojan
for newcomers while optimizing for people who submit
a lot of CLs.
J
On Wed, Jul 22, 2009 at 1:43 PM, Ojan Vafai o...@chromium.org wrote:
I'm OK with not having the function list. I can see the advantages of the
webkit approach as it means that comments in the code don't get outdated
They'll eventually be moved into upstream webkit's repository, at which
point they'll be in third_party/WebKit.
On Thu, Jul 16, 2009 at 9:43 AM, Jeremy Orlow jor...@chromium.org wrote:
Maybe those should be moved out of the source tree (into deps) so that they
can be excluded?
On Thu, Jul
On Tue, Jul 14, 2009 at 2:18 PM, Nicolas Sylvain nsylv...@chromium.orgwrote:
Q3: What kind of auto-refresh do we need?
We used to be at 60 secs for a long time, and I changed it a couple of
weeks ago to 90 secs.
No one complained, so I guess this is good. Should we go even higher than
On Tue, Jul 14, 2009 at 2:35 PM, Nicolas Sylvain nsylv...@chromium.orgwrote:
On Tue, Jul 14, 2009 at 2:25 PM, Evan Martin e...@chromium.org wrote:
On Tue, Jul 14, 2009 at 2:18 PM, Nicolas Sylvainnsylv...@chromium.org
wrote:
It seems to me a caching layer that only ever hit the backend every
2009/7/9 Rafael Weinstein rafa...@chromium.org
However, because some of our existing pages use JSTemplate both for
injecting strings and for doing dynamic composition, the jst directives can
colide. Consider the following:
div jsselect=items
span jscontent=i18n_downloadDownload: /span
This is not a pass. Specifically Regressions: Unexpected failures lists
the failures. Other times, you'll see Regressions: Unexpected * where * is
crash, timeout, failures, etc. Also, it should have popped up a window with
the results just for the failing tests.
Ojan
2009/6/25 David Jones
For the layout tests steps, why do you we need to build test_shell locally,
rebaseline and then add the other platforms to tests_fixable? Can't we just
use the rebaseline tool and point it at the integration bots? Currently, you
can point the tool at a specific builder. Maybe we could add a
What Windows are you on? Vista cannot run some of the layout tests.
There is a flag you can pass to run_webkit_tests to get it to ignore the
system dependencies check. I don't remember the name off the top of my head.
To find it run: run_webkit_tests.sh --help
The flag will let you run the tests
This isn't the best, but it would be easy to add a flag to run-webkit-tests
that told it to always do the pixel comparison even if the checksums
matched.
Ojan
On Mon, Jun 22, 2009 at 10:55 AM, Evan Martin e...@chromium.org wrote:
Just so I'm not all negative, my suggestions after consulting
We discontinued it because we had a ton of files
forked and it was getting to be a lot of work to maintain.
PROS
-Can more easily identify v8 layout test failures
-Can ensure that all the USE(JSC) blocks are actually about the JS
engine instead of just Chromium/Safari-specific
code.
-Good for
in v8::internal::NativesCollection).
Thanks,
Stephen
On Thu, May 7, 2009 at 11:49 PM, Ojan Vafai o...@google.com wrote:
I've been getting the following build error for the past couple days on
Windows. It happens if I use Incredibuild or VS. It happens on a totally
fresh checkout. Any one
I just committed a change that removes defer from text_expectations.txt.
That means that the number of failing tests the bot reports is the total
number of webkit tests that we'll ever want to fix (e.g. win-release went
from 141 fixable to 768 fixable). In order to know which of those tests need
I've been getting the following build error for the past couple days on
Windows. It happens if I use Incredibuild or VS. It happens on a totally
fresh checkout. Any one have any ideas as to what could be causing this?
9-- Build started: Project: mksnapshot, Configuration: Debug Win32
--
This should still work fine. One person can lock the whole directory, then
people who need to commit unforkage can lock the specific files they need to
unfork using --force.
That said, the only forkage that happens these days is when doing a webkit
merge. What should the merger do if they find
, I'll send you the review for
test_expecations.txt.
Regards,
Glenn
On Fri, Apr 10, 2009 at 4:36 PM, Ojan Vafai o...@google.com wrote:
I hate to ask this, but any chance we could rewrite it in python? It
would be a lot less code in python (one script file) and would match the
rest of our
...@chromium.org wrote:
On Mon, Apr 6, 2009 at 6:57 PM, David Levin le...@google.com wrote:
On Mon, Apr 6, 2009 at 6:24 PM, Ojan Vafai o...@google.com wrote:
run_webkit_test.sh now runs cpus+1 test_shells for Release builds.
Please keep an eye out over the next couple days for test flakyness
On Thu, Apr 9, 2009 at 9:06 AM, Pam Greene p...@chromium.org wrote:
On that note, though, it would be amazing if someone wanted to figure out
the interdependencies. We have three run_webkit_tests otpions available to
help: --randomize-order, which runs the tests in a random
run_webkit_test.sh now runs cpus+1 test_shells for Release builds. Please
keep an eye out over the next couple days for test flakyness that may have
resulted from this.
Release tests on a dual core now take about half the time they used to.
There's still a lot of room for improvement and I'm a bit
On Mon, Apr 6, 2009 at 6:57 PM, David Levin le...@google.com wrote:
Release tests on a dual core now take about half the time they used to.
There's still a lot of room for improvement and I'm a bit burnt out on this
stuff, so if anyone is willing to help that would be much appreciated. Here
to take one number from that report and one number (searching on
priority/milestone) from the code tracker.
If the people who do that regularly (Jon?) are happy with that, then I have
no problem with it.
- Pam
On Thu, Mar 26, 2009 at 3:45 PM, Ojan Vafai o...@google.com wrote:
This matches my
25, 2009 at 4:00 PM, Ojan Vafai o...@google.com wrote:
Just want to make sure everyone sees this. Please voice yourself now if
you care about layout test fixing process and about managing test list
process.
I'll give another day. Unless I hear objections, I'll make
run_webkit_tests do option 3
tests_ignored.txt and tests_fixable.txt no longer exist. They were merged
into a single file: src/webkit/tools/layout_tests/test_expectations.txt. All
the files that were previously ignored now have the WONTFIX metadata applied
to them. WONTFIX means that we never intend to pass the test.
WONTFIX
PM, Ojan Vafai o...@google.com wrote:
OK. So, what I'm hearing is that every test should have a bug assigned to
it, no matter the priority. In that case, there's a couple other options.
*Option 3*
Get rid of DEFER and don't add priorities to the test list. Instead
require that every test
it.
:DG
On Mon, Mar 23, 2009 at 10:03 PM, Eric Seidel esei...@chromium.org
wrote:
Kill it (or I can, as part of the merge tomorrow)... so long as the merge
instructions are up to date.
On Mon, Mar 23, 2009 at 5:46 PM, Ojan Vafai o...@google.com wrote:
I think this file is basically
I'm going about adding support to the webkit test list for BUGx metadata
and replacing DEFER with P0/P1/P2/P3. I've come to the conclusion that we
need to better understand our desired workflow for dealing with failing
layout tests.
*TEST OWNERSHIP:*
Firstly, can we move away from using the
) from the issue
tracker... Maybe... ;-)
BYE
MAD
On Tue, Mar 24, 2009 at 2:57 PM, Ojan Vafai o...@google.com wrote:
I'm going about adding support to the webkit test list for BUGx
metadata and replacing DEFER with P0/P1/P2/P3. I've come to the
conclusion
that we need to better understand
I think this file is basically useless at this point. All the information in
it is encoding in src/DEPS (it now has a webkit_revision VAR). Any objection
to getting rid of this file? It's one fewer thing for the merger to keep
track of. I'll delete the file tomorrow if I hear no objections.
Ojan
I think this is fine, but we should stay on top of new svg regressions
from here forward.
Ojan
On Fri, Mar 13, 2009 at 11:48 AM, Marc-Antoine Ruel mar...@chromium.org wrote:
Stress reliever. But I won't have fixed any layout tests. :(
On Fri, Mar 13, 2009 at 2:28 PM, Scott Violet
/othertest.html = CRASH
NEVER_FIX : LayoutTests/http/othertest.html = FAIL
Ojan
On Fri, Mar 13, 2009 at 10:52 AM, Ojan Vafai o...@google.com wrote:
Being deputy this week, I've seen a ton of flaky tests on the mac. The vast
majority of these tests have been the http tests. A good chunk of them
timeout
On Mon, Mar 9, 2009 at 10:12 AM, Avi Drissman a...@google.com wrote:
On Mon, Mar 9, 2009 at 12:02 PM, Evan Martin e...@chromium.org wrote:
Maybe a better option is to have the renderer send FYI,
cut/copy/paste state is now x/y/z messages up to the UI whenever it
changes? (I guess paste is
I'm ok with saying that you do the merge one day and have another day to
cleanup layout test issues. Once we're not merging anymore though, I think
we should just have 1-2 people oncall for 1 week at a time to keep the
webkit(webkit.org) build green and to pull a new revision at least once a
day
, Ojan Vafai o...@chromium.org wrote:
In the spirit of trying to fix all the layout tests that represent
real regressions since our initial launch, I've just committed a
changelist that defers the tests that are failing that are new to
webkit since the revision of our launch or whose
-chromium-reviews, +chromium-dev
Not really sure. It seems to me that we need to send patches upstream to
make InspectorController not depend directly on JSC. It doesn't seem like it
should need to interact so directly with JSC. It's a non-trivial amount of
work. Is there another way we could
, right? ;-)
-Darin
On Thu, Feb 19, 2009 at 2:49 PM, Ojan Vafai o...@chromium.org wrote:
In the spirit of trying to fix all the layout tests that represent
real regressions since our initial launch, I've just committed a
changelist that defers the tests that are failing that are new
...@chromium.org wrote:
Perhaps this should exclude tests that we've ever passed, since those are
also regressions, albeit more recent ones.
- Pam
On Thu, Feb 19, 2009 at 2:49 PM, Ojan Vafai o...@chromium.org wrote:
In the spirit of trying to fix all the layout tests that represent
To match Safari compat, we need to pass all the layout tests that are not
inherently Safari specific. So essentially that means having 0 failing tests
and 0 deferred tests. The point of deferring is just so we can prioritize
some tests over others as we fix them. In an ideal world down the road,
So, it just needs a clobber then?
On Sun, Feb 8, 2009 at 9:11 PM, Mark Mentovai m...@chromium.org wrote:
(...posting again from the right e-mail address...)
Oh, I see in your r9380 of webkit/webkit.xcodeproj/project.pbxproj,
you removed EventTargetNode.cpp but you never removed
What if the styling is just to the size of the control? Currently there is
code (in WebKit proper) that falls back to OS ignorant drawing code if the
background-color and border are set. Something like that. I don't remember
the details. We could follow that.
On Fri, Jan 23, 2009 at 2:25 PM, Evan
Also, I think it makes sense to integrate this UI with bookmark manager. My
roommate recently had the same inability to find the manage search keywords
UI. I've pointed it out to him before, but it's hard enough to find that he
has to ask me every time. In his case, he was looking in the bookmark
, but if it keeps happening, we may
need to.
On Wed, Dec 10, 2008 at 2:17 PM, Ojan Vafai o...@chromium.org wrote:
Firstly, there is now a lint option that will parse the test list for
each
platform (win/mac/linux) and each build target (debug/release). This way
you
can know that you
On Tue, Dec 16, 2008 at 2:58 PM, Darin Fisher da...@chromium.org wrote:
On Tue, Dec 16, 2008 at 2:44 PM, Ojan Vafai o...@chromium.org wrote:
On Tue, Dec 16, 2008 at 1:52 PM, Darin Fisher da...@chromium.org wrote:
http://nightly.webkit.org/start has a link to the list of approved
1 - 100 of 114 matches
Mail list logo
