WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
120550
AX: REGRESSION: @title is exposed as AXDescription when label label from contents already exists.
https://bugs.webkit.org/show_bug.cgi?id=120550
Summary
AX: REGRESSION: @title is exposed as AXDescription when label label from cont...
James Craig
Reported
2013-08-30 14:42:30 PDT
AX: REGRESSION: @title is exposed as AXDescription when label label from contents already exists. Presumably this is not traversing the contents correctly (considering the element to have no label from contents) and therefore exposing the @title value as AXDescription instead of the default AXHelp.
Attachments
test case demonstrating bug
(303 bytes, text/html)
2013-08-30 14:45 PDT
,
James Craig
no flags
Details
patch
(10.23 KB, patch)
2013-09-02 18:59 PDT
,
chris fleizach
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1
2013-08-30 14:43:23 PDT
<
rdar://problem/14882968
>
James Craig
Comment 2
2013-08-30 14:45:49 PDT
Created
attachment 210162
[details]
test case demonstrating bug
James Craig
Comment 3
2013-08-30 14:47:19 PDT
Looks like it also exposes the contents as both AXDescription and AXHelp, which should never happen, and results in extremely redundant speech for VoiceOver.
chris fleizach
Comment 4
2013-09-02 18:59:48 PDT
Created
attachment 210318
[details]
patch
Mario Sanchez Prada
Comment 5
2013-09-03 03:04:13 PDT
Comment on
attachment 210318
[details]
patch View in context:
https://bugs.webkit.org/attachment.cgi?id=210318&action=review
> Source/WebCore/accessibility/mac/WebAccessibilityObjectWrapperMac.mm:2040 > + switch (text.textSource) { > + case VisibleText: > + case ChildrenText: > + case LabelByElementText: > + visibleTextAvailable = true; > + default: > + break; > + } > + > + if (text.textSource == TitleTagText && !visibleTextAvailable) > return text.text;
I believe this is safe just because TitleTagText sources are always appended "almost" at the end (in AccessibilityNodeObject::helpText() and before maybe adding a PlaceHolderText source in accessibilityText()). However, if the order was not always that one (e.g. what if you have some VisibleText source after the TitleTagText one?) then you might find yourself returning text.text here because visibleTextAvailable hasn't set to true yet. Setting r+ anyway because this is Mac specific code and you definitely know better. Just commenting that in case you might want to consider it in order to protect against situations that might happen in the future if the assertion about the order in which TitleTagText source is being appended was no longer true.
chris fleizach
Comment 6
2013-09-03 22:48:14 PDT
(In reply to
comment #5
)
> (From update of
attachment 210318
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=210318&action=review
> > > Source/WebCore/accessibility/mac/WebAccessibilityObjectWrapperMac.mm:2040 > > + switch (text.textSource) { > > + case VisibleText: > > + case ChildrenText: > > + case LabelByElementText: > > + visibleTextAvailable = true; > > + default: > > + break; > > + } > > + > > + if (text.textSource == TitleTagText && !visibleTextAvailable) > > return text.text; > > I believe this is safe just because TitleTagText sources are always appended "almost" at the end (in AccessibilityNodeObject::helpText() and before maybe adding a PlaceHolderText source in accessibilityText()). However, if the order was not always that one (e.g. what if you have some VisibleText source after the TitleTagText one?) then you might find yourself returning text.text here because visibleTextAvailable hasn't set to true yet. > > Setting r+ anyway because this is Mac specific code and you definitely know better. Just commenting that in case you might want to consider it in order to protect against situations that might happen in the future if the assertion about the order in which TitleTagText source is being appended was no longer true.
Yes this is part of the contract of the accessibilityText method. You rely on the order of the text being appended in importance Thanks
WebKit Commit Bot
Comment 7
2013-09-03 23:12:36 PDT
Comment on
attachment 210318
[details]
patch Clearing flags on attachment: 210318 Committed
r155022
: <
http://trac.webkit.org/changeset/155022
>
WebKit Commit Bot
Comment 8
2013-09-03 23:12:38 PDT
All reviewed patches have been landed. Closing bug.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug