The Minefield - Restore Previous Session dialog appears in the accessibility hierarchy in at-poke, but fires no window:activate or focus: events when tabbing between its buttons. An AT is never informed of its presence.

Tested on Windows with Mozilla 1.8 / Firefox 2 (8/22/2006) and it works.

confirmed. Alert window of Firefox do not fire activate/deactivate/focus event currently.

all the js alert dialog have this problem. and it works fine in FF2.0

not only js alert, but also all dialogs, like "about" and "add bookmark", fire no a11y events.

make GetRootAccessible() work for alert and dialog.

Comment on attachment 236063 [details] [diff] [review] patch What about Windows? It's surprising if this is the fix, as I'm seeing the same problem.

Aaron, does this bug also exist on Windows with trunk build? the patch works for me on Linux.

Comment on attachment 236063 [details] [diff] [review] patch There are 2 problems with this: 1) In the case of an embedded HTML area, the root accessible could be ROLE_DOCUMENT. 2) A ROLE_ALERT can exist anywhere in the hierachy. For example, the popup notification window is ROLE_ALERT. If you really want the root accessible a better test is to see if the accessible has a parent. If there is no parent, it's the root. At least that is true when we run in MSAA -- is it true under Linux/ATK? Or, you might have to add a method to nsIAccessible or nsIAccessibleDocument in order to get the root accessible. I think Hwaara said he needed that.

> There are 2 problems with this: > 1) In the case of an embedded HTML area, the root accessible could be > ROLE_DOCUMENT. GetRootAccessible() in nsWindow is for dispatching window:activated/deactivated events, we don't fire them for embeded HTML area, right? > 2) A ROLE_ALERT can exist anywhere in the hierachy. For example, the popup > notification window is ROLE_ALERT. > In fact, GetRole() returns ROLE_DIALOG for both of js alert and real dialogs, so only "role == nsIAccessible::ROLE_DIALOG" is needed for this bug. js alert's role is ROLE_ALERT in at-poke, I believe GetFinalRole() will return the real role - ROLE_ALERT for js alert. I added "role == nsIAccessible::ROLE_ALERT" is just for in case. It turns out I was wrong, I need to remove the comparison of ROLE_ALERT. > If you really want the root accessible a better test is to see if the > accessible has a parent. If there is no parent, it's the root. At least that is > true when we run in MSAA -- is it true under Linux/ATK? > No. Under Linux/ATK, every window is a rootAccessible, and they all have the same parent - nsAppRootAccessible, one instance for the whole application. > Or, you might have to add a method to nsIAccessible or nsIAccessibleDocument in > order to get the root accessible. I think Hwaara said he needed that. > as my commment above, GetRootAccessible would be platform-dependent, right?

> Under Linux/ATK, every window is a rootAccessible, and they all have the > same parent - nsAppRootAccessible, one instance for the whole application. Right, so would a cleaner, more sustainable test be to see if the parent is the app root accessible? So your loop would keep track of the previousParentAccessible. if parentAccessible's role == nsIAccessible::ROLE_APP_ROOT then return previousParentAccessible.

return docAcc as root accessible when its parent is app root accessible

Comment on attachment 236195 [details] [diff] [review] patch v2 I'm not sure I like using the name docAcc there. It's a bit confusing in that it's not always for a document (in the loop). Maybe choose a different name for that. You can optimize this a bit further as follows: while (PR_TRUE) { docAcc->GetParent(getter_AddRefs(parentAcc)); if (!parentAcc) { break; } parentAcc->GetRole(&role); if (role == nsIAccessible::ROLE_APP_ROOT) { NS_ADDREF(*aAccessible = docAcc); break; } docAcc = parentAcc; }