Bug 123697 – AX: Mail attachments at the start of an email are not output by VoiceOver

• Status: RESOLVED
• Resolution: FIXED
• Component: Accessibility

[chris fleizach]

Attachments that are the first character of a sent email are not seen by accessibility.

Repro Steps:
Compose a new email and attach a text document
Send it to yourself
Turn on VO and then try to get VO to output the attachment
Notice that VO will never read it

The problem is that the message never contains the AppKit text attachment character (e.g. \ufffc).


<rdar://problem/15184300>

[chris fleizach]

Created attachment 215849 [details]
patch

[Build Bot]

Comment on attachment 215849 [details]
patch

Attachment 215849 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.appspot.com/results/19608518

New failing tests:
platform/mac/accessibility/object-replacements-at-node-start.html
editing/execCommand/remove-format-elements.html
editing/execCommand/button.html
editing/pasteboard/paste-noscript-xhtml.xhtml

[Build Bot]

Created attachment 215857 [details]
Archive of layout-test-results from webkit-ews-09 for mac-mountainlion-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-09  Port: mac-mountainlion-wk2  Platform: Mac OS X 10.8.5

[Build Bot]

Comment on attachment 215849 [details]
patch

Attachment 215849 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.appspot.com/results/20408008

New failing tests:
platform/mac/accessibility/object-replacements-at-node-start.html
editing/execCommand/remove-format-elements.html
editing/execCommand/button.html
editing/pasteboard/paste-noscript-xhtml.xhtml

[Build Bot]

Created attachment 215860 [details]
Archive of layout-test-results from webkit-ews-10 for mac-mountainlion-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-10  Port: mac-mountainlion-wk2  Platform: Mac OS X 10.8.5

[Build Bot]

Comment on attachment 215849 [details]
patch

Attachment 215849 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.appspot.com/results/20478010

New failing tests:
platform/mac/accessibility/object-replacements-at-node-start.html
editing/execCommand/remove-format-elements.html
editing/execCommand/button.html
editing/pasteboard/paste-noscript-xhtml.xhtml

[Build Bot]

Created attachment 215862 [details]
Archive of layout-test-results from webkit-ews-07 for mac-mountainlion

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-07  Port: mac-mountainlion  Platform: Mac OS X 10.8.5

[chris fleizach]

Created attachment 215950 [details]
patch

[Ryosuke Niwa]

Comment on attachment 215950 [details]
patch

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

> LayoutTests/platform/mac/accessibility/object-replacement-with-no-rendered-children-at-node-start-expected.txt:1
> +b

Can we hide this b once the test had run?

> LayoutTests/platform/mac/accessibility/object-replacement-with-no-rendered-children-at-node-start-expected.txt:7
> +Object string for BODY range: b

What happened to the text here?

> LayoutTests/platform/mac/accessibility/object-replacement-with-rendered-children-at-node-start-expected.txt:2
> +inside
> +b

Ditto.

[chris fleizach]

Comment on attachment 215950 [details]
patch

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

>> LayoutTests/platform/mac/accessibility/object-replacement-with-no-rendered-children-at-node-start-expected.txt:1
>> +b
> 
> Can we hide this b once the test had run?

yep

>> LayoutTests/platform/mac/accessibility/object-replacement-with-no-rendered-children-at-node-start-expected.txt:7
>> +Object string for BODY range: b
> 
> What happened to the text here?

That's the attachment character when rendered in expected results (0x7FFF) i think. So that's what we're looking for

[EFL EWS Bot]

Comment on attachment 215950 [details]
patch

Attachment 215950 [details] did not pass efl-wk2-ews (efl-wk2):
Output: http://webkit-queues.appspot.com/results/19578823

[Ryosuke Niwa]

(In reply to comment #10)
> (From update of attachment 215950 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=215950&action=review
>
> >> LayoutTests/platform/mac/accessibility/object-replacement-with-no-rendered-children-at-node-start-expected.txt:7
> >> +Object string for BODY range: b
> > 
> > What happened to the text here?
> 
> That's the attachment character when rendered in expected results (0x7FFF) i think. So that's what we're looking for

Can we compare the results in script or something so that the output isn't so mysterious?

[chris fleizach]

Comment on attachment 215950 [details]
patch

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

>>>> LayoutTests/platform/mac/accessibility/object-replacement-with-no-rendered-children-at-node-start-expected.txt:7
>>>> +Object string for BODY range: b
>>> 
>>> What happened to the text here?
>> 
>> That's the attachment character when rendered in expected results (0x7FFF) i think. So that's what we're looking for
> 
> Can we compare the results in script or something so that the output isn't so mysterious?

sure, i'll replace that character with something meaningful

[chris fleizach]

Created attachment 215963 [details]
patch

[chris fleizach]

http://trac.webkit.org/changeset/158617

[Darin Adler]

Comment on attachment 215963 [details]
patch

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

> Tools/DumpRenderTree/AccessibilityUIElement.cpp:1257
> +    return 0;

nullptr

> Tools/DumpRenderTree/AccessibilityUIElement.cpp:1262
> +    return 0;

nullptr

> Tools/DumpRenderTree/mac/AccessibilityUIElementMac.mm:1573
> +    return 0;

nullptr

> Tools/DumpRenderTree/mac/AccessibilityUIElementMac.mm:1583
> +    return 0;

nullptr

> Tools/WebKitTestRunner/InjectedBundle/atk/AccessibilityUIElementAtk.cpp:1461
> +    return 0;    

nullptr

> Tools/WebKitTestRunner/InjectedBundle/atk/AccessibilityUIElementAtk.cpp:1467
> +    return 0;

nullptr

> Tools/WebKitTestRunner/InjectedBundle/mac/AccessibilityUIElementMac.mm:1553
> +    return 0;

nullptr

> Tools/WebKitTestRunner/InjectedBundle/mac/AccessibilityUIElementMac.mm:1563
> +    return 0;

nullptr

[chris fleizach]

(In reply to comment #16)
> (From update of attachment 215963 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=215963&action=review
> 
> > Tools/DumpRenderTree/AccessibilityUIElement.cpp:1257
> > +    return 0;
> 
> nullptr
> 
> > Tools/DumpRenderTree/AccessibilityUIElement.cpp:1262
> > +    return 0;
> 
> nullptr
> 
> > Tools/DumpRenderTree/mac/AccessibilityUIElementMac.mm:1573
> > +    return 0;
> 
> nullptr
> 
> > Tools/DumpRenderTree/mac/AccessibilityUIElementMac.mm:1583
> > +    return 0;
> 
> nullptr
> 
> > Tools/WebKitTestRunner/InjectedBundle/atk/AccessibilityUIElementAtk.cpp:1461
> > +    return 0;    
> 
> nullptr
> 
> > Tools/WebKitTestRunner/InjectedBundle/atk/AccessibilityUIElementAtk.cpp:1467
> > +    return 0;
> 
> nullptr
> 
> > Tools/WebKitTestRunner/InjectedBundle/mac/AccessibilityUIElementMac.mm:1553
> > +    return 0;
> 
> nullptr
> 
> > Tools/WebKitTestRunner/InjectedBundle/mac/AccessibilityUIElementMac.mm:1563
> > +    return 0;
> 
> nullptr

Thanks Darin. Instead of doing this piecemeal, I just filed to handle all the cases in DRT WKTR
https://bugs.webkit.org/show_bug.cgi?id=123773
which I'll have a patch ready soon

(In reply to comment #15)
> http://trac.webkit.org/changeset/158617

This caused bug 126322.