Bug 68512

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?

(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.

*** Bug 123566 has been marked as a duplicate of this bug. ***

Created attachment 216402 [details] Patch

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 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)

Could you give feedback? :)

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

(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

*** Bug 106338 has been marked as a duplicate of this bug. ***

It started timing out consistently in the following range: Last non-timeout: 286510@main First timeout: 286514@main Likely related commit in range: 286511@main (1e6dbc10af5d) AX: Make all layout tests pass on macOS and iOS with ENABLE(INCLUDE_IGNORED_IN_CORE_AX_TREE) https://bugs.webkit.org/show_bug.cgi?id=282647 rdar://139315447 Gardening as timeout.