look like misspelling in FlushPendingEvents. This patch possibly will fix 428240, at least it should help. Marco, could you check?

(In reply to comment #0) > This patch possibly will fix 428240, at least it should help. Marco, could you > check? Looks very good so far! Haven't managed to break it on three separate Thunderbird launches. Regardless of how many folders in imap or newsgroup accounts I navigate to, it appears to always get the headers correctly with this one in. Obviously it only shows its full beauty if patch for bug 427841 is also applied, or the folder contents won't update.

the bug 413777 started this behaviour it seems to me. So since it's regression then do we have any chance to get this in? Marco, could you set all flags for this because I started to be lost with all of them :)

Alexander, can you give a more detailed explanation of what the problem is? Also, does the patch in this bug cause bug 413777 to reappear? What are the risks and benefits to Firefox?

In other words, To nominate this for blocking the Firefox 3 release, I need a real-world scenario, a high-impact web site, that also exhibits this problem, not just a couple of column header accessibles in tree tables that are used in Thunderbird. For that, I already nominated the bug for inclusion as soon as we know what Gecko release Thunderbird will use. So if you think this is blocking Firefox 3, please provide a testcase that clearly illustrates what the impact on users will be if we don't get this in. Thanks!

Willie, can you give us any input here? Basically we're not firing a show event on certain root objects such as column headers in tree tables, and possibly others. Do you know off-hand where Orca might rely on this and if this blocks any major website usage?

I took a look at this. My characterization of the problem is this: a treecol accessible isn't firing a object:state-changed:showing event. The question is does Orca care? If the problem statement is correct, I think the answer to "does Orca care" is "no". Orca looks for object:state-changed:showing events to handle some interesting cases, but I don't think the treecol thing falls under those special cases. The special cases include PANELS, LABELS, TOOLTIPS, STATUSBAR (metacity), WINDOW (Gecko and autocompletes), but I don't see treecol in the code. In general, however, when we look at an object, we do care if its SHOWING state is set correctly. In IRC with Marco, I think we determined this state is being set. So...all seems OK for at least the event side of things. However... In IRC, Marco also noted that this patch seems to fix a more serious problem, which is that of a stale/broken hierarchy. These kinds of things are very very bad and detrimental to assistive technologies and I'd view that as a show stopper.

Comment on attachment 321197 [details] [diff] [review] patch Requesting approval since this was really a bad miss-out from review for bug 413777. The wrong parenthesis mean that an event show is currently never fired even when it should.

Based on the last paragraph of Comment #6, requesting permission to include in RC2.

Comment on attachment 321197 [details] [diff] [review] patch a=beltzner, please land asap on cvs

(test coverage _ASAP_, please)

mozilla/accessible/src/base/nsDocAccessible.cpp 1.244

Verified fixed using ChatZilla 0.9.82.1 and Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9) Gecko/2008052906 Firefox/3.0