Closed
Bug 112978
Opened 23 years ago
Closed 23 years ago
Active Accessibility: Html Select Options do not get focus
Categories
(SeaMonkey :: General, defect, P2)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla1.0
People
(Reporter: dsirnapalli, Assigned: aaronlev)
References
Details
(Keywords: access, topembed+, Whiteboard: [ADT2])
Attachments
(1 file, 1 obsolete file)
|
(deleted),
patch
|
mozilla
:
review+
attinasi
:
superreview+
asa
:
approval+
|
Details | Diff | Splinter Review |
steps to reproduce.
open the following html in mozilla.
------------------------
<html>
<title> Select List </title>
<body>
<!-- Test Select List -->
<u><b>Testing Select List</b></u>
<br><br>
Choose your favorite color
<select>
<option> Red </option>
<option> Blue </option>
<option> Green </option>
<option> Yellow </option>
</select>
</body>
</html>
--------------------------------
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.
|
Assignee | |
Updated•23 years ago
|
Severity: normal → major
|
||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla0.9.8
|
|
Assignee | |
Comment 1•23 years ago
|
||
*** This bug has been marked as a duplicate of 118018 ***
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
|
Reporter | |
Comment 2•23 years ago
|
||
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.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
|
|
Assignee | |
Comment 3•23 years ago
|
||
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.
|
|
||
Updated•23 years ago
|
Severity: major → blocker
|
|
||
Comment 4•23 years ago
|
||
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 )
|
|
||
Comment 5•23 years ago
|
||
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.
|
|
||
Comment 6•23 years ago
|
||
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.
|
|
||
Comment 7•23 years ago
|
||
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....
|
|
||
Comment 8•23 years ago
|
||
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
working.
|
||
Updated•23 years ago
|
|
||
Comment 9•23 years ago
|
||
nsbeta1+ per ADT triage team, Should work in XBL Form Controls, adding dep on
bug 57209
|
||
Comment 10•23 years ago
|
||
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?
|
|
Assignee | |
Comment 11•23 years ago
|
||
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.
|
|
||
Comment 12•23 years ago
|
||
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"
event.
|
|
Assignee | |
Comment 13•23 years ago
|
||
John, can you verify whether we used to use onchange for this?
|
|
Assignee | |
Comment 14•23 years ago
|
||
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.
|
|
Assignee | |
Comment 15•23 years ago
|
||
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)
|
|
Assignee | |
Comment 16•23 years ago
|
||
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
|
|
Assignee | |
Comment 17•23 years ago
|
||
|
|
||
Comment 18•23 years ago
|
||
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.
|
|
Assignee | |
Comment 19•23 years ago
|
||
Kyle,
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
difference!
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
Status: REOPENED → NEW
|
|
Assignee | |
Comment 20•23 years ago
|
||
|
|
Assignee | |
Updated•23 years ago
|
Attachment #77406 -
Attachment is obsolete: true
|
|
||
Comment 21•23 years ago
|
||
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.
r=jgaunt
Attachment #77423 -
Flags: review+
|
|
Assignee | |
Comment 22•23 years ago
|
||
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=.
Status: NEW → ASSIGNED
|
||
Comment 23•23 years ago
|
||
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
sr=attinasi
Attachment #77423 -
Flags: superreview+
|
|
Reporter | |
Updated•23 years ago
|
QA Contact: doronr → dsirnapalli
|
||
Comment 24•23 years ago
|
||
adt1.0.0+ (on ADT's behalf) approval for checkin to 1.0.
|
||
Comment 25•23 years ago
|
||
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+
|
|
Assignee | |
Comment 26•23 years ago
|
||
checked in
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
|
|
Reporter | |
Comment 27•23 years ago
|
||
-- Highlight rectangle waits only for a second and goes back to pane. I verified
this in current nightly build.
steps to reproduce:
1.open the above test case in mozilla.
2.open 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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
|
|
||
Comment 28•23 years ago
|
||
This has been reopned. Removing adt1.0.0+. Adding ADT2
Keywords: adt1.0.0+
Whiteboard: [ADT2]
|
|
Assignee | |
Updated•23 years ago
|
Target Milestone: mozilla0.9.9 → mozilla1.0
|
|
Assignee | |
Comment 29•23 years ago
|
||
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.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
|
||
Updated•20 years ago
|
Product: Browser → Seamonkey
|
||
Comment 31•6 years ago
|
||
Keywords: sec508
You need to log in
before you can comment on or make changes to this bug.
Description
•