Bug 34632 - pixel diff errors in editing layout tests
Summary: pixel diff errors in editing layout tests
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC OS X 10.5
: P2 Normal
Assignee: Tony Chang
URL: http://ponderer.org/tests/layout-test...
Depends on:
Reported: 2010-02-04 23:37 PST by Tony Chang
Modified: 2010-02-07 16:47 PST (History)
2 users (show)

See Also:

Patch (47.67 KB, patch)
2010-02-04 23:40 PST, Tony Chang
darin: review+
commit-queue: commit-queue-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tony Chang 2010-02-04 23:37:08 PST
I ran the layout tests with --pixel and --tolerance 0 just to verify that the baselines were in fact correct.  These are my findings:

I will upload new baselines for these two:
editing/deleting/5390681-2.html - cursor isn't in expected image although it should be
editing/pasteboard/5387578.html - collapse whitespace change in r42549 without new baselines

For these tests, the expected images have slightly darker fonts than when I run them locally.  Seems safe to ignore, but might be good to rebaseline.

editing/inserting/4960120-1.html - Focus ring in the expected image is a bit darker (more blue).  Seems safe to ignore, but might be good to rebaseline.

editing/deleting/delete-to-select-table.html - one pixel off in the border, seems fine.
editing/selection/select-all-002.html - one pixel off in the border, seems fine.

editing/selection/4960116.html - the caret shows through even though the div that contains it is invisible.  Maybe DRT is designed to always show the cursor?  I don't see a caret in Safari.  Seems safe to ignore, but maybe this is a bug in DRT.

These tests appear to have regressed:
editing/selection/caret-rtl-2.html - The test description says that the caret should be near where the user clicks, but it's not.  Both the expected and the actual look wrong.  Looking through the repo, I can't tell when this regressed.
editing/selection/extend-by-word-002.html - The selection on my mac looks like two selections are overlapping (some of the selection is darker than other parts of the selection).  I think this test has also regressed.

Let me know if I should file separate bugs for any of these.
Comment 1 Tony Chang 2010-02-04 23:40:49 PST
Created attachment 48204 [details]
Comment 2 Tony Chang 2010-02-04 23:42:21 PST
Comment on attachment 48204 [details]

Hmm, I though the images would show in the formatted diff.  I will upload the images to a different server.
Comment 3 Tony Chang 2010-02-04 23:55:40 PST
Result images and diffs are here:
Comment 4 WebKit Commit Bot 2010-02-05 07:17:47 PST
Comment on attachment 48204 [details]

Rejecting patch 48204 from commit-queue.

Failed to run "['/Users/eseidel/Projects/CommitQueue/WebKitTools/Scripts/svn-apply', '--reviewer', 'Darin Adler', '--force']" exit_code: 255
patching file LayoutTests/ChangeLog
Hunk #1 succeeded at 1 with fuzz 3.
patching file LayoutTests/platform/mac/editing/deleting/5390681-2-expected.checksum
only literal type is supported now at /Users/eseidel/Projects/CommitQueue/WebKitTools/Scripts/svn-apply line 283, <> line 751.

Full output: http://webkit-commit-queue.appspot.com/results/238103
Comment 5 Eric Seidel (no email) 2010-02-05 12:03:17 PST
Attachment 48204 [details] was posted by a committer and has review+, assigning to Tony Chang for commit.
Comment 6 Tony Chang 2010-02-07 16:42:13 PST
Committed r54475: <http://trac.webkit.org/changeset/54475>
Comment 7 Tony Chang 2010-02-07 16:47:36 PST
I filed bug 34692 and bug 34693 for the 2 tests that seem to have regressed.