Bug 73409 - [GTK] placeholder-related reftests failing
Summary: [GTK] placeholder-related reftests failing
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: Gtk, LayoutTestFailure
: 86472 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-11-30 01:22 PST by Philippe Normand
Modified: 2020-06-19 00:37 PDT (History)
13 users (show)

See Also:


Attachments
Updating tests (5.64 KB, patch)
2012-05-16 07:15 PDT, Dominik Röttsches (drott)
tkent: review-
webkit.review.bot: commit-queue-
Details | Formatted Diff | Diff
Archive of layout-test-results from ec2-cr-linux-04 (739.92 KB, application/zip)
2012-05-16 08:19 PDT, WebKit Review Bot
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Philippe Normand 2011-11-30 01:22:43 PST
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.
Comment 1 Dominik Röttsches (drott) 2012-05-16 06:45:30 PDT
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.
Comment 2 Dominik Röttsches (drott) 2012-05-16 06:50:09 PDT
*** Bug 86472 has been marked as a duplicate of this bug. ***
Comment 3 Dominik Röttsches (drott) 2012-05-16 07:15:37 PDT
Created attachment 142253 [details]
Updating tests
Comment 4 WebKit Review Bot 2012-05-16 08:19:23 PDT
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
Comment 5 WebKit Review Bot 2012-05-16 08:19:29 PDT
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
Comment 6 Dominik Röttsches (drott) 2012-05-16 08:26:04 PDT
(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?
Comment 7 Kent Tamura 2012-05-16 23:48:09 PDT
(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.
Comment 8 Dominik Röttsches (drott) 2012-05-17 02:23:21 PDT
(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.
Comment 9 Kent Tamura 2012-05-17 02:29:32 PDT
(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.
Comment 10 Zan Dobersek 2012-05-22 05:54:41 PDT
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.
Comment 11 Diego Pino 2020-06-19 00:37:53 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>