Bug 58020
| Summary: | [GTK] fast/forms/input-number-large-padding.html fails | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Philippe Normand <pnormand> |
| Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | a.renevier, tkent, zan |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | PC | ||
| OS: | OS X 10.5 | ||
Philippe Normand
--- /home/slave/webkitgtk/gtk-linux-64-debug/build/layout-test-results/fast/forms/input-number-large-padding-expected.txt 2011-04-07 00:43:42.193766486 -0700
+++ /home/slave/webkitgtk/gtk-linux-64-debug/build/layout-test-results/fast/forms/input-number-large-padding-actual.txt 2011-04-07 00:43:42.193766486 -0700
@@ -3,7 +3,7 @@
On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE".
-PASS numberInput.value is "1"
+FAIL numberInput.value should be 1. Was 0.
PASS successfullyParsed is true
TEST COMPLETE
Added in http://trac.webkit.org/changeset/83145
Will skip for now.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Kent Tamura
Hmm, it's curious. input-number-large-padding.html is very similar to input-number-events.html, which is passing on GTK.
Philippe Normand
eventSender.mouseMoveTo(numberInput.offsetLeft + numberInput.offsetWidth - 10, numberInput.offsetTop + numberInput.offsetHeight / 4);
Humm... Could it be that on GTK clicking on that position has not the expected effect?
Zan Dobersek
The tests covered by this bug were found to be passing consistently after moving from using the Skipped list to using test_expectations.txt. Their expectations were removed in r116122[1] (covered by bug #85591). Closing the bug.
1: http://trac.webkit.org/changeset/116122