Bug 137669

<rdar://problem/18638498>

Created attachment 239742 [details] Patch

See also bug 137672.

Note: this seems to work ok for me with VoiceOver on a mac

Comment on attachment 239742 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=239742&action=review > Source/WebCore/ChangeLog:11 > + Test: accessibility/css-content-attribute.html how come this works on Mac, but not GTK without more modification?

(In reply to comment #5) > (From update of attachment 239742 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=239742&action=review > > > Source/WebCore/ChangeLog:11 > > + Test: accessibility/css-content-attribute.html > > how come this works on Mac, but not GTK without more modification? Good question. Here's what seems to be the case (please correct me if I'm wrong): OS X most of the time is not calling textUnderElement on RenderBlock elements. Instead, you ask for and get the text for the children of those elements (i.e. the RenderInline and RenderText objects). The exception to this rule seems to be when you're getting the title for objects such as headings. But in that case, the mode is TextUnderElementModeSkipIgnoredChildren so you wind up deferring to AccessibilityNodeObject::textUnderElement. In contrast, GTK most of the time IS calling textUnderElement on RenderBlock elements and when it does the mode is TextUnderElementModeIncludeAllChildren because for GTK/ATK, StaticTextRole objects are "ignored" -- their content being folded into the parent block element. But as a result of this mode difference, on GTK, we're not deferring to AccessibilityNodeObject::textUnderElement. In light of the above, I wonder if we could simplify AccessibilityRenderObject::textUnderElement. How much benefit are we getting from our attempts to use a text iterator for consistent handling of whitespace?

(In reply to comment #6) > (In reply to comment #5) > > (From update of attachment 239742 [details]) > > View in context: https://bugs.webkit.org/attachment.cgi?id=239742&action=review > > > > > Source/WebCore/ChangeLog:11 > > > + Test: accessibility/css-content-attribute.html > > > > how come this works on Mac, but not GTK without more modification? > > Good question. Here's what seems to be the case (please correct me if I'm > wrong): > > OS X most of the time is not calling textUnderElement on RenderBlock > elements. Instead, you ask for and get the text for the children of those > elements (i.e. the RenderInline and RenderText objects). The exception to > this rule seems to be when you're getting the title for objects such as > headings. But in that case, the mode is > TextUnderElementModeSkipIgnoredChildren so you wind up deferring to > AccessibilityNodeObject::textUnderElement. > > In contrast, GTK most of the time IS calling textUnderElement on RenderBlock > elements and when it does the mode is TextUnderElementModeIncludeAllChildren > because for GTK/ATK, StaticTextRole objects are "ignored" -- their content > being folded into the parent block element. But as a result of this mode > difference, on GTK, we're not deferring to > AccessibilityNodeObject::textUnderElement. > > In light of the above, I wonder if we could simplify > AccessibilityRenderObject::textUnderElement. How much benefit are we getting > from our attempts to use a text iterator for consistent handling of > whitespace? (In reply to comment #6) > (In reply to comment #5) > > (From update of attachment 239742 [details]) > > View in context: https://bugs.webkit.org/attachment.cgi?id=239742&action=review > > > > > Source/WebCore/ChangeLog:11 > > > + Test: accessibility/css-content-attribute.html > > > > how come this works on Mac, but not GTK without more modification? > > Good question. Here's what seems to be the case (please correct me if I'm > wrong): > > OS X most of the time is not calling textUnderElement on RenderBlock > elements. Instead, you ask for and get the text for the children of those > elements (i.e. the RenderInline and RenderText objects). The exception to > this rule seems to be when you're getting the title for objects such as > headings. But in that case, the mode is > TextUnderElementModeSkipIgnoredChildren so you wind up deferring to > AccessibilityNodeObject::textUnderElement. > > In contrast, GTK most of the time IS calling textUnderElement on RenderBlock > elements and when it does the mode is TextUnderElementModeIncludeAllChildren > because for GTK/ATK, StaticTextRole objects are "ignored" -- their content > being folded into the parent block element. But as a result of this mode > difference, on GTK, we're not deferring to > AccessibilityNodeObject::textUnderElement. > > In light of the above, I wonder if we could simplify > AccessibilityRenderObject::textUnderElement. How much benefit are we getting > from our attempts to use a text iterator for consistent handling of > whitespace? Simplifying these these methods seems like it would be a good idea. It's totally unclear at this time what is expected behavior without actually debugging the code. Do you want to do that with this patch, or do you want to get this change in?

(In reply to comment #7) > Simplifying these these methods seems like it would be a good idea. It's > totally unclear at this time what is expected behavior without actually > debugging the code. > > Do you want to do that with this patch, or do you want to get this change in? Regarding the simplification, I just opened bug 137927. If we need to debug the code just to figure it out, and given our platforms' different approaches to accessible text, tackling that problem should be separated out. As for getting the change from the attached patch in, I'm comfortable with it for my platform if you're comfortable with it for yours. If you'd prefer I make the change in the ATK code or write some more tests so we can be sure it isn't breaking anything on the Mac, I'm happy to do so.

Comment on attachment 239742 [details] Patch Clearing flags on attachment: 239742 Committed r174992: <http://trac.webkit.org/changeset/174992>

All reviewed patches have been landed. Closing bug.