Steps to reproduce: 1. Move focus to the location bar 2. Shift+Tab once to the identity information button 3. Press Space to display the information in an alert 4. Press Escape 5. Repeat the above steps The first time the alert appears, an object:children-changed:add event is issued for the frame. The event's any_data contains the accessible alert. After this point, re-displaying the alert causes an object:state-changed:showing event and an object:state-changed:visible event to be emitted. However, these events are not for an accessible of ROLE_ALERT; instead they are for an object of ROLE_WINDOW which claims to have no name, no parent, and only one child: which Accerciser calls simply "redundant object". To be honest, it's not clear to me what this object of ROLE_WINDOW is, but it doesn't seem to be the alert. Whenever the alert appears object:state-changed:showing and object:state-changed:visible for the alert should be issued. Thanks!

WFM on Windows, so seems to be an ATK-specific issue. Joanie, what events do you get when the alert goes away after pressing ESCAPE?

object:state-changed:showing with detail1 == 0 for the mystery object of ROLE_WINDOW. And then the focus: and object:state-changed:focused events for the location bar.

What about ARIA alerts in content? <div role="alert">Your password is incorrect</div>

Sorry, that comment was meant for the Orca alert bug.

Confirmed. Actually the object:state-changed:showing and object:state-changed:visible events are fired by libgail for gtk_widget_show(). That's not good, I think.

Fernando, can you check it please?

Confirmed with trunk. First time the alert is displayed I get: object:property-change:accessible-name - 0,0,Google - Minefield [frame | Google - Minefield] object:property-change:accessible-parent - 0,0,[frame | Google - Minefield] [alert | ] object:children-changed:add:system - 8,0,[alert | ] [frame | Google - Minefield] object:bounds-changed - 0,0,<Accessibility.BoundingBox object at 0x9dd282c> [window | ] object:property-change:accessible-name - 0,0,More Information… [push button | More Information…] object:property-change:accessible-parent - 0,0,[alert | ] [push button | More Information…] focus: - 0,0,None [push button | More Information…] object:state-changed:focused - 1,0,None [push button | More Information…] and the second time: object:bounds-changed - 0,0,<Accessibility.BoundingBox object at 0x9dd2a0c> [window | ] object:state-changed:showing - 1,0,None [window | ] object:state-changed:visible - 1,0,None [window | ] object:state-changed:iconified - 0,0,None [window | ] object:text-changed:delete - 0,50,Your connection to this web site is not encrypted. [label | ] object:text-changed:insert:system - 0,50,Your connection to this web site is not encrypted. [label | ] focus: - 0,0,None [push button | More Information…] object:state-changed:focused - 1,0,None [push button | More Information…]

This is a native window created with nsWindow::Create, and object:state-changed:showing comes from nsWindow::Show calling gtk_widget_show. It looks like we are failing at nsWindow::CreateRootAccessible, but anyway we are not using it.

A temporal solution would be mapping EVENT_ALERT to Atk showing/visible notifications, so we would get them for the proper accessible. However we would get duplicated showing/visible events from the native nsWindow (wrong accessible, as it was created by gail and it is not in our tree) and we would miss show hide.

Trevor, is this still valid? And if so, do you have an idea how to move forward on it? Fernando is no longer available to look at this I believe.

Comment on attachment 8795408 [details] [diff] [review] make the site identity popup have an alert role Can you explain why this is necessary? Why does it work the first time and not the second time? AIUI the alert role will mean it will be announced when shown programmatically (without user interaction) as well. Do we want that?

