Bug 132421

Summary:

fast/multicol/fixed-stack.html failing since introduction.

Product:

WebKit

Reporter:

Andreas Kling <kling>

Component:

Layout and Rendering

Assignee:

Dave Hyatt <hyatt>

Status:

NEW

Severity:

Normal

CC:

ap, bfulgham, clopez, darin, kling, simon.fraser, thorton

Priority:

Version:

528+ (Nightly build)

Hardware:

Unspecified

OS:

Unspecified

See Also:

https://bugs.webkit.org/show_bug.cgi?id=159214

Attachments:

Description	Flags
Patch	darin: review+

Andreas Kling

Reported 2014-05-01 00:15:05 PDT

This test was added in r168076 and is failing on bots since. It appears to be a problem with compositing vs non-compositing code paths. There is a small antialiasing difference in the output, and it goes away if I force the -expected.html to use accelerate compositing as well.

Attachments
Patch (2.98 KB, patch) 2021-12-21 20:51 PST, Simon Fraser (smfr)	darin: review+	Details Formatted Diff Diff
View All Add attachment proposed patch, testcase, etc.

Andreas Kling

Comment 1 2014-05-01 00:18:44 PDT

Skipped: <http://trac.webkit.org/changeset/168090>

Tim Horton

Comment 2 2014-05-01 06:54:31 PDT

Seems like this should have gotten ImageOnlyFailure'd, not Skipped! That way we'll still learn if the text parts differ and just ignore the bad image parts.

Dave Hyatt

Comment 3 2014-05-01 09:41:47 PDT

Hmmm not sure how to fix. The whole point was to compare compositing vs. non-compositing, so if the images aren't going to match I'm not sure how to test this issue.

Dave Hyatt

Comment 4 2014-05-01 09:42:06 PDT

I guess I should turn it into a pixel test.

Alexey Proskuryakov

Comment 5 2014-05-01 09:43:23 PDT

Updated the expectation in <http://trac.webkit.org/r168106>.

Tim Horton

Comment 6 2014-05-01 09:49:55 PDT

(In reply to comment #3) > Hmmm not sure how to fix. The whole point was to compare compositing vs. non-compositing, so if the images aren't going to match I'm not sure how to test this issue. It would be nice to have a link to the failure here so we can see what kind of AA differences are occuring. Ideally there should be no differences between the two modes, and you shouldn't have to worry about this when writing a test. Andreas, did it fail on WebKit2 bots as well? (i.e. was the issue with the whole webview being in compositing/not, which only switches on WebKit1 bots, or with the content specifically being in compositing/not, which switches on both).

Alexey Proskuryakov

Comment 7 2014-05-01 10:10:02 PDT

http://build.webkit.org/results/Apple%20MountainLion%20Release%20WK2%20(Tests)/r168079%20(18114)/fast/multicol/fixed-stack-diffs.html http://build.webkit.org/results/Apple%20Mavericks%20Release%20WK2%20(Tests)/r168087%20(5354)/fast/multicol/fixed-stack-diffs.html It was WK2 only, for added surprise :). Failing consistently on all Mac WK2 bots.

Carlos Alberto Lopez Perez

Comment 8 2014-08-19 04:36:59 PDT

This test pass on GTK (WK2)

Alexey Proskuryakov

Comment 9 2014-10-24 12:12:05 PDT

As of Yosemite, the test now fails on WK1 too, because it actually started to use compositing. Updated expectations in <http://trac.webkit.org/r175170>.

Brent Fulgham

Comment 10 2015-01-21 14:20:04 PST

(In reply to comment #9) > As of Yosemite, the test now fails on WK1 too, because it actually started > to use compositing. > > Updated expectations in <http://trac.webkit.org/r175170>. After this test expectation change, Windows now passes as well.

Simon Fraser (smfr)

Comment 11 2021-12-21 20:51:31 PST

Created attachment 447777 [details] Patch

Note You need to log in before you can comment on or make changes to this bug.