Bug 223862

Summary:

[GTK] REGRESSION(r274919?): Several accessibility tests are failing

Product:

WebKit

Reporter:

Diego Pino <dpino>

Component:

New Bugs

Assignee:

Diego Pino <dpino>

Status:

NEW ---

Severity:

Normal

CC:

aboxhall, andresg_22, apinheiro, bugs-noreply, cdumez, cfleizach, cgarcia, dmazzoni, ews-watchlist, jcraig, jdiggs, samuel_white

Priority:

Version:

WebKit Nightly Build

Hardware:

Unspecified

OS:

Unspecified

Attachments:

Description	Flags
WIP: Rewrite 'text-for-range' a11y layout tests as GTK API tests	dpino: review?

Description Diego Pino 2021-03-28 22:04:20 PDT

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.

Comment 1 Diego Pino 2021-03-28 22:09:12 PDT

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.

Comment 2 Carlos Garcia Campos 2021-10-08 02:16:46 PDT

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.

Comment 3 Diego Pino 2021-11-17 02:12:33 PST

Created attachment 444501 [details]
WIP: Rewrite 'text-for-range' a11y layout tests as GTK API tests

Comment 4 Diego Pino 2022-07-19 21:15:56 PDT

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?

Comment 5 Carlos Garcia Campos 2022-07-19 22:41:59 PDT

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.