370163 - <select> with optgroup has dead accessibles

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[parente]

Attachment: see the last selection box

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a3pre) Gecko/20070212 Minefield/3.0a3pre

1. Open the attached test page
2. Poke at the last selection box
3. Notice the structure of the children under this accessible is the following:

Numbers (accessible text: 8 embed characters)
  child 0 (dead accessible)
  child 1 (dead accessible)
  child 2 (dead accessible)
  child 3 (dead accessible)
  child 4 (dead accessible)
  child 5 (dead accessible)
  child 6 (dead accessible)
  child 7 (dead accessible)
One
Two
Three
Four
Letters (accessible text: 3 embed characters)
  child 0 (dead accessible)
  child 1 (dead accessible)
  child 2 (dead accessible)
A
B
C

It looks like the code handling group boxes was never updated for new-atk, or is some mixmatch of tree code and new-atk.

Comment 1

[Aaron Leventhal]

Are you sure this bug requires optgroup usage?

We're currently invalidating all the children every time the user changes an option in the combo box?

Comment 2

[parente]

I haven't seen this bug on a standard list box. Only on optgroup's where the contents are more tree-like than list like.

Is the second question directed at me? I'm not sure what you're asking or how I can tell.

Comment 3

[Aaron Leventhal]

The 2nd part was a statement. The ? was a typo.

Comment 4

[Aaron Leventhal]

Attachment: Remove code that tries to flatten list, fix level/setsize/posinset calculation for GetAttributesInternal()

It's not worth all the extra code to try to flatten the list. In fact, those <optgroup>'s are more like headings than they are options. They're neither focusable nor selectable.

Comment 5

[Evan Yan]

In at-poke, it shows <optgroup> have "selectable" states and the first one also has "selected" state.

Would you like to fix it as well?

Comment 6

[Aaron Leventhal]

Yes, that's easy. Do you need a new patch?

Comment 7

[Aaron Leventhal]

Actually, that should already be fixed:

NS_IMETHODIMP
nsHTMLSelectOptGroupAccessible::GetState(PRUint32 *aState, PRUint32 *aExtraState)
{
  nsresult rv = nsHTMLSelectOptionAccessible::GetState(aState, aExtraState);
  NS_ENSURE_SUCCESS(rv, rv);

  *aState &= ~(nsIAccessibleStates::STATE_FOCUSABLE |
               nsIAccessibleStates::STATE_SELECTABLE);

  return NS_OK;
}

Comment 8

[Aaron Leventhal]

Evan, that code should clear the states. When I look at it in MSAA Inspect the states are not there.

I think the ATK bridge is adding focusable and selectable for those objects. Or, where are those states getting added?

Comment 9

[Aaron Leventhal]

Evan, maybe STATE_SELECTABLE is coming from atkobject.c here? I don't know.
http://www.google.com/codesearch?hl=en&q=+ATK_IS_SELECTION+show:jfcOE2MSUWs:E8VtMY6KEdg:5p0yIlr2TiQ&sa=N&cd=5&ct=rc&cs_p=http://ftp.iasi.roedu.net/mirrors/ftp.gimp.org/gtk/v2.0/atk-1.0.3.tar.bz2&cs_f=atk-1.0.3/atk/atkobject.c#a0

Comment 10

[Aaron Leventhal]

Comment on attachment 262555 [details] [diff] [review]
Remove code that tries to flatten list, fix level/setsize/posinset calculation for GetAttributesInternal()

Oh shoot, that's why we have to keep the list flat -- the selection interface requires child offsets.

Good catch Evan.

Comment 11

[Aaron Leventhal]

Attachment: Keep list flat - WIP

Comment 12

[Aaron Leventhal]

Attachment: Keep list flat

I can't help if libatk says an <optgroup> is selectable when it isn't, unless we implement AtkSelection on the optgroup instead of the listbox itself, which be a bit unexpected.

Comment 13

[Evan Yan]

Comment on attachment 262649 [details] [diff] [review]
Keep list flat

r=me