Bug 68512 - [ATK] Tests failing due to not properly considering flattened text objects
Summary: [ATK] Tests failing due to not properly considering flattened text objects
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Accessibility (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Linux
: P2 Normal
Assignee: Lukasz Gajowy
URL:
Keywords: Gtk, LayoutTestFailure
: 106338 123566 (view as bug list)
Depends on:
Blocks: 98347
  Show dependency treegraph
 
Reported: 2011-09-21 02:01 PDT by Philippe Normand
Modified: 2017-03-11 10:52 PST (History)
7 users (show)

See Also:


Attachments
Patch (28.35 KB, patch)
2013-11-08 09:16 PST, Lukasz Gajowy
cfleizach: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Philippe Normand 2011-09-21 02:01:11 PDT
in the 3 bots.

--- /home/slave/webkitgtk/gtk-linux-64-debug/build/layout-test-results/accessibility/aria-hidden-updates-alldescendants-expected.txt 
+++ /home/slave/webkitgtk/gtk-linux-64-debug/build/layout-test-results/accessibility/aria-hidden-updates-alldescendants-actual.txt 
@@ -9,9 +9,9 @@
 On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE".
 
 
-PASS main.childrenCount is 1
-PASS main.childrenCount is 2
-PASS main.childAtIndex(1).childrenCount is 1
+FAIL main.childrenCount should be 1. Was 0.
+FAIL main.childrenCount should be 2. Was 1.
+FAIL main.childAtIndex(1).childrenCount should be 1. Was 0.
 PASS successfullyParsed is true
 
 TEST COMPLETE

Will skip for now.
Comment 1 Lukasz Gajowy 2013-10-25 03:57:36 PDT
It appears that the https://bugs.webkit.org/show_bug.cgi?id=30883 feature causes the problem with some tests on efl and gtk platforms. Without this feature 5 tests are passing:

platform/efl/accessibility/aria-updates-alldescendants.html
accessibility/inline-continuations.html
accessibility/render-counter-text.html
accessibility/secure-textfield-title-ui.html
accessibility/text-role-with-aria-hidden-inside.html

This is mostly because children are counted differently with this patch (StaticTextRole is ignored and #text children are not counted). So should we generate new expected results (because this behaviour is normal), or improve somehow the implementation of the feature?
Comment 2 Mario Sanchez Prada 2013-10-25 05:53:59 PDT
(In reply to comment #1)
> [...]
> This is mostly because children are counted differently with this patch 
> (StaticTextRole is ignored and #text children are not counted). So should
> we generate new expected results (because this behaviour is normal), or
> improve somehow the implementation of the feature?

You are exactly right. StaticText objects are folded into and exposed through their parents, so we need to provide gtk (and efl) specific result for this test, I'm afraid.
Comment 3 Mario Sanchez Prada 2013-11-04 06:44:53 PST
*** Bug 123566 has been marked as a duplicate of this bug. ***
Comment 4 Lukasz Gajowy 2013-11-08 09:16:30 PST
Created attachment 216402 [details]
Patch
Comment 5 chris fleizach 2013-11-08 09:45:28 PST
Comment on attachment 216402 [details]
Patch 

View in context: https://bugs.webkit.org/attachment.cgi?id=216402&action=review

looks pretty good, but some comments inside

> LayoutTests/accessibility/secure-textfield-title-ui.html:25
> +            debug("titleText.stringValue is: " + titleText.stringValue);

this has a 5 character indent

> LayoutTests/accessibility/text-role-with-aria-hidden-inside.html:25
> +        debug("text.stringValue is: " + text.stringValue);

why can't this be run on gtk or efl? and if that's the case we could leave this as a should be

> LayoutTests/platform/efl/accessibility/render-counter-text-expected.txt:5
> +line1.childAtIndex(0).stringValue is:

is stringValue not implemented on efl? seems like we should continue to mark as failure until that's done (since this test isn't really testing anything right now seemingly)
Comment 6 Lukasz Gajowy 2013-11-12 06:02:01 PST
Comment on attachment 216402 [details]
Patch 

View in context: https://bugs.webkit.org/attachment.cgi?id=216402&action=review

>> LayoutTests/accessibility/secure-textfield-title-ui.html:25
>> +            debug("titleText.stringValue is: " + titleText.stringValue);
> 
> this has a 5 character indent

I will fix this in another patch after I get feedback to the comments below. :)

>> LayoutTests/accessibility/text-role-with-aria-hidden-inside.html:25
>> +        debug("text.stringValue is: " + text.stringValue);
> 
> why can't this be run on gtk or efl? and if that's the case we could leave this as a should be

Basically all the changes in this patch are due to different implementation of Accessibility Objects across platforms. In EFL & GTK (ATK) elements with StaticTextRole are NOT included. In MAC they are. In situation like above the element "text" is ignored, so later it is null. This is why the atk specific -expected.txt files are different and the test is modified. Can i leave it as it is?

>> LayoutTests/platform/efl/accessibility/render-counter-text-expected.txt:5
>> +line1.childAtIndex(0).stringValue is:
> 
> is stringValue not implemented on efl? seems like we should continue to mark as failure until that's done (since this test isn't really testing anything right now seemingly)

The stringValue is implemented - this situation is analogous to the one described above. The string value returns nothing in this case, because StaticTextRole is Ignored (see: WebCore/accessibility/atk/AccessibilityObjectAtk.cpp line:65)
Comment 7 Lukasz Gajowy 2013-11-22 00:53:35 PST
Could you give feedback? :)
Comment 8 Mario Sanchez Prada 2013-12-06 03:56:18 PST
Comment on attachment 216402 [details]
Patch 

