Since they were converted to ref tests in r101233, fast/forms/placeholder-set-attribute.html fast/forms/search-placeholder-value-changed.html fast/forms/textarea-placeholder-set-attribute.html are failing consistently on GTK bots.
In my understanding the repainting expectation in these tests is not reliable. They fail on GTK, they are flaky in EFL. In order to get the repainting correctly tested, the same methodology as in http://trac.webkit.org/changeset/106918 needs to be applied. We need to include the repaint.js harness to ensure the right timing for repaints with these tests. Patch will follow.
*** Bug 86472 has been marked as a duplicate of this bug. ***
Created attachment 142253 [details] Updating tests
Comment on attachment 142253 [details] Updating tests Attachment 142253 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/12722159 New failing tests: fast/forms/search-placeholder-value-changed.html fast/forms/placeholder-set-attribute.html fast/forms/textarea-placeholder-set-attribute.html
Created attachment 142267 [details] Archive of layout-test-results from ec2-cr-linux-04 The attached test failures were seen while running run-webkit-tests on the chromium-ews. Bot: ec2-cr-linux-04 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
(In reply to comment #4) > (From update of attachment 142253 [details]) > Attachment 142253 [details] did not pass chromium-ews (chromium-xvfb): > Output: http://queues.webkit.org/results/12722159 Kent, can you advice how to solve this? Do I need to add something to chromium's test_expectations.txt to get them rebaselined?
(In reply to comment #6) > (In reply to comment #4) > > (From update of attachment 142253 [details] [details]) > > Attachment 142253 [details] [details] did not pass chromium-ews (chromium-xvfb): > > Output: http://queues.webkit.org/results/12722159 > > Kent, can you advice how to solve this? Do I need to add something to chromium's test_expectations.txt to get them rebaselined? I don't think this patch works. You're trying to change the rendering results of these tests by LTC.display(). You need to update *-expected.html too, but I don't think LTC.display() makes sense in ref tests.
(In reply to comment #7) > (In reply to comment #6) > I don't think this patch works. You're trying to change the rendering results of these tests by LTC.display(). You need to update *-expected.html too, but I don't think LTC.display() makes sense in ref tests. Well it does work, the tests pass correctly afterwards on GTK. And these tests check for elements to be repainted. The previous way of notifyDone does not allow them to pass on GTK and makes them fail on EFL since the repainting happens to late. That's explained in Nikolas' explanations in r106918.
(In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > I don't think this patch works. You're trying to change the rendering results of these tests by LTC.display(). You need to update *-expected.html too, but I don't think LTC.display() makes sense in ref tests. > > Well it does work, the tests pass correctly afterwards on GTK. And these tests check for elements to be repainted. The previous way of notifyDone does not allow them to pass on GTK and makes them fail on EFL since the repainting happens to late. That's explained in Nikolas' explanations in r106918. I understand the problem. But the solution looks wrong. Do you understand what's LayoutTestController.display() does? LTC.display() in EFL is not implemented, LTC.display() in GTK looks incorrect.
Two of the three tests now pass for Gtk after r117947. The remaining failure is fast/forms/textarea-placeholder-set-attribute.html, the 'Placeholder' text does not become visible until the textarea is hovered over. (In reply to comment #9) > Do you understand what's LayoutTestController.display() does? LTC.display() in EFL is not implemented, LTC.display() in GTK looks incorrect. LTC.display() is indeed incorrect in GTK's DumpRenderTree. As far as I looked into it, calling this method should start repaint tracking in the FrameView. The name is quite misleading in that regard.
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>