Active Accessibility: nsIAccessible's accTakeFocus() does not work as intended on Html Table.

VERIFIED WONTFIX

Status

--
minor
VERIFIED WONTFIX
17 years ago
14 years ago

People

(Reporter: dsirnapalli, Assigned: aaronlev)

Tracking

Trunk
x86
Other

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
I attached the test case. when you see the results accFocused-> shows "Fail" 
and state-> shows 4(STATE_FOCUSED), because table is getting focused.
Test case is large, important functions in the test case are executeTestCase() 
and constructResults(). in executeTestCase() see the lines...
var domNode = getDomNodeTable();
accNode = getAccessibleNode(domNode);
tempaccNode = accNode;

accNode.accTakeFocus();
i am storing the accessible node temporarily in tempaccNode.
at this point i am not sure whether there is focus on table.when you come to 
constructResults() function see the lines..
if(tempaccNode.accGetDOMNode() == accNode.accFocused.accGetDOMNode())
{
  varaccFocused = true;
}
else
{
  varaccFocused = false;
}
the above lines tell that the dom node for both focused node and temp node are 
same.if you try to alert varaccFocused() you can see it shows "true", which 
means the table is focused.
(Reporter)

Comment 1

17 years ago
Created attachment 66322 [details]
Test Case

Test case to reproduce the bug.
(Reporter)

Comment 2

17 years ago
-- try to run the test case in mozilla or mfcEmbed.
(Reporter)

Updated

17 years ago
QA Contact: doronr → dsirnapalli
(Assignee)

Comment 3

17 years ago
Dharma, the test case shows up as a blank page for me.
(Assignee)

Comment 4

17 years ago
I found an easier way to test this.
Load up Inspect, point at a table, click on the focus toolbutton in Inspect.
It will then report STATE_FOCUSED on the table.

As a matter of fact, the same thing happens with anthing that represents a DOM
element.

So we have 3 categories of objects that can have an IAccessible
1. Text nodes - these are not elements, and can never take focus
2. DOM elements that normally can take focus -- links, form elements
3. DOM elements that normally do not take focus -- images, table cells, tables

Items in group 3 - images, table cells and tables, are all exhibiting this
behavior. Through MSAA, you can focus them, and they will report that they are
focused, although there is no CSS rule to make their focus state apparent.

I've decided this isn't really a bug. If the process in question really does
want to focus on one of those elements, I suppose it should be allowed to. At
this point, I really don't want to remove this capability -- the ability to
focus on element will probably be useful at a later point.

Dharma, thanks for reporting this -- it's a good thing we discovered this.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 5

17 years ago
-- sorry, i attached wrong test case. anyway i was able to reproduce it with 
your steps. i am not attaching the test case again.
(Reporter)

Comment 6

17 years ago
-- Marking bug as verified.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.