Summary: | AX: Layout tests related to text alternative computation need to be done differently | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Joanmarie Diggs <jdiggs> | ||||||
Component: | Accessibility | Assignee: | Joanmarie Diggs <jdiggs> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Normal | CC: | aboxhall, apinheiro, cfleizach, clopez, commit-queue, dmazzoni, jcraig, mario, mcatanzaro, samuel_white, webkit-bug-importer, zan | ||||||
Priority: | P2 | Keywords: | InRadar | ||||||
Version: | WebKit Nightly Build | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
Bug Depends on: | 157822 | ||||||||
Bug Blocks: | |||||||||
Attachments: |
|
Description
Joanmarie Diggs
2016-04-29 10:21:58 PDT
*** Bug 106340 has been marked as a duplicate of this bug. *** I see only one failing test marked against this bug: accessibility/gtk/title-and-alt.html. This test was fixed by r200261, a commit clearly unrelated to accessibility code. Michael: This bug is not about a specific failure; it's about the need to write the tests in such a way as to not rely upon a specific property (e.g. description) having a specific value. FWIW, there are at least a few tests which currently pass even though they are a functionally failing because in ATK the property is being exposed on the same property (e.g. description) as the Mac even though description on the Mac is not the same as description in ATK. (In reply to comment #3) > I see only one failing test marked against this bug: > accessibility/gtk/title-and-alt.html. This test was fixed by r200261, a > commit clearly unrelated to accessibility code. BTW: 200261 did not fix it. See https://trac.webkit.org/changeset/200260. Maybe the "FAIL" expectations weren't the right approach. But the test is still failing and there is a bug which still need to be fixed. But because they are not in the TestExpectations, one now needs to grep for "FAIL" rather than look at TestExpectations. *** Bug 131496 has been marked as a duplicate of this bug. *** Created attachment 279365 [details]
Proposal 1, Take 1
Comment on attachment 279365 [details] Proposal 1, Take 1 Attachment 279365 [details] did not pass mac-debug-ews (mac): Output: http://webkit-queues.webkit.org/results/1346738 New failing tests: storage/websql/change-version.html Created attachment 279368 [details]
Archive of layout-test-results from ews112 for mac-yosemite
The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews112 Port: mac-yosemite Platform: Mac OS X 10.10.5
(In reply to comment #10) > Created attachment 279368 [details] > Archive of layout-test-results from ews112 for mac-yosemite > > The attached test failures were seen while running run-webkit-tests on the > mac-debug-ews. > Bot: ews112 Port: mac-yosemite Platform: Mac OS X 10.10.5 I think this is a false positive because the only thing I've touched in my patch is accessibility layout tests, along with adding some utility methods that only the accessibility layout tests call. How those changes could break storage/websql/change-version.html is beyond me. Comment on attachment 279365 [details]
Proposal 1, Take 1
Chris, here's my initial proposal. Please let me know what you think. Thanks!
Comment on attachment 279365 [details] Proposal 1, Take 1 View in context: https://bugs.webkit.org/attachment.cgi?id=279365&action=review > LayoutTests/resources/accessibility-helper.js:36 > +function platformValueForW3CName(accessibilityObject, includeSource=false) { Looks great. Why did you go with "W3CName"? Do you think that suffix is necessary, or would platformValueForAccessibleName be valid? Thanks (In reply to comment #13) > Why did you go with "W3CName"? Do you think that suffix is necessary, or > would platformValueForAccessibleName be valid? Brutal explicitness. :) Description is worse, so to use that: Description could hypothetically be: 1. Some generic term (like properties) 2. The WKTR's AccessibilityUIElement::description() 3. Your platform's AXDescription 4. My platform's AtkObject description 5. The W3C's accessible description I think it's worth three chars to eliminate the possibility of confusion. Comment on attachment 279365 [details]
Proposal 1, Take 1
cq+ing this patch because as previously indicated, I believe the identified failure was/is a false positive. This patch consists entirely of Accessibility layout test changes.
Comment on attachment 279365 [details] Proposal 1, Take 1 Clearing flags on attachment: 279365 Committed r201216: <http://trac.webkit.org/changeset/201216> All reviewed patches have been landed. Closing bug. |