Bug 78021

Summary: layoutTestController.display() is flaky for SVG tests
Product: WebKit Reporter: Nikolas Zimmermann <zimmermann>
Component: Tools / TestsAssignee: Nikolas Zimmermann <zimmermann>
Status: RESOLVED FIXED    
Severity: Normal CC: aroben
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on: 77736    
Bug Blocks:    
Attachments:
Description Flags
Patch for mac
none
Patch for win none

Description Nikolas Zimmermann 2012-02-07 12:56:11 PST
layoutTestController.display() is flaky for SVG tests. Reduction:
new-run-webkit-tests --tolerance 0 -p --child-processes=1 svg/W3C-SVG-1.1(-SE)/any-test.svg svg/filters/animate-fill.svg
There's a hack in DRT to produce 480x360 expected.pngs for any test starting with "svg/W3C-SVG-1.1" - the resizing of the web view is done when dump()ing the render tree - _after_ layoutTestController.display() was called and the repaint test executed. This makes the grey overlay vanish again.
The first test that tests repainting, running right after a svg/W3C-SVG-1.1/xxxx test case will fill. Uploading a simple fix for Mac DRT soon.
Comment 1 Nikolas Zimmermann 2012-02-07 13:02:28 PST
Created attachment 125906 [details]
Patch for mac
Comment 2 mitz 2012-02-07 13:05:59 PST
Comment on attachment 125906 [details]
Patch for mac

View in context: https://bugs.webkit.org/attachment.cgi?id=125906&action=review

> Tools/ChangeLog:11
> +        hack that forces 480x3600 instead of 800x600 pixel test dumps for any test starting with

Typo: 3600
Comment 3 Nikolas Zimmermann 2012-02-07 13:38:13 PST
Committed r106983: <http://trac.webkit.org/changeset/106983>
Comment 4 Adam Roben (:aroben) 2012-02-07 14:13:27 PST
I believe DRT/win has extremely similar code. Any chance you'll fix that implementation too?
Comment 5 Nikolas Zimmermann 2012-02-09 02:39:44 PST
(In reply to comment #4)
> I believe DRT/win has extremely similar code. Any chance you'll fix that implementation too?
Reopning this bug as reminder. I've checked DRT code for all platforms (efl/gtk/cr/..) - those ports all resize the view before running the test, so they don't suffer from the problem, so really only win/ is left to fix. Will upload a patch soon.
Comment 6 Nikolas Zimmermann 2012-02-09 03:55:40 PST
Created attachment 126275 [details]
Patch for win
Comment 7 Early Warning System Bot 2012-02-09 04:14:30 PST
Comment on attachment 126275 [details]
Patch for win

Attachment 126275 [details] did not pass qt-ews (qt):
Output: http://queues.webkit.org/results/11473188
Comment 8 Nikolas Zimmermann 2012-02-09 04:26:49 PST
The Qt build failure is unrelated.
Comment 9 Adam Roben (:aroben) 2012-02-09 09:31:32 PST
Comment on attachment 126275 [details]
Patch for win

View in context: https://bugs.webkit.org/attachment.cgi?id=126275&action=review

> Tools/DumpRenderTree/win/DumpRenderTree.cpp:726
> +        ::InvalidateRect(webViewWindow, 0, TRUE);
> +        ::SendMessage(webViewWindow, WM_PAINT, 0, 0);

Why do we need to do this even for dumpAsText tests?
Comment 10 Eric Seidel (no email) 2012-02-10 10:20:40 PST
Comment on attachment 125906 [details]
Patch for mac

Cleared Dan Bernstein's review+ from obsolete attachment 125906 [details] so that this bug does not appear in http://webkit.org/pending-commit.
Comment 11 Nikolas Zimmermann 2012-02-11 15:54:29 PST
(In reply to comment #9)
> Why do we need to do this even for dumpAsText tests?
Not sure, I just refactored it - it's as it used to be. It looks suspicious though - I don't have a win machine to test though. To stay on the safe-side we could leave it as-is, but I don't know if it works, I couldn't try it.
Comment 12 Nikolas Zimmermann 2012-02-16 04:58:43 PST
Anyone?
Comment 13 Nikolas Zimmermann 2012-02-17 03:07:22 PST
Comment on attachment 126275 [details]
Patch for win

Clearing flags on attachment: 126275

Committed r108054: <http://trac.webkit.org/changeset/108054>
Comment 14 Nikolas Zimmermann 2012-02-17 03:07:32 PST
All reviewed patches have been landed.  Closing bug.