(In reply to :Gijs Kruitbosch from comment #12) > Comment on attachment 8795408 [details] [diff] [review] > make the site identity popup have an alert role > > Can you explain why this is necessary? Why does it work the first time and > not the second time? I cannot explain why it worked the first time and not the second time. But the behavior has changed: It always has ROLE_PANEL. When generic containers claim to be showing but don't claim focus (which happens fairly often in many applications), Orca by default doesn't present them because 9 times out of 10 is accessibility-event noise and not an alert-like thing or a door hanger. > AIUI the alert role will mean it will be announced when shown > programmatically (without user interaction) as well. Do we want that? That's exactly what we want. You (Mozilla devs) did this for other doorhangers which don't claim focus but which should be presented to the user (like the remember-password one). As a result, Orca now presents those doorhangers. If this doorhanger gets ROLE_ALERT, Orca will present it. If memory serves me, on Windows there is some sort of "alert" accessibility event which can (and is?) being used so that Windows screen readers can present the doorhanger content. I don't have such an event on my platform; but I do have object:state-changed:showing. So that plus ROLE_ALERT was the agreed-upon workaround we came up with last time I was in Toronto for a meetup.

(In reply to Joanmarie Diggs from comment #13) > > AIUI the alert role will mean it will be announced when shown > > programmatically (without user interaction) as well. Do we want that? > > That's exactly what we want. You (Mozilla devs) did this for other > doorhangers which don't claim focus but which should be presented to the > user (like the remember-password one). As a result, Orca now presents those > doorhangers. If this doorhanger gets ROLE_ALERT, Orca will present it. The problem I'm trying to highlight is that this popup is, to the best of my knowledge, never shown without user interaction. So I don't see why that's necessary. This isn't an alert that pops up out of the blue, it's more like a menu or dropdown that shows up specifically because of user interaction. Presumably menus and <select> dropdowns don't get an alert role? Or, say, the main menupanel (on the hamburger/3-lines button) - that seems to have role=group - or the downloads panel? What does Orca do for those? It's fine if this is necessary, I would just like to understand better why that is the case (and if we need to do it elsewhere)

(In reply to :Gijs Kruitbosch from comment #14) > (In reply to Joanmarie Diggs from comment #13) > > > AIUI the alert role will mean it will be announced when shown > > > programmatically (without user interaction) as well. Do we want that? > > > > That's exactly what we want. You (Mozilla devs) did this for other > > doorhangers which don't claim focus but which should be presented to the > > user (like the remember-password one). As a result, Orca now presents those > > doorhangers. If this doorhanger gets ROLE_ALERT, Orca will present it. > > The problem I'm trying to highlight is that this popup is, to the best of my > knowledge, never shown without user interaction. So I don't see why that's > necessary. This isn't an alert that pops up out of the blue, it's more like > a menu or dropdown that shows up specifically because of user interaction. > Presumably menus and <select> dropdowns don't get an alert role? Or, say, > the main menupanel (on the hamburger/3-lines button) - that seems to have > role=group - or the downloads panel? What does Orca do for those? It seems to me the difference is that all those other things get focused, but this panel doesn't.

(In reply to :Gijs Kruitbosch from comment #14) > Presumably menus and <select> dropdowns don't get an alert role? Correct. And Orca doesn't present the menus and <select> dropdowns **when they emit object:state-changed:showing.** Instead, the menus and dropdowns emit events like object:selection-changed or object:active-descendant-changed. And the menu items therein emit events like object:state-changed:focused and/or object:state-changed:selected. When the selected/focused menu item changes, Orca trusts that the user is in the parent menu and presents the newly-selected/newly-focused menu item. There is one exception to the above: Sometimes a collapsed combobox and/or its descendants will emit selection-change-related events even when the user is not in it. For instance, in a form, if I change my country from U.S. to Spain, a state/region combobox elsewhere in the form might change from displaying "Georgia" to displaying "Galicia." There may be other such comboboxes. Because the user is not in those other comboboxes, and because the change was automatic (though arguably triggered as a direct result of user interaction), those selection changes should not be presented. Therefore, Orca does some additional sanity checking for selection changes in comboboxes: If the combobox is not the "locus of focus" (aka what Orca believes the users is on/in based on previous focus/selection-related events) AND if the combo box is lacks STATE_FOCUSED, then Orca concludes the selection-change is "noise" which should not be presented at this time. Getting back to this doorhanger, the problems are: 1. It has my platform's most generic role ever: ROLE_PANEL. ROLE_PANEL is the role which gets automatically assigned by Gtk for want of a proper, specific role. It also gets deliberately assigned to GtkContainer and similar things. Panels in and of themselves are not interactive and often not worthy of presentation even when their contents are. 2. It doesn't claim focus, nor do its descendants, and it's not the "locus of focus". 3. There's no definitive way to connect it to being BOTH a) something which appeared because the user asked it to appear (see note below) b) Something whose content is worthy of presentation (see note below). In other words, a generic object has declared sighted users can see it now. How am I supposed to know, programmatically, that this is a popup containing the information asked for by the user? Notes: Regarding 3.a), there are a bazillion object:state-changed:showing events which get emitted by applications as the result of user interaction: * If you down arrow in a mail client, or delete a message, panels with header information might go away and be replaced with panels with new information. The panel which contains the message text might also get replaced. If the user pressed down arrow or delete as the first of a series of down arrows/deletions en route to the message of interest, those interim newly-showing panels are irrelevant and users would complain if the screen reader presented them. * In the case of applications whose menu bars are disabled by default, getting into a menu might cause both the menu bar and some other toolbars to appear. Toolbar widgets are typically contained in panels, and when a toolbar is suddenly shown, its panel descendants will emit object:state-changed:showing. If a screen reader spewed the contents of all those panels out, users would complain. * If you're in an editor and move into a table, that application might add/show table-related widgets (which live in panels). Should the screen reader present "merge cell, split cell, insert row above, insert row below, ...."? If it did, users would complain. These are all examples of panels which claim to be showing as a direct result of user interaction. I hope you would agree that these panels and their contents should not be presented -- unless they also claim focus or emit some other event beyond "I can now be seen." Regarding 3.b) Some things which are not the "locus of focus" and which do not claim focus might still be worthy of presentation to the user. Incoming chat messages, certain application-context-specific status bar content changes, notifications, etc. Those get handled on a case-by-case basis, and handling them correctly requires some means to reliably identify that this non-focused thing should be presented to the user. In other words, I/Orca needs a hint (like a non-generic role, bonus points for a non-generic role which is used for content which should be presented to the user even if it doesn't claim focus). Or the doorhanger (or one of its descendants) needs to claim focus. > Or, say, > the main menupanel (on the hamburger/3-lines button) - that seems to have > role=group - or the downloads panel? What does Orca do for those? Don't those claim focus? If they do (or if one of their descendants does) it passes the test of presentation worthy. > It's fine if this is necessary, I would just like to understand better why > that is the case (and if we need to do it elsewhere) I hope I did better this time. :) If not, feel free to re-NEEDINFO me

The confusion for me here is that in bug 990045 and friends we explicitly avoided focusing similar doorhangers, mostly because they can pop up willy-nilly and stealing focus is evil Here we're doing the opposite, but the doorhanger is explicitly opened by the user and so it actually seems reasonable to autofocus, as far as I'm concerned. So the simplest solution might just be to remove noautofocus or whatever it is that isn't focusing these dialogs to begin with. IIRC there were issues with autofocus and this panel. Panos or Tim , do you remember and/or do you know if we can just autofocus this popup (bug 1182643 and friends, I think?) ? Alternatively, IIRC there is manual "move the focus" code for this popup right now. The STR and summary make me suspect that it somehow works the first time but not the second time, so maybe that code is just buggy?

(In reply to :Gijs Kruitbosch from comment #17) > The confusion for me here is that in bug 990045 and friends we explicitly > avoided focusing similar doorhangers, mostly because they can pop up > willy-nilly and stealing focus is evil > > Here we're doing the opposite, but the doorhanger is explicitly opened by > the user and so it actually seems reasonable to autofocus, as far as I'm heh, that was my first reaction, but Joanie assumed there was a reason it wasn't focused and convinced me to do the role thing. So I'm a tad amused there doesn't really seem to be a reason. > concerned. So the simplest solution might just be to remove noautofocus or > whatever it is that isn't focusing these dialogs to begin with. > > IIRC there were issues with autofocus and this panel. Panos or Tim , do you > remember and/or do you know if we can just autofocus this popup (bug 1182643 > and friends, I think?) ? Alternatively, IIRC there is manual "move the > focus" code for this popup right now. The STR and summary make me suspect > that it somehow works the first time but not the second time, so maybe that > code is just buggy? fwiw for me the behavior the first and second time seems to be the same.

I don't know why the identity panel doesn't receive focus, but maybe Paolo does. It does seem reasonable to me to do so since as you say it only appears as a result of user interaction.

I'm not sure why the accessibility behavior would be different the first time the panel is opened, and I'm not too familiar with the accessibility APIs so I can't be of much help. Keyboard focus works consistently - pressing TAB after the panel is shown goes to the subview button, if present. The only thing that we do differently the first time is that we remove the "hidden" attribute: https://dxr.mozilla.org/mozilla-central/rev/90d8afaddf9150853b0b68b35b30c1e54a8683e7/browser/base/content/browser.js#7321-7323 There is some code right after that to handle the case where the panel loses focus, but we listen to the same events every time the panel is shown.

So if the doorhanger doesn't have noautofocus and there's no custom code that does this, why isn't the panel focused when opened? Neil?

What in the panel are you expecting to be focused? Panels themselves are not focusable elements.

(In reply to Joanmarie Diggs from comment #16) > Getting back to this doorhanger, the problems are: > 2. It doesn't claim focus, nor do its descendants, and it's not the "locus > of focus". (In reply to Neil Deakin from comment #22) > What in the panel are you expecting to be focused? Panels themselves are not > focusable elements. I'm guessing Trevor knows the answer to this question.

> I'm guessing Trevor knows the answer to this question. I'll forward that to Joanie.