Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1b3) Gecko/20090429 Firefox/3.1b3 1) Go to http://mail.google.com/mail/signup 2) Tab to the "Security Question:" combobox 3) Run accerciser - monitor all the events from the above combobox 4) Back in Firefox, press the up/down arrows to change the combobox selection No events are issued when the combobox selection changes. Note that this may be an intermittent problem. I was able to manage to do something (some odd combination of changing windows, selecting different tabs in FF, etc.) to get it to emit events, but I don't know what it was. On a related note, there doesn't appear to be any way to expand the combobox from the keyboard.

(In reply to comment #0) > On a related note, there doesn't appear to be any way to expand the combobox > from the keyboard. Did you try Alt+Down Arrow? That works for me.

Will, did you try this with the latest release build of Firefox 3.5 as well? The build ID shows that you have Beta3, which is rather outdated by now. We put in some things after beta 3 still, so it's worth testing.

(In reply to comment #1) > Did you try Alt+Down Arrow? That works for me. Yep. Doesn't work. But, I did notice that Alt+Up arrow works. Seems to wake the events up as well. (In reply to comment #2) > Will, did you try this with the latest release build of Firefox 3.5 as well? I haven't had a chance to grab it yet. I'm assuming you have it, though. :-) Can you give this a quick try?

Alt+Up or Down works for me. The latest trunk still has this bug (no event). What event are you expected? focus event for list item or menu item?

Hi Ginn: On this bug page, just below the "Additional Comments" area is a "Status" combobox. It behaves properly and issues focus events for the menu items in the combobox when you press Up/Down (i.e., the combobox is *not* popped up and you arrow up/down to select items). Here's an example debug log line from Orca: focus: detail=(0,0) app.name='Firefox' name='UNCONFIRMED' role='menu item' state='enabled focusable focused horizontal opaque selectable selected sensitive showing visible' relations='' Since Alt+{Up,Down} provide a way to access the combobox, I lowered this to orca:medium. It's still not a good bug, however. Without feedback that something has changed, a user may press Up/Down on a combobox and select things without realizing it. Many thanks for looking at this!

The nsHTMLComboboxListAccessible under nsHTMLComboboxAccessible is somehow invalid. In accerciser we can see the problematic combobox has no child or has a <dead> child. In dbx, if I force to recreate a nsHTMLComboboxListAccessible, the problem is gone. But I don't know why, and I couldn't create a test case.

Ginn, this is really weird. I looked at the markup of that combobox on the GMail signup page, and it didn't look particularly different from other comboboxes. But since this is not a problem in Firefox 3.0.11 apparently, we must have changed something that breaks it now. :(

I guess the different is it has a script to change the last option. However I didn't recreate the problem with copying the code snippet to another html file.

This bug is really interesting. The story is we get back to InvalidateChildren() for HTMLCombobox during CacheChildren() for HTMLCombobox. So the mAccChildCount is -1 (init), 0 (setting to zero in nsHTMLComboboxAccessible::CacheChildren), -1 (InvalidateChildren), 0 (++mAccChildCount at end of nsHTMLComboboxAccessible::CacheChildren) Finally, we got zero. The solution should be easy. We can change ++mAccChildCount to mAccChildCount = 1. Or we can call CacheChildren() again if mListAccessible->Init() caused InvalidateChildren(). But what about COMBO_BOX_WITH_THREE_CHILDREN, do we really need it? Here's the stack of calling InvalidateChildren() [1] nsAccessible::InvalidateChildren(this = 0xef78e640), line 549 in "nsAccessible.cpp" [2] nsAccessible::Shutdown(this = 0xef78e680), line 524 in "nsAccessible.cpp" [3] nsAccessibleWrap::Shutdown(this = 0xef78e680), line 311 in "nsAccessibleWrap.cpp" =>[4] nsDocAccessible::CacheAccessNode(this = 0xed8dd530, aUniqueID = 0xef78e680, aAccessNode = 0xef78e680), line 578 in "nsDocAccessible.cpp" [5] nsAccessNode::Init(this = 0xef78e680), line 197 in "nsAccessNode.cpp" [6] nsHTMLComboboxAccessible::CacheChildren(this = 0xef78e640), line 1038 in "nsHTMLSelectAccessible.cpp" [7] nsAccessible::GetChildCount(this = 0xef78e640, aAccChildCount = 0x80441cc), line 781 in "nsAccessible.cpp"

(In reply to comment #9) > But what about COMBO_BOX_WITH_THREE_CHILDREN, do we really need it? Practice shows we don't need it. We disabled this code a long time ago already and screen readers we work with feel good. Afaik Marco collaborate with another screen reader vendors so let ask him how much accessible our comboboxes are there.

They are very accessible the way they are now. For the Firefox 3.0 timeframe we ironed out a few problems, and since then have had no issues with comboboxes, until now...

The code has more problems than I thought. Calling mListAccessible->Init(); would always kill itself.

So once nsHTMLComboboxAccessible::InvalidateChildren is called then we'll call nsHTMLComboboxListAccessible::Init one more time for mListAccessible in nsHTMLComboboxAccessible::CacheChildren. We shouldn't call Init if mListAccessible was created already I think.

Comment on attachment 390644 [details] [diff] [review] patch Yes, this is the fix I was trying to use. Please remove all the code in #ifdef COMBO_BOX_WITH_THREE_CHILDREN. Or you can do it in another bug.

(In reply to comment #15) > (From update of attachment 390644 [details] [diff] [review]) > Yes, this is the fix I was trying to use. then it should be right fix. > Please remove all the code in #ifdef COMBO_BOX_WITH_THREE_CHILDREN. > Or you can do it in another bug. I'll file bug.

(In reply to comment #16) > > Please remove all the code in #ifdef COMBO_BOX_WITH_THREE_CHILDREN. > > Or you can do it in another bug. > > I'll file bug. bug 506616

Comment on attachment 390644 [details] [diff] [review] patch Marco is on vacation, I think it's enough to have Ginn's review only.

landed on 1.9.2 - http://hg.mozilla.org/mozilla-central/rev/6d50b269c43a

Since this is a regression from 3.0 to 3.5, we should try to land this on the 1.9.1 branch too. Surkov, any objections to requesting approval?

Marco, is this regression? Patched code wasn't changed that time range afaik.

This is a regression from 3.0.

The code was not changed. But the behavior differs if CacheChildren() is called at different time frame. Even with Firefox 3.5, it's kind of random. But it's very easy to reproduce with the certain google page.

Ok, if the bug hasn't seen in Firefox 3.0 then I think we should ask for approval. I think it's safe approach and it makes the code correct.

Comment on attachment 390644 [details] [diff] [review] patch Regression from 3.0, impacts a number of comboboxes on Linux. Safe fix.

Comment on attachment 390644 [details] [diff] [review] patch Approved for 1.9.1.4, a=dveditz for release-drivers

landed on 1.9.1 - http://hg.mozilla.org/releases/mozilla-1.9.1/rev/dfd648c2652e

Marco, could you or the reporter verify that this is fixed in the nightly 1.9.1 build from ftp://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-1.9.1/ ?

Verified fixed in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) Gecko/20090930 Shiretoko/3.5.4pre