412931 - Tabs not exposed unless 3 of them

Status: VERIFIED FIXED

(Core :: Disability Access APIs, defect)

Description

[Steve Lee]

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.

Comment 1

[Aaron Leventhal]

Marco, can you confirm?

Comment 2

[Steve Lee]

Attachment: python to prints page tabs

Marco, hope this helps, it prints the number of tabs and their names or an error message.

run as 'python test.py'

Comment 4

[Ginn Chen]

Not reproducible on my box.

Comment 5

[Marco Zehe (:MarcoZ)]

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.

Comment 6

[Marco Zehe (:MarcoZ)]

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.

Comment 7

[Aaron Leventhal]

Marco, were you able to duplicate this on Windows?

Comment 8

[Marco Zehe (:MarcoZ)]

(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.

Comment 9

[Mike Beltzner [:beltzner, not reading bugmail]]

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

Comment 10

[Aaron Leventhal]

Attachment: Easy fix, but I need to investigate why 1st parent invalidatation for DOM_CREATE didn't take

Comment 11

[Marco Zehe (:MarcoZ)]

(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?

Comment 12

[Aaron Leventhal]

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.

Comment 13

[Mike Beltzner [:beltzner, not reading bugmail]]

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

Comment 14

[Aaron Leventhal]

Attachment: 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

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 15

[alexander :surkov (:asurkov)]

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?

Comment 16

[Aaron Leventhal]

> 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.

Comment 17

[Marco Zehe (:MarcoZ)]

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.

Comment 18

[Aaron Leventhal]

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

Comment 19

[alexander :surkov (:asurkov)]

(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 :)

Comment 20

[Aaron Leventhal]

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.

Comment 21

[Marco Zehe (:MarcoZ)]

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