After http://trac.webkit.org/changeset/54865 was checked in, 3 svg tests started failing for Chromium, due to pixel result mismatches (chromium runs pixel tests, webkit.org does not). I've checked these all on a webkit checkout, and the tests also fail for webkit and have results that match Chromium. Do these simply need rebaselining, or was the old behavior correct and this is a regression? I am not familiar enough with svg to know the answer here. The tests: fast/borders/svg-as-border-image-2.html fast/borders/svg-as-border-image.html fast/images/svg-as-tiled-background.html You can see more details of the mismatch on the Chromium layout test dashboard. This has a lot of data, but the part of interest is where you see the "ACTUAL RESULTS" for the png files. http://src.chromium.org/viewvc/chrome/trunk/src/webkit/tools/layout_tests/flakiness_dashboard.html#tests=fast%2Fimages%2Fsvg-as-tiled-background.html%2Cfast%2Fborders%2Fsvg-as-border-image.html%2Cfast%2Fborders%2Fsvg-as-border-image-2.html&showExpectations=true
Sorry about that, I will take a look.
fast/images/svg-as-tiled-background.html tests exactly the same bug that I just fixed, so it should get updated results. (I guess my new test was redundant) fast/borders/svg-as-border-image-2.html fast/borders/svg-as-border-image.html At first, I thought that these 2 tests exposed a bug, but then I compared the results of these 2 tests with the result of fast/borders/border-image-01.html. The SVG border image now behaves the same as non-SVG border image, so I think we just need an updated test result.
Going to update the svg-as-tiled-background.html expected png soon, marking this bug as duplicate of 37028, where Simon provides new svg-as-border* tests, which are much better. *** This bug has been marked as a duplicate of bug 37028 ***