View in context: https://bugs.webkit.org/attachment.cgi?id=216402&action=review

> LayoutTests/accessibility/aria-hidden-updates-alldescendants.html:30
> -          
> +

Please avoid including this kind of "changes" :)

> LayoutTests/accessibility/secure-textfield-title-ui.html:-14
> -

Ditto.

> LayoutTests/accessibility/text-role-with-aria-hidden-inside-expected.txt:6
> -PASS text.stringValue is 'AXValue: Song Title Artist Name (4 stars, 1,234 ratings)'
> +text.stringValue is: 'AXValue: Song Title Artist Name (4 stars, 1,234 ratings)'

Unneeded change

>>> LayoutTests/accessibility/text-role-with-aria-hidden-inside.html:25
>>> +        debug("text.stringValue is: " + text.stringValue);
>> 
>> why can't this be run on gtk or efl? and if that's the case we could leave this as a should be
> 
> Basically all the changes in this patch are due to different implementation of Accessibility Objects across platforms. In EFL & GTK (ATK) elements with StaticTextRole are NOT included. In MAC they are. In situation like above the element "text" is ignored, so later it is null. This is why the atk specific -expected.txt files are different and the test is modified. Can i leave it as it is?

Maybe we can just use debug here and adapt in the platform specific expectations. That way the test itself would really be platform agnostic

>>> LayoutTests/platform/efl/accessibility/render-counter-text-expected.txt:5
>>> +line1.childAtIndex(0).stringValue is:
>> 
>> is stringValue not implemented on efl? seems like we should continue to mark as failure until that's done (since this test isn't really testing anything right now seemingly)
> 
> The stringValue is implemented - this situation is analogous to the one described above. The string value returns nothing in this case, because StaticTextRole is Ignored (see: WebCore/accessibility/atk/AccessibilityObjectAtk.cpp line:65)

Maybe it's better to just skip this test in GTK and EFL then since, as Chris pointed out, it's not testing anything right now
Comment 9 Mario Sanchez Prada 2013-12-06 04:20:03 PST
(In reply to comment #8)
> > > LayoutTests/accessibility/text-role-with-aria-hidden-inside-expected.txt:6
> > -PASS text.stringValue is 'AXValue: Song Title Artist Name (4 stars, 1,234 ratings)'
> > +text.stringValue is: 'AXValue: Song Title Artist Name (4 stars, 1,234 ratings)'
> 
> Unneeded change
> 
Forget about this comment. It was a mistake of mine
Comment 10 Martin Robinson 2014-04-07 19:28:43 PDT
*** Bug 106338 has been marked as a duplicate of this bug. ***