If an html:label has both a title and inner text, title becomes acc name for control this label is labelling.

VERIFIED FIXED

Status

()

Core
Disability Access APIs
--
major
VERIFIED FIXED
10 years ago
10 years ago

People

(Reporter: MarcoZ, Assigned: surkov)

Tracking

(Blocks: 1 bug, {access, regression})

Trunk
access, regression
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

10 years ago
Found in Bugzilla after bug 455886 landed:
If an HTML:label has both a @title attribute and inner text:
1. The inner text becomes the accName for the label as usual.
2. The contents of the @title attribute becomes the accName of the control this label is associated with via the @for attribute. This is a regression.
(Reporter)

Comment 1

10 years ago
Created attachment 364064 [details]
Testcase

This demonstrates the problem. Look at the accName of the label and the combobox, they should be identically called "Country:", but aren't.

The same can be observed in Bugzilla on any bug with the "Wanted-next" and other such blocking/wanted/etc. flags. And the factor is the title of the label rather than the title of the combobox, as in Bugzilla the same title is present on both controls. I reduced the testcase to the actual problematic constellation.
(Assignee)

Comment 2

10 years ago
Created attachment 364079 [details] [diff] [review]
mochitest

the problem is 
nsTextEquivUtils::AppendFromAccessible is called on label accessible and gets the label name. Since reqursive name from subtree is denied then we do not get name from subtree for label and get its name from @title attribute.
(Assignee)

Updated

10 years ago
Blocks: 459353
(Assignee)

Comment 3

10 years ago
Created attachment 364308 [details] [diff] [review]
patch
Assignee: nobody → surkov.alexander
Attachment #364079 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #364308 - Flags: review?(marco.zehe)
(Assignee)

Updated

10 years ago
Attachment #364308 - Flags: review?(david.bolter)
(Reporter)

Comment 4

10 years ago
Comment on attachment 364308 [details] [diff] [review]
patch

This fixes the bug, and on my system all tests pass. r=me for the functional part.
Attachment #364308 - Flags: review?(marco.zehe) → review+
Comment on attachment 364308 [details] [diff] [review]
patch

r=me
Thanks.
Attachment #364308 - Flags: review?(david.bolter) → review+
(Assignee)

Comment 6

10 years ago
http://hg.mozilla.org/mozilla-central/rev/f2f97a49b6a1
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
(Assignee)

Updated

10 years ago
Flags: in-testsuite+
(Reporter)

Comment 7

10 years ago
Verified fixed in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090228 Minefield/3.2a1pre
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.