Bug 73409 – [GTK] placeholder-related reftests failing

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Philippe Normand]

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.

[Dominik Röttsches (drott)]

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.

[Dominik Röttsches (drott)]

*** Bug 86472 has been marked as a duplicate of this bug. ***

[Dominik Röttsches (drott)]

Created attachment 142253 [details]
Updating tests

[WebKit Review Bot]

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

[WebKit Review Bot]

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

[Dominik Röttsches (drott)]

(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?

[Kent Tamura]

(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.

[Dominik Röttsches (drott)]

(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.

[Kent Tamura]

(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.

[Zan Dobersek]

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.

[Diego Pino]

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>