Remove Leopard Accessibility support from WebCore (now that no port builds on Leopard)
Created attachment 150094 [details] Patch
Comment on attachment 150094 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=150094&action=review > Source/WebCore/accessibility/AccessibilityARIAGrid.cpp:46 > m_isAccessibilityTable = true; Should we initialize this on the initialization list now that if-def is gone? > Source/WebCore/accessibility/AccessibilityTable.cpp:54 > m_isAccessibilityTable = isTableExposableThroughAccessibility(); Ditto.
Comment on attachment 150094 [details] Patch A task for another day. :)
Comment on attachment 150094 [details] Patch Rejecting attachment 150094 [details] from commit-queue. New failing tests: accessibility/aria-roles.html Full output: http://queues.webkit.org/results/13109339
Created attachment 150142 [details] Archive of layout-test-results from ec2-cq-03 The attached test failures were seen while running run-webkit-tests on the commit-queue. Bot: ec2-cq-03 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
Comment on attachment 150094 [details] Patch Attachment 150094 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/13106390 New failing tests: accessibility/aria-roles.html
Created attachment 150162 [details] Archive of layout-test-results from ec2-cr-linux-01 The attached test failures were seen while running run-webkit-tests on the chromium-ews. Bot: ec2-cr-linux-01 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
These comparisons are all now with MAC_OS_X_VERSION_MIN_REQUIRED, which makes them slightly harder to grep for/remove unfortunately.
Comment on attachment 150094 [details] Patch I don't plan to take this on again anytime soon.
(In reply to comment #9) > (From update of attachment 150094 [details]) > I don't plan to take this on again anytime soon. Are you saying you want someone else to finish this up?
That would be fine. I'm also happy to close this. I'm not actively working on removing LEOPARD code right now.
Comment on attachment 150094 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=150094&action=review >> Source/WebCore/accessibility/AccessibilityARIAGrid.cpp:46 >> m_isAccessibilityTable = true; > > Should we initialize this on the initialization list now that if-def is gone? yes we can do this one >> Source/WebCore/accessibility/AccessibilityTable.cpp:54 >> m_isAccessibilityTable = isTableExposableThroughAccessibility(); > > Ditto. i believe there were some issues in calling this method from the constructor. Right now it lives in the init() method
Created attachment 188191 [details] patch
Comment on attachment 188191 [details] patch Looks reasonable to me.
Comment on attachment 188191 [details] patch Attachment 188191 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://queues.webkit.org/results/16580061 New failing tests: platform/mac/accessibility/aria-treegrid.html
Created attachment 188384 [details] patch for landing
(In reply to comment #16) > Created an attachment (id=188384) [details] > patch for landing Previous patch caused that test to fail because AccessibilityARIAGrid wasn't calling AXRenderObject::init The easy fix is for AXARIAGrid to override isTableExposableThroughAccessibility() and return true instead of trying to have AXTable return a value for AXARIAGrid
http://trac.webkit.org/changeset/142895