This is causing stack overflows in assistive technologies. The problem exists in the following code: http://lxr.mozilla.org/seamonkey/source/accessible/src/html/nsHTMLSelectAccessible.cpp#898 What Mozila does for a combobox or list description is forward the description for the current "focused option node". We use that awful hack for descriptions on option nodes, where we provide positional info like "3 of 5". So the idea is that the description for the combo box would be "3 of 5" if the currently focused option would be item #3 of #5. Unfortunately the code that returns the current option can fallback on returning the original combo box or list node itself, in which case when we try to forward the description from that we end up in an infinite loop. The fallback is probably happening whenever a combobox is closed.
how to reproduce this?
This was reported by Freedom Scientific and JAWS users. They said that getting the description from a combo box or listbox would reproduce it. After looking at the code, I think it's an obvious problem, but I haven't spent the time to try and duplicate the error condition.
Fixed via checkin to bug 278034.
Created attachment 251562 [details] [diff] [review] The part of the fix from bug 278034 that addresses this crash
Same patch applies 1.8.0 and 1.8 branches.
Comment on attachment 251562 [details] [diff] [review] The part of the fix from bug 278034 that addresses this crash sr=me for branch port.
Comment on attachment 251562 [details] [diff] [review] The part of the fix from bug 278034 that addresses this crash approved for 1.8/1.8.0 branches, a=dveditz for drivers Please land ASAP, we'll remove the approval after the code freeze as this is not a blocking bug.