Summary: | [chromium] Hundreds of mac failures are due to a slightly different color repaint background | ||
---|---|---|---|
Product: | WebKit | Reporter: | Ojan Vafai <ojan> |
Component: | Tools / Tests | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED WONTFIX | ||
Severity: | Normal | CC: | caryclark, danakj, epoger, reed, senorblanco |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | Mac | ||
OS: | Unspecified |
Description
Ojan Vafai
2012-04-06 15:09:11 PDT
Probably this https://codereview.appspot.com/5758043 Here's the skia bug http://code.google.com/p/skia/issues/detail?id=420 Ojan, can you please tell me how to get a list of the "hundreds" of tests that fall into this category? (Or at least a good chunk of them?) Taking the example given, empty-section-crash, I see (via svn blame) that it was marked as expected to IMAGE fail at least 16 months ago (http://trac.webkit.org/changeset/74070/trunk/LayoutTests/platform/chromium/test_expectations.txt). Its expectations line refers to http://crbug.com/23489 , which was filed in Sept 2009... (In reply to comment #3) > Ojan, can you please tell me how to get a list of the "hundreds" of tests that fall into this category? (Or at least a good chunk of them?) 1. load "webkit-patch garden-o-matic" 2. go to the expected failures tab 3. examine the fast/repaint tests Fixing the color issue probably won't make all these tests pass, but it will make it so that the pixel diffs are just text-rendering/antialiasing. So, they would be straightforward rebaselines. I think a large percentage of these have also be rebaselined. I know I rebaselined a lot of these for the Lion port before I realized that it was a more widespread problem. So, fixing this would cause a number of tests to "fail" that would need rebaselining. Marked LayoutTest bugs, bugs with Chromium IDs, and some others as WontFix. Test failure bugs still are trackable via TestExpectations or disabled unit tests. |