Several accessibility test started failing in the interval r274913-274928: accessibility/gtk/text-for-range-embedded-objects.html accessibility/gtk/text-for-range-entry-and-password.html accessibility/gtk/text-for-range-formatted.html accessibility/gtk/text-for-range-heading.html accessibility/gtk/text-for-range-list-items.html accessibility/gtk/text-for-range-simple.html accessibility/gtk/text-for-range-table-cells.html accessibility/gtk/text-for-range-with-link.html For instance: https://results.webkit.org/?platform=GTK&suite=layout-tests&test=accessibility%2Fgtk%2Ftext-for-range-embedded-objects.html Within the range of revisions, it seems this regression might be introduced by r274919.
Here is the output of one failing test: https://build.webkit.org/results/GTK-Linux-64-bit-Release-Tests/r275155%20%28883%29/accessibility/gtk/text-for-range-embedded-objects-diff.txt --- /home/buildbot/worker/gtk-linux-64-release-tests/build/layout-test-results/accessibility/gtk/text-for-range-embedded-objects-expected.txt +++ /home/buildbot/worker/gtk-linux-64-release-tests/build/layout-test-results/accessibility/gtk/text-for-range-embedded-objects-actual.txt @@ -9,9 +9,9 @@ On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE". -PASS paragraph1.stringForRange(0, -1) is 'Choose: foo bar (pick one)' -PASS paragraph2.stringForRange(0, -1) is 'Choose:  (pick one)' -PASS paragraph3.stringForRange(0, -1) is '' +FAIL paragraph1.stringForRange(0, -1) should be Choose: foo bar (pick one). Was . +FAIL paragraph2.stringForRange(0, -1) should be Choose:  (pick one). Was . +FAIL paragraph3.stringForRange(0, -1) should be . Was . PASS successfullyParsed is true TEST COMPLETE It seems the problem is in the call `paragraph.stringForRange(0, -1)` which instead of returning the whole text of the paragraph is now returning an empty string.
Yes, -1 is not a valid value for an offset in the test runner. I think we should move these tests as unit tests where we are actually testing the atk/atspi interface.
Created attachment 444501 [details] WIP: Rewrite 'text-for-range' a11y layout tests as GTK API tests
When I wrote these tests I got the impression there were already tests in place that where testing Range. Does it make sense to add these new tests or would it be enough with removing the faulting LayoutTests?
I still think it would be great to convert those layout tests into api tests. They would need to be adapted to current tests and if something is already covered we don't need to add it twice, of course.