Bug 88230 - [GTK] new test svg/stroke/non-scaling-stroke-pattern.svg fails
Summary: [GTK] new test svg/stroke/non-scaling-stroke-pattern.svg fails
Status: REOPENED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Philip Rogers
URL:
Keywords:
Depends on:
Blocks: 87008 104528
  Show dependency treegraph
 
Reported: 2012-06-04 07:14 PDT by János Badics
Modified: 2017-03-11 11:00 PST (History)
12 users (show)

See Also:


Attachments
Update test expectations after 119392 (45.62 KB, patch)
2012-06-04 08:12 PDT, Philip Rogers
pdr: commit-queue-
Details | Formatted Diff | Diff
Update test expectations after 119392 (2.52 KB, patch)
2012-06-04 08:14 PDT, Philip Rogers
no flags Details | Formatted Diff | Diff
Update TestExpectations (3.89 KB, patch)
2012-07-17 16:07 PDT, Philip Rogers
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description János Badics 2012-06-04 07:14:27 PDT
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
Comment 1 János Badics 2012-06-04 07:23:14 PDT
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
Comment 2 Philip Rogers 2012-06-04 07:29:08 PDT
I'll have a patch up in a few minutes to fix this.
Comment 3 János Badics 2012-06-04 07:32:35 PDT
(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.
Comment 4 Philip Rogers 2012-06-04 08:12:56 PDT
Created attachment 145588 [details]
Update test expectations after 119392
Comment 5 Philip Rogers 2012-06-04 08:13:50 PDT
Comment on attachment 145588 [details]
Update test expectations after 119392

Wrong patch.
Comment 6 Philip Rogers 2012-06-04 08:14:27 PDT
Created attachment 145590 [details]
Update test expectations after 119392
Comment 7 WebKit Review Bot 2012-06-04 08:51:13 PDT
Comment on attachment 145590 [details]
Update test expectations after 119392

Clearing flags on attachment: 145590

Committed r119402: <http://trac.webkit.org/changeset/119402>
Comment 8 WebKit Review Bot 2012-06-04 08:51:19 PDT
All reviewed patches have been landed.  Closing bug.
Comment 9 Philippe Normand 2012-06-04 22:17:33 PDT
I guess you want to keep this bug open, right?
Comment 10 Philip Rogers 2012-06-05 12:34:10 PDT
(In reply to comment #9)
> I guess you want to keep this bug open, right?

Absolutely, thanks Philippe!
Comment 11 Philip Rogers 2012-07-17 16:07:10 PDT
Created attachment 152860 [details]
Update TestExpectations
Comment 12 WebKit Review Bot 2012-07-17 17:30:51 PDT
Comment on attachment 152860 [details]
Update TestExpectations

Clearing flags on attachment: 152860

Committed r122903: <http://trac.webkit.org/changeset/122903>
Comment 13 WebKit Review Bot 2012-07-17 17:30:57 PDT
All reviewed patches have been landed.  Closing bug.
Comment 14 Csaba Osztrogonác 2012-07-18 01:10:24 PDT
It is still valid, but CQ closed it when landing expectations update.
Comment 15 Philip Rogers 2012-07-18 09:17:19 PDT
(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.
Comment 16 Raphael Kubo da Costa (:rakuco) 2012-09-24 10:04:33 PDT
(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>
Comment 17 Raphael Kubo da Costa (:rakuco) 2012-09-24 10:17:08 PDT
(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...
Comment 18 Philip Rogers 2012-12-10 10:00:29 PST
(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?
Comment 19 Jussi Kukkonen (jku) 2012-12-31 05:34:09 PST
(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?
Comment 20 Jussi Kukkonen (jku) 2012-12-31 05:52:07 PST
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.
Comment 21 Jussi Kukkonen (jku) 2012-12-31 06:18:01 PST
(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.