Re: [chromium-dev] changes to specifying test names (and test_expectations.txt) for Layout tests
I just updated
http://sites.google.com/a/chromium.org/dev/developers/testing/webkit-layout-tests
to
reflect these changes as well.
On Thu, Jan 14, 2010 at 10:40 AM, Ojan Vafai o...@google.com wrote:
I think the data for the dashboard is fine. There's just some dashboard
logic that needs updating. Will get on that ASAP.
On Wed, Jan 13, 2010 at 6:47 PM, Dirk Pranke dpra...@chromium.org wrote:
Hi all,
If you never run layout tests or modify test_expectations.txt, you can
stop reading.
As part of the process to upstream our layout test infrastructure, I
have just checked in a change that changes our test infrastructure to
conform to WebKit's in how we specify test names.
Specifically, instead of saying LayoutTests/fast/html/foo.html, you
now just say fast/html/foo.html. This affects specifying tests on
the command line to run_webkit_tests, and also specifying test names
in test_expectations.txt .
In the near future, we will also be moving all of the baselines from
src/webkit/data/layout_tests/platform/chromium-{mac,win,linux}/LayoutTests/*
to platform/chromium-{mac,win,linux}/*, again to match WebKit's
structure.
Two notes:
1) I believe the rebaselining tool is working correctly, but I'm not
100% sure. If you have any problems, let me know.
2) I may have just corrupted the data sets used by the flakiness
dashboard. I will be checking this with Ojan and (hopefully) fixing it
later this evening if I did.
Any questions or problems to me. Thanks!
-- Dirk
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] WebKit Gardeners 3 rebaseline.py -w
Yeah, me too. This is what tends to lead to me spending the day after my gardening rotation doing clean up. Maybe if we had 2 people gardening at the same time they could do this real time, but on a normal day, I think it is too much for one person. This tool is awesome though! Julie On Fri, Jan 8, 2010 at 4:54 PM, Jeremy Orlow jor...@chromium.org wrote: Same here. On Fri, Jan 8, 2010 at 4:51 PM, Drew Wilson atwil...@chromium.org wrote: Do you find that you have time to figure out if rebaselining a test is the right thing to do while you're actively gardening? Maybe I just work too slowly, but I often find that if I'm trying to rebaseline on the fly, it requires that I do at least *some* investigation of the test failure to make sure I'm not rebaselining in an error (or rebaselining a test that is merely flaky) which slows me down enough that I fall behind and inevitably am crushed by the WebKit juggernaut. -atw On Fri, Jan 8, 2010 at 4:33 PM, Dimitri Glazkov dglaz...@chromium.orgwrote: Before heading out for the weekend, I just want to mention this: rebaseline tool really, really rocks. And yesterday I discovered an option that I, to my shame, hadn't seen before: -w. This option pulls baselines from the canary. It's like getting test expectations from the future! In other words, there are no more excuses for you, dear WebKit gardeners, to commit those ghastly BUG_SOMENAME entries in test_expectations. The workflow is mind-numbingly simple: 1) Identify tests that need rebaselining prior to rolling 2) Add these tests to test_expectations.txt as if you were to commit them -- except add a REBASELINE flag next to BUG_SOMENAME 3) Run rebaseline -w 4) Make sure that the tool ran and removed these entries from test_expectations.txt 5) Create CL -- you will notice how new expected result files are conveniently added for you. 6) Enjoy regression-free WebKit roll. Big thanks to Victor Wang for this amazing instrument of everlasting harmony. Send him your accolades. Or cash. If you find bugs/quirks, fix them. :DG P.S. As part of gardener/sheriff process overhaul, I will be adding these and other helpful tips/hints to our gardening doc. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: [chromium-extensions] HTML5 spellcheck attribute
On Thu, Oct 15, 2009 at 10:04 AM, Aaron Boodman a...@chromium.org wrote: This is not really an extensions question. I think you want chromium-...@. - a On Thu, Oct 15, 2009 at 9:10 AM, Mixe twitter...@googlemail.com wrote: Chrome does not support HTML5 spellcheck attribute? Then why spellchecking is enabled by default? How we can disable (using JS) spellchecking into INPUT and TEXTAREA elements? I think there is a bug here, the spellcheck attribute should work. textarea spellcheck=false works, but myTextArea.spellcheck = false seems not to. Can you file a bug for this at crbug.com? For example, when a user put the path or another specific text into a text box, Chrome spellcheck always put red lines under the text :( A user may think that something is wrong. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [LTTF] Flaky tests and setTimeout
Another class of layout tests with bad setTimeouts in them -
Tests of the form:
body onload=runTest();
img
...
function runTest() {
// Wait for img to load
setTimeout(step2, 200);
}
These tests are not flaky, but the setTimeouts are completely
unnecessary (body onload always fires AFTER the img loads) and are just
leading to longer cycle times. If you encounter these, feel free to
eliminate the setTimeout and waitUntilDone calls.
Julie
On Tue, Oct 13, 2009 at 11:48 PM, Andrew Scherkus scher...@chromium.orgwrote:
On Tue, Oct 13, 2009 at 3:55 PM, Ojan Vafai o...@chromium.org wrote:
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 digging through the event
dispatching code to verify that the flakiness isn't limited to Chromium.
Even if it is just limited to Chromium, it is still a bug, right? Unless
I'm not understanding, there's no case under which we should be patching the
test in the above case. I don't know anything about video events, so I don't
really know what event order guarantees there should be.
Ojan
Yeah it's has to be a bug somewhere, just tricky to track down due to the
thread interaction between the video subsystem and the renderer thread.
Andrew
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: WebKit Layouts bot pulling code from the canary?
Would another solution be to have canary bots for both release and debug? On Thu, Oct 15, 2009 at 1:58 PM, Yaar Schnitman y...@chromium.org wrote: The layout try bots are just too slow for the purposes of webkit gardening, which needs to keep up with the fast stream of layout test breakage coming from webkit.org. Gclient and compilation consume most of the time, but the gardener is usually only interested in the layout tests themselves. How hard would it be to ask the bots to use chrome built by the canaries rather than waste time rebuilding it from scratch? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: layout test dashboard goofup
I actually have a copy of the data from Tuesday at 2:30pm. If you need any information out of the results page, just let me know. Julie On Thu, Oct 15, 2009 at 10:58 AM, Ojan Vafai o...@google.com wrote: I put some more thought into this. Given that we only store a month's worth of data, it's not worth doing backups. Keeping around all the data (maybe a year's worth?) would be awesome though. I actually think that would not be too much work and would add value to the dashboard. At that point, doing backups seems more worthwhile. I'm happy to walk someone through how to make this happen. It really would not be a lot of work if you have a workable knowledge of Python and JS. Ojan On Wed, Oct 14, 2009 at 5:15 PM, Nicolas Sylvain nsylv...@chromium.orgwrote: On Wed, Oct 14, 2009 at 4:53 PM, 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 the archive step of each run. We intentionally limit the number of results we keep in that file to 750 runs to keep filesize down. In my accidental checking, I changed 750 to 9. :( A little bit unrelated: This data, along with all the data on build.chromium.org, is replicated on at least 4 machines. It would be easy to recover the data if the server dies for example. We are also planning to do daily backups, but the data is huge. For example, we archive 25GB of new layout test results every day. Nicolas A trivial to implement backup would be to also copy the file to the archive location for just that run (same place as where we copy layout_test_results.zip), e.g. also copy it to http://build.chromium.org/buildbot/layout_test_results/webkit-rel/29056/. The downside is that this uses up disk space (e.g. the largest results.json file was 25mb before being clobbered). Another problem with backing up is that you'd also have to find a way to restore from backup that didn't lose data from runs that happened since the problem occurred. Merging the two files results.json should be pretty relatively trivial code, but it's all code that someone would need to write and test. While it sucks, I don't think backing up this data is worth the effort. It's a temporary productivity hit for the team, but we get enough new data to make reasonable decisions relatively quickly. Mistakes like this are very rare. It will become even more rare as coding work on the dashboard winds down. Feel free to have at it if you disagree. Creates the results.json file and it's content: trunk/src/webkit/tools/layout_tests/layout_package/json_results_generator.py Copies the results.json file to the right place: trunk/tools/buildbot/scripts/slave/chromium/archive_layout_test_results.py Ojan On Wed, Oct 14, 2009 at 4:24 PM, Jeremy Orlow jor...@chromium.orgwrote: I haven't actually gotten anything done on LocalStorage this week because I've been doing so many small side projects like this.but if it's a priority, sure. How about a cron job on some machine that ssh's via a cert into whatever machines the data is stored on, pulls it back, and dumps it into some dir? When we start filling up the hard drive, we can look at doing something smarter, deleting old data, or putting it somewhere like GFS. What server can I use and where's the data stored? On Wed, Oct 14, 2009 at 4:17 PM, Evan Martin e...@chromium.org wrote: Sounds like we've got 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...@google.com wrote: 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. Do you moonlight for the Danger team at Microsoft? PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
Re: Layout test flakiness WAS: [chromium-dev] Re: [LTTF][WebKit Gardening]: Keeping up with the weeds.
We did this on my last project to deal with flaky test infrastructure. It worked well in that test failures were pretty much guaranteed to be real (we ran tests 3 times and only reported failure if a test failed all 3 times), but it did definitely make us stop caring about flaky tests. Idealizing this some more, what if it could auto-add flaky tests to test_expectations, or at least generate a daily report that someone could then manually add? This would make us keep track of the flakiness and would only have the slowdown in test run times until a flaky test is added to test_expectations. On Tue, Oct 13, 2009 at 12:02 PM, Ojan Vafai o...@chromium.org wrote: 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 much greener -Try bots will be much more reliable -Increase in overall team sanity Cons: -Almost guaranteed to sweep some new flakiness under the rug -If enough flakiness accumulates it will affect cycle time (each timeout/crash test we rerun takes seconds) Shouldn't be too hard to implement. Ojan On Tue, Oct 13, 2009 at 11:32 AM, Peter Kasting pkast...@google.comwrote: On Tue, Oct 13, 2009 at 11:17 AM, Nicolas Sylvain nsylv...@chromium.orgwrote: It's because the sheriff don't notice the new failing tests, because most of the time the gardener does a good job of updating the list at the same time as the merge, so the tree stays mostly green. See http://src.chromium.org/viewvc/chrome?view=revrevision=28727 In my case I was watching jparent's commits, so I stand by my assertion. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [LTTF][WebKit Gardening]: Keeping up with the weeds.
I like the idea of ownership of groups of layout tests. Maybe these directory owners could be more like the finders? An owner shouldn't have to necessarily fix everything in a group/directory, but they should be responsible for triaging and getting meaningful bugs filled for them, to keep things moving along. (I volunteer for editing/) Another complicating factor - The state of the main Chrome tree has a lot of effect on the gardener. If the tree is already filled with flakiness, then the webkit roll is likely to show failures, which may or may not have been there before the roll. This was largely the case in the situation pkasting was referring to, when he took over as sheriff, he inherited a tree with a lot of flakiness not reflected in test_expectations/disabled ui tests. I think very few (if any) of the tests he added to test_expectations had anything to do with the roll. Any policy we make needs to keep in mind that main tree sheriffs deal with flakiness differently; some cross their fingers and hope it goes away, and some do clean up. Maybe we need to get better at enforcing (or automating) adding flaky tests to expectations, so we at least have a clean slate for gardeners to start with. On Tue, Oct 13, 2009 at 11:53 AM, Stephen White senorbla...@chromium.orgwrote: I agree with Dimitri that we're fighting a losing battle here. In my last stint as gardener, I did informally what I proposed formally last time: I spent basically 1 full day just triaging failures from my 2 days gardening. Not fixing, but just running tests locally, analyzing, grouping, creating bugs, assigning to appropriate people (when I knew who they were, cc'ing poor dglazkov when I didn't). So at least I didn't leave a monster bug with layout tests broken by merge #foo but at least grouped by area. That was manageable, but I don't know if another day would actually be enough for a meaningful amount of fixing. I also agree with Drew that actively fixing all the broken tests is usually beyond the skills of any one gardener. Perhaps we should start taking ownership of particular groups of layout tests? And maybe automatically assign them (or least cc them), the same way Area-Foo causes automatic cc'ing in bugs.chromium.org (I think?) That way, the gardener wouldn't have to know who to assign to. I've basically taken responsibility for fixing all layout tests broken by Skia rolls, which can pretty heavy on its own, but I'm willing to take ownership of a directory or two. BTW, the layout test flakiness dashboard has become an invaluable tool for analyzing failures: searching for a test by name is lightning-fast, and you can clearly see if a test has become flaky, on which platforms, and which WebKit merge was responsible, which can also help with grouping. (Props to Ojan for that). Also, it may be Gilbert-and-Sullivan-esque of me, but I think everyone who contributes patches to WebKit for chromium should be on the WebKit gardener rotation. Stephen On Tue, Oct 13, 2009 at 1:53 PM, Drew Wilson atwil...@chromium.orgwrote: I've been thinking quite a bit about this - I agree with Dmitri that the current Sisyphean approach is unsustainable. I don't think the right path is to ask the sheriffs to do the cleanup themselves - for example, a webkit roll that breaks workers in some obscure way is almost certainly beyond the ability of any random gardener to fix in two days, especially when there may be multiple bugs. A better solution would be to have the sheriff (or someone from LTTF) assign the bugs to specific people, with a general rule that such bugs must be fixed within two days (make these bugs the top priority over other tasks). This allows for load balancing of bugs, and also makes sure that we have the right people working on any specific bug. -atw On Tue, Oct 13, 2009 at 10:40 AM, Pam Greene p...@chromium.org wrote: I don't think it's realistic to expect the gardener, or any one person, to be able to fix an arbitrary broken layout test in a reasonable period of time. That's certainly true for new tests, but even for regressions I often can't even tell for sure whether our results are correct, much less what to do if they're not. It's far more efficient to have the right person fix a test. (Of course, people should also strive to broaden their knowledge, but there's a limit to how much of that one can do in a week.) Never having broken layout tests is an excellent goal, but quite frankly I don't think it's one we should prioritize so high that we hobble other efforts and burn out developers. - Pam On Tue, Oct 13, 2009 at 10:31 AM, Dimitri Glazkov dglaz...@chromium.org wrote: I think we need to change something. I am not sure what -- I have ideas, but -- I would appreciate some collective thinking on this. PROBLEM: We accumulate more test failures via WebKit rolls than we fix with our LTTF effort. This ain't right. ANALYSIS: Ok, WebKit
[chromium-dev] Re: seeking webkit reviewer for chrome-specific patches
Be sheriff that day :) Real advice: Once you have webkit patch R+'ed and chrome rebaselines ready, let the gardener know. Once the gardener is caught up, they can set commit-queue flag on your change, so it gets committed at a time when they are ready to deal with it and your follow up change will be there ready to fix everything. On Tue, Oct 13, 2009 at 4:06 PM, Evan Martin e...@chromium.org wrote: Both of these patches don't really have an obvious reviewer, but they're pretty simple. https://bugs.webkit.org/show_bug.cgi?id=30319 https://bugs.webkit.org/show_bug.cgi?id=30320 The latter one will require an epic amount of rebaselining, which I have volunteered to do. If anyone has advice on how to do that in a way that makes the webkit sheriffs happy, let me know. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] [LTTF] Flaky tests and setTimeout
For those of you looking into flaky tests - I've found a surprising number of tests that are flaky because they use a setTimeout to guarantee that a resource (usually an iframe) has loaded. This leads to slower running, flaky tests. To address this, change the tests upstream to use onload instead and make the world a better place :) I'm converting all of the editing tests now. Julie --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Rubber stamping layout test rebaselines considered harmful
Problem: People rubber stamp or TBR rebaselines instead of doing normal reviews, because they are hard to review, due to lack of detailed knowledge about why they are being rebaselined. This is causing bad baselines to be checked in, which leads to layout test failures, which leads to sadness. Proposed Solution: Changelist comments for rebaselines should include enough information that the reviewer should be able to do a reasonable sanity check (aka, explain a little about WHY this is the right thing to be doing in the first place), and reviewers should do a quick sanity check. Spending a couple seconds glancing at diffs now will save time in the future. Real examples I ran into in the past 2 days: - Failing tests because the baseline checked in is for an error page, and we generate real results. Glancing at the diff should have caught this: http://codereview.chromium.org/113170/diff/1/1080 - A slew of totally unrelated tests had one single image checked in as their baseline. Again, glancing at the diff should have caught this: http://codereview.chromium.org/99147/diff/1/12 Julie --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Layout try slaves
Are these running release or dbg? On Mon, Aug 31, 2009 at 1:12 PM, Marc-Antoine Ruel mar...@chromium.orgwrote: On Mon, Aug 31, 2009 at 12:39 PM, Brett Wilsonbre...@chromium.org wrote: On Mon, Aug 31, 2009 at 10:13 AM, Marc-Antoine Ruelmar...@chromium.org wrote: If you are not a committer, you can skip this message. If you want to run layout tests as a try job, you can use the layout try slaves. They are not in the default pool so you need to reference them manually. The format is: gcl try foo --bot layout_win,layout_mac,layout_linux This is great. Is this documented anywhere? Seems like http://dev.chromium.org/developers/how-tos/webkit-merge-1 would be a very useful place to have it. I'm not a webkit gardener so I don't think I'm the best person to modify this page with useful information. M-A --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: 3.0.195.1 Released to Dev Channel
What is the best way to figure out which WebKit revision this corresponds to? Some of the older release notes were including that information in the notes, but I don't see it in the last few releases. On Wed, Jul 22, 2009 at 5:28 PM, Jon j...@chromium.org wrote: See http://googlechromereleases.blogspot.com/ for more information. Jon --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: running layout_tests on vista and windows 7
On Mon, Jul 13, 2009 at 1:16 PM, Dirk Pranke dpra...@google.com wrote: Yup, I've already adopted that. Thanks! On Mon, Jul 13, 2009 at 12:55 PM, Thomas Van Lententhoma...@chromium.org wrote: Quick skimmed reply: Mac already has expectations per OS where we need them, so you might be able to follow that basic model (and maybe small tweaks to the scripts to use it). It looks for version specific and then falls back to generic platform files so we only have to dup the ones that are os version specific. TVL On Mon, Jul 13, 2009 at 3:50 PM, Dirk Pranke dpra...@google.com wrote: Hi all, (If you don't ever care to run the webkit layout tests, you can skip this note). As most of you are no doubt aware, we currently can only run the webkit layout_tests on windows XP. For some of us who primarily develop on 64-bit Vista, this is inconvenient at best, and this is only going to get worse over time as more of migrate to 64-bit machines and (eventually) Windows 7. So, I'm working on porting the layout tests to Vista. This note is a writeup of the approach I'm thinking of taking, and I'm looking for feedback and suggestions, especially since most of you have been on this code base a lot longer than me. My basic approach is to try and get something up as quickly as possible as a proof of concept, and then work to try and reduce the maintenance over time. So, I've started by cloning the chromium-win port over to vista, and modifying the test scripts to be aware of the new set of test expectations. I will then tweak the tests to get roughly the same list of tests passing on Vista as on Windows. The main differences will have to do with how the theming renders scroll bars and a few other native controls. I have most of this now, and should have the rest of this in a day or two, but this is not a maintainable solution without a lot of manual overhead. Next, we'll get a buildbot setup to run on Vista. While we're doing this, I'll start working on reducing the test set duplication between XP and Vista. The best way to do this (we currently think) will be to modify test_shell to *not* draw the native controls, but rather stub them out in a platform-independent way for test purposes (e.g., just painting a grey box instead of a real scroll bar). Then we can write a few platform-specific unit tests to ensure that the widgets do work correctly, but the bulk of the tests will become (more) platform-independent. My hope is that we'll have something that I can demonstrate here in a week or two, and that it will extend trivially to Win 7. A stretch hope is that we can even get the rendering to be platform-independent enough that we may even be able to leverage them across the linux and mac ports. I don't know if this is realistic or not, as many of the tests may differ just due to font rendering and other minor differences. An alternative strategy is to start looking at more and more of the tests and making sure they are written to be as platform-independent as possible. First we'd this by making sure that we don't rely on pixel-based tests where text-based tests would do. We started doing this for all of the editing tests, but got pushback from WebKit, because they were concerned that we may inadvertantly lose some of the subtle things that a pixel test can test that a text based test can't. I still think it is a good idea (less platform specific results to check out, tests run faster, etc), but just an FYI that you might hit some pushback in this area, so be sure to run it by webkit-dev before doing too much work. Another option would be to switch to writing two tests just to ensure that page A renders the same way as page B (where A and B use two different sets of layout but should produce the same output). Both of these options are significantly more work up front, but will payoff in much less maintenance down the line. Also, all of this work will also overlap with the webkit test suites, so it'll need to be coordinated with our upstream buddies. Comments? Thoughts? -- Dirk --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Text editing freezing jank?
If anyone sees this somewhere other than Gmail replies, please comment on the bug. On Thu, Jun 11, 2009 at 1:00 PM, Nick Baum nickb...@chromium.org wrote: Doh, thanks! -Nick On Thu, Jun 11, 2009 at 12:18 PM, Peter Kasting pkast...@google.comwrote: On Thu, Jun 11, 2009 at 12:17 PM, Nick Baum nickb...@chromium.orgwrote: Has anyone else run into this behavior in Chrome, in Gmail or elsewhere? Any suggestions for next steps to track this down? I suggest searching the bug database. You will find this: http://crbug.com/12785 PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
