User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2008011704 Minefield/3.0b3pre Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2008011704 Minefield/3.0b3pre The ROLE_PAGE_TAB_LIST for the web page tabs does not appear unless there are 3 tabs. In addition the child change events are not always generated as tabs come and go Reproducible: Always Steps to Reproduce: 1.setup minefield with a single page open (no tabs) 2. use accerciser to look for page tab (hint ctrl-alt-? or browse 0.16.2) 3. Opne and tab a look again 4 open a tab and look again 5. close the tab and look again 6 refresh accerciser and look again Actual Results: The tab list and tabs only appear when third tab opened Accerciser does not know the tab is closed. Expected Results: Tabs always correctly exposed in a11y as well as events raised.

Marco, can you confirm?

Marco, hope this helps, it prints the number of tabs and their names or an error message. run as 'python test.py'

Not reproducible on my box.

The regression range is http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-01-11+05%3A00&maxdate=2008-01-12+05%3A30&cvsroot=%2Fcvsroot. a11y bugs were bug 408997, and bug 411737. There was also an XForms-related checkin related to bug 280423, but I am not sure that applies here.

In addition, the behaviour has changed in the meantime: Only the inactive tab is now exposed. So, if I have 2 tabs open, and am on tab 2, only tab 1 is now exposed, but tab 2 isn't.

Marco, were you able to duplicate this on Windows?

(In reply to comment #7) > Marco, were you able to duplicate this on Windows? Yes! If you look at the hierarchy in AccExplorer, you'll see that the active tab is missing from the tabs node under the nameless grouping node. In the January 12 and successive builds, the tabs node and its children were missing alltogether.

Aaron: how serious is this in terms of a regression over b2? does it make the beta entirely useless for accessibility testing? Just wondering if it can wait for beta4

(In reply to comment #10) > Created an attachment (id=300643) [details] > Easy fix, but I need to investigate why 1st parent invalidatation for > DOM_CREATE didn't take Doesn't this revert part of the fix for bug 408997, and would thus reintroduce that problem?

It was an optimization that's being removed, so no. But I still am investigating because I don't understand why we need to remove that optimization.

Moving out to beta4, feel free to renom if you disagree.

This may fix other problems as well. It's a flaw in our logic that we've had ever since we added the eCoalesceFromSameSubtree capability to simplify the events we fire.

Comment on attachment 300779 [details] [diff] [review] Asynch show events are removed from the queue when an ancestor is also shown, in order to avoid redundancy. However, we still need to invalidate children in the parents of the shown nodes for those re >+ if (eventType == nsIAccessibleEvent::EVENT_ASYNCH_SHOW) { >+ if (accessible) { Is it possible accessible is null?

> Is it possible accessible is null? Yes, absolutely. We fire the delayed event for a dom node, which could be any kind of node like a span etc. When there is no node we will end up calling FireShowHideEvents() which will recurse back here for each first line accessible in that inaccessible node's subtree.

I ran with this patch most of the day, and consider it to be solid. If we get review from Alexander I'd like to request approval for beta 3.

I'm not sure if Surkov watches you so we need to CC him 1st.

(In reply to comment #18) > I'm not sure if Surkov watches you so we need to CC him 1st. > I'm watching for you :)

Marco ran with this all day and wants to get it in. This fixes a cache corruption bug -- the type of bug that leads to instability.

Verified using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b3) Gecko/2008020514 Firefox/3.0b3