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>
Created attachment 215849 [details] patch
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
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
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
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
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
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
Created attachment 215950 [details] patch
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.
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
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
(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?
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
Created attachment 215963 [details] patch
http://trac.webkit.org/changeset/158617
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
(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.