This new test: svg/stroke/non-scaling-stroke-pattern.svg fails after introduced in r119391 on Qt, GTK and EFL platforms. See http://build.webkit.sed.hu/results/x86-32%20Linux%20Qt%20Release%20-%20Qt5-WebKit1/r119392%20(8214)/svg/stroke/non-scaling-stroke-pattern-diffs.html https://bugs.webkit.org/show_bug.cgi?id=87925
I'm sorry for copying wrong links. Let me correct: This new test: svg/stroke/non-scaling-stroke-pattern.svg fails after introduced in r119391 on Qt, GTK and EFL platforms. See http://build.webkit.sed.hu/results/x86-32%20Linux%20Qt%20Release%20-%20Qt5-WebKit1/r119392%20(8214)/svg/stroke/non-scaling-stroke https://bugs.webkit.org/show_bug.cgi?id=88198
I'll have a patch up in a few minutes to fix this.
(In reply to comment #2) > I'll have a patch up in a few minutes to fix this. Thank you for the quick reply and for looking into it.
Created attachment 145588 [details] Update test expectations after 119392
Comment on attachment 145588 [details] Update test expectations after 119392 Wrong patch.
Created attachment 145590 [details] Update test expectations after 119392
Comment on attachment 145590 [details] Update test expectations after 119392 Clearing flags on attachment: 145590 Committed r119402: <http://trac.webkit.org/changeset/119402>
All reviewed patches have been landed. Closing bug.
I guess you want to keep this bug open, right?
(In reply to comment #9) > I guess you want to keep this bug open, right? Absolutely, thanks Philippe!
Created attachment 152860 [details] Update TestExpectations
Comment on attachment 152860 [details] Update TestExpectations Clearing flags on attachment: 152860 Committed r122903: <http://trac.webkit.org/changeset/122903>
It is still valid, but CQ closed it when landing expectations update.
(In reply to comment #14) > It is still valid, but CQ closed it when landing expectations update. Is it still valid? I thought one of the refactorings I've been doing in RenderSVGShape fixed it, as the test is now passing on Saf/mac, Cr/linux, Cr/win, and the QT/EFL/GTK bots look to be happy.
(In reply to comment #15) > (In reply to comment #14) > > It is still valid, but CQ closed it when landing expectations update. > > Is it still valid? I thought one of the refactorings I've been doing in RenderSVGShape fixed it, as the test is now passing on Saf/mac, Cr/linux, Cr/win, and the QT/EFL/GTK bots look to be happy. For some reason, the test started being flaky on the EFL bots since r129371 on the WK2 bot: <http://build.webkit.org/builders/EFL%20Linux%2064-bit%20Debug%20WK2/builds/3534/steps/layout-test/logs/stdio> and r129372 on the WK1 bot: <http://build.webkit.org/builders/EFL%20Linux%2064-bit%20Debug/builds/6296/steps/layout-test/logs/stdio>
(In reply to comment #16) > (In reply to comment #15) > > (In reply to comment #14) > > > It is still valid, but CQ closed it when landing expectations update. > > > > Is it still valid? I thought one of the refactorings I've been doing in RenderSVGShape fixed it, as the test is now passing on Saf/mac, Cr/linux, Cr/win, and the QT/EFL/GTK bots look to be happy. > > For some reason, the test started being flaky on the EFL bots since r129371 on the WK2 bot: <http://build.webkit.org/builders/EFL%20Linux%2064-bit%20Debug%20WK2/builds/3534/steps/layout-test/logs/stdio> and r129372 on the WK1 bot: <http://build.webkit.org/builders/EFL%20Linux%2064-bit%20Debug/builds/6296/steps/layout-test/logs/stdio> And then the flakiness mysteriously stopped in r129380 for the WK1 bot and 129377 for WK2...
(In reply to comment #17) > (In reply to comment #16) > > (In reply to comment #15) > > > (In reply to comment #14) > > > > It is still valid, but CQ closed it when landing expectations update. > > > > > > Is it still valid? I thought one of the refactorings I've been doing in RenderSVGShape fixed it, as the test is now passing on Saf/mac, Cr/linux, Cr/win, and the QT/EFL/GTK bots look to be happy. > > > > For some reason, the test started being flaky on the EFL bots since r129371 on the WK2 bot: <http://build.webkit.org/builders/EFL%20Linux%2064-bit%20Debug%20WK2/builds/3534/steps/layout-test/logs/stdio> and r129372 on the WK1 bot: <http://build.webkit.org/builders/EFL%20Linux%2064-bit%20Debug/builds/6296/steps/layout-test/logs/stdio> > > And then the flakiness mysteriously stopped in r129380 for the WK1 bot and 129377 for WK2... This may have been some other test leaving bad state around. I watch this code pretty closely and I don't think there have been any changes here. Mind if we close this again?
(In reply to comment #18) > This may have been some other test leaving bad state around. I watch this code pretty closely and I don't think there have been any changes here. > > Mind if we close this again? The test is _very_ flaky on all EFL and GTK bots. I think that's perfectly valid reason to keep a bug open and as this bug wasn't used to fix any particular issue so far it could as well be this one, right?
I can reproduce this with --iterations=3 (or larger). For some reason the third one and all subsequent iterations will always fail here. The failure is interesting: there are visual artifacts around the square (I assume this is the pattern area). These artifacts change depending on the number of iterations I tell test runner to do, but they are totally reproducible: e.g. the result for iteration 4 will always be the same.
(In reply to comment #20) > The failure is interesting: there are visual artifacts around the square (I assume this is the pattern area). These artifacts change depending on the number of iterations I tell test runner to do, but they are totally reproducible: e.g. the result for iteration 4 will always be the same. This works in minibrowser as well: refresh the window a few times and the problems start appearing.
The test(s) filed under this bug have been consistently passing for the last 4000 revisions. Marking bug as fixed. Committed r263254: <https://trac.webkit.org/changeset/263254>
<rdar://problem/64522650>