Active Accessibility: Html Select Options do not get focus

VERIFIED FIXED in mozilla1.0


18 years ago
4 months ago


(Reporter: dsirnapalli, Assigned: aaronlev)


({access, topembed+})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [ADT2])


(1 attachment, 1 obsolete attachment)

steps to reproduce.
open the following html in mozilla.
<title> Select List </title>
<!-- Test Select List -->

<u><b>Testing Select List</b></u>
Choose your favorite color
  <option> Red    </option>
  <option> Blue   </option>
  <option> Green  </option>
  <option> Yellow </option>
open mozInspect and click on "Show Hightlight rectangle" button. Then click on 
select list values. we donot get the focus on the values.the focus is only on 
the drop down list window. In IE we see the focus on each list item.
Severity: normal → major
Priority: -- → P2
Target Milestone: --- → mozilla0.9.8

*** This bug has been marked as a duplicate of 118018 ***
Closed: 18 years ago
Resolution: --- → DUPLICATE
I still do no see the bounds on the list items.
click on the drop down list. you see values Red, Blue, Green, Yellow. Open 
mozInspect and click on "Show highlight rectangle" and take over to one of these 
values. say take over Green. You still see the bounds on select list but not on 
value "Green". Repeat it in IE. you see when you select "Green" the bounds will 
be shown on value "Green".
When you select "Green" in mozilla, Values in mozInspect are
Name:none, Role:client State:normal Value:none  
When you select "Green" in IE, Values in mozInspect are
Name:Green, Role:list item State:selected, selectable, focused, 
focusable, Value:none
I feel list item in not accessible in our case. we should make it accessible.
However the fix for bug#118018 works.
Resolution: DUPLICATE → ---
Okay, sorry -- I fixed something else where select list items were reporting
incorrect bounds when you got to the item through accexplorer.

I didn't change anything as far as focus on these items go.
Keywords: access, fcc508
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Severity: major → blocker
Keywords: nsbeta1
changing summary to more accurately reflect the problem. This is a problem for
the comobobox html widget ( <select> or <select size="1"> ) as opposed to the
listbox html widget ( <select size="4"> ). 
Summary: Active Accessibility: Html Select List Values does not get focus. → Active Accessibility: Html Select Options do not get focus in comboboxes ( listbox ok )
strangely mousing over select options in a listbox works, where mousing over
them in a combobox dropdown does not. the problem is somewhere in our AccGetAt
routine I think. Possibly in bounds calculations, but that doesn't really make
senese with the 2 outcomes I am seeing.
looks like the problem way be with hit detection at the very beginning ( in
nsWindow.cpp ) because when we mouse over in the drop down we don't even get the
information for the other 2 things there except for the bounds. It's as if we
know something accessible is there but we can't find out so we are going we a
very primitive base class instead of drilling down into a derived class. But we
don't even hit the AccGetAt code in these situations, it shortcuts before we
event get there.
Hmmm... looks like we aren't even getting the request for the object when we
mouse over. Like the request is going to the OS instead. I'm trying to find out
if the window ( for the drop down ) is native. If so we may be running into
problems there. If not.... 
I've taken the course of watching for the change events to get notification to
focus the individual options. In digging around I have noticed we are no longer
getting a primary frame for the HTML Select Option, so I'm investigating that.
Pulled and currently building a tree to see how it worked when I checked the
code in. This may be an oversight in the original code, but I do remember it
Keywords: topembed
Blocks: 75785
Keywords: topembedtopembed+
nsbeta1+ per ADT triage team, Should work in XBL Form Controls, adding dep on
bug 57209
Depends on: 57209
Keywords: nsbeta1nsbeta1+
Blocks: atfmeta
Yes, John, I agree with you. the function 
shell->GetPrimaryFrameFor(content, &frame)
always returns a null frame.
And I also think a focus event must be fired
in nsListControlFrame::SingleSelection funtion.
When user navigate the popuplist by either
mouse or keyboard, this function will be called.

I've done a patch and it's working. But I'm
not sure is this a right way?
We should not fire any new DOM focus events that aren't already fired. We have
to use events that are already there, such as onchange, or write custom events.
Custom events are like "DOMMenuitemActive", which we fire in places where we
need to know the focus, but the W3C spec says there should be no focus event there.
But there is not any events when the combobox item was selected, at least in 
the nsRootAccessible::HandleEvent. So maybe we need fire a "DOMMenuitemActive" 
John, can you verify whether we used to use onchange for this?
I just investigated:

There are several problems here.

