WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
Bug 88230
[GTK] new test svg/stroke/non-scaling-stroke-pattern.svg fails
https://bugs.webkit.org/show_bug.cgi?id=88230
Summary
[GTK] new test svg/stroke/non-scaling-stroke-pattern.svg fails
János Badics
Reported
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
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
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
János Badics
Comment 1
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
Philip Rogers
Comment 2
2012-06-04 07:29:08 PDT
I'll have a patch up in a few minutes to fix this.
János Badics
Comment 3
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.
Philip Rogers
Comment 4
2012-06-04 08:12:56 PDT
Created
attachment 145588
[details]
Update test expectations after 119392
Philip Rogers
Comment 5
2012-06-04 08:13:50 PDT
Comment on
attachment 145588
[details]
Update test expectations after 119392 Wrong patch.
Philip Rogers
Comment 6
2012-06-04 08:14:27 PDT
Created
attachment 145590
[details]
Update test expectations after 119392
WebKit Review Bot
Comment 7
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
>
WebKit Review Bot
Comment 8
2012-06-04 08:51:19 PDT
All reviewed patches have been landed. Closing bug.
Philippe Normand
Comment 9
2012-06-04 22:17:33 PDT
I guess you want to keep this bug open, right?
Philip Rogers
Comment 10
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!
Philip Rogers
Comment 11
2012-07-17 16:07:10 PDT
Created
attachment 152860
[details]
Update TestExpectations
WebKit Review Bot
Comment 12
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
>
WebKit Review Bot
Comment 13
2012-07-17 17:30:57 PDT
All reviewed patches have been landed. Closing bug.
Csaba Osztrogonác
Comment 14
2012-07-18 01:10:24 PDT
It is still valid, but CQ closed it when landing expectations update.
Philip Rogers
Comment 15
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.
Raphael Kubo da Costa (:rakuco)
Comment 16
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
>
Raphael Kubo da Costa (:rakuco)
Comment 17
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...
Philip Rogers
Comment 18
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?
Jussi Kukkonen (jku)
Comment 19
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?
Jussi Kukkonen (jku)
Comment 20
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.
Jussi Kukkonen (jku)
Comment 21
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.
Diego Pino
Comment 22
2020-06-19 00:38:14 PDT
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
>
Radar WebKit Bug Importer
Comment 23
2020-06-19 00:39:19 PDT
<
rdar://problem/64522650
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug