Bug 132421 - fast/multicol/fixed-stack.html failing since introduction.
Summary: fast/multicol/fixed-stack.html failing since introduction.
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Dave Hyatt
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-01 00:15 PDT by Andreas Kling
Modified: 2016-06-28 20:01 PDT (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Kling 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.
Comment 1 Andreas Kling 2014-05-01 00:18:44 PDT
Skipped: <http://trac.webkit.org/changeset/168090>
Comment 2 Tim Horton 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.
Comment 3 Dave Hyatt 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.
Comment 4 Dave Hyatt 2014-05-01 09:42:06 PDT
I guess I should turn it into a pixel test.
Comment 5 Alexey Proskuryakov 2014-05-01 09:43:23 PDT
Updated the expectation in <http://trac.webkit.org/r168106>.
Comment 6 Tim Horton 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).
Comment 8 Carlos Alberto Lopez Perez 2014-08-19 04:36:59 PDT
This test pass on GTK (WK2)
Comment 9 Alexey Proskuryakov 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>.
Comment 10 Brent Fulgham 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.