#1 - We no longer fire onchange events for combo box options, when the user hits
an arrow key. This is intentional, and correct, because many sites load a URL
based on a combo box selection. However, we do fire onchange for listbox options. 

#2 - listbox options aren't working because the following GetPrimaryFrameFor in
nsHTMLSelectOptionAccessible::GetFocusedOptionNode() no longer returns a frame
(it now returns null in frame):
  shell->GetPrimaryFrameFor(htmlSelectContent, &frame);

To fix problem #1, we need to fire custom DOMMenuitemActive events, as we do for
XUL comboboxes and menus, for HTML comboboxes and menus.

To fix problem #2, we need to figure out why we're no longer getting a frame for
the <select> element.
nsListControlFrame::PerformSelection() is a good place to fire the
DOMMenuitemActive event. It gets called when the selection changes from keyboard
or mouse.

A good example of where that's been done is 
void nsMenuFrame::FireMenuDOMEvent(const nsAString& aDOMEventName)
Listboxes broken now too, because of GetPrimaryFrameFor problem on <select>
elements. Changing summary.
Summary: Active Accessibility: Html Select Options do not get focus in comboboxes ( listbox ok ) → Active Accessibility: Html Select Options do not get focus
Why do not we use this:

  nsCOMPtr<nsIDOMHTMLSelectElement> listFrame(do_QueryInterface(aListNode));

instead of those:

  nsIFrame *frame = nsnull;
  nsCOMPtr<nsIContent> content(do_QueryInterface(aListNode));
  shell->GetPrimaryFrameFor(content, &frame);

  nsCOMPtr<nsIListControlFrame> listFrame(do_QueryInterface(frame));
  if (!listFrame)
    return NS_ERROR_FAILURE;  

I verified the first line can work properly.

A couple of things:

nsCOMPtr<nsIDOMHTMLSelectElement> listFrame(do_QueryInterface(aListNode));

You're not getting a frame there at all. You're getting a DOM interface. Quite a

Yes, they both have GetSelectedIndex() methods, but the DOM interface version
won't return the focused option index, it returns the first selected option's
index. This means if a user hits shift+down, to extend selection, the wrong item
will be reported to be focused - it should report where you moved to.

I do have a fix for this bug now, will submit it shortly.
Assignee: jgaunt → aaronl
Attachment #77406 - Attachment is obsolete: true
Comment on attachment 77423 [details] [diff] [review]
The fix. We weren't using the correct pres shell, we weren't seeing events in combo boxes, and we weren't getting the selected index in combo boxes

This comment doesn't seem to make sense.

>+        if (!selectControl)   // Don't use EVENT_STATE_CHANGE events fire selects
>           mListener->HandleEvent(nsIAccessibleEventListener::EVENT_STATE_CHANGE, accessible);

Everything else looks good. 
Attachment #77423 - Flags: review+
Changed that comment to:
// Don't use onchange to fire EVENT_STATE_CHANGE events for selects

I'll leave the current patch up there for the sr=.
Comment on attachment 77423 [details] [diff] [review]
The fix. We weren't using the correct pres shell, we weren't seeing events in combo boxes, and we weren't getting the selected index in combo boxes

Attachment #77423 - Flags: superreview+
Keywords: adt1.0.0
Blocks: 135206
QA Contact: doronr → dsirnapalli
adt1.0.0+ (on ADT's behalf) approval for checkin to 1.0.
Keywords: adt1.0.0adt1.0.0+
Comment on attachment 77423 [details] [diff] [review]
The fix. We weren't using the correct pres shell, we weren't seeing events in combo boxes, and we weren't getting the selected index in combo boxes

a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #77423 - Flags: approval+
checked in
Closed: 18 years ago18 years ago
Resolution: --- → FIXED
-- Highlight rectangle waits only for a second and goes back to pane. I verified
this in current nightly build.
steps to reproduce: the above test case in mozilla. mozInspect and click on "Show Hightlight rectangle" button.
3.Then click on select combo box values.
4.we are now able to get the highlight rectangle on the value but it waits only
for a second.
Resolution: FIXED → ---
This has been reopned. Removing adt1.0.0+. Adding ADT2
Keywords: adt1.0.0+
Whiteboard: [ADT2]
Target Milestone: mozilla0.9.9 → mozilla1.0
Accesibility focus events realy do work for HTML select options, as Dharma and I
just determined by looking at it together.

However, AccessibleObjectFromPoint() returns the listbox instead of individual
options. I don't think this is a problem for us in real world usage. 

Marking fixed.
Closed: 18 years ago18 years ago
Resolution: --- → FIXED
-- Marking as verified.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.