User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030206 Build Identifier: http://ftp25moz.newaol.com/pub/mozilla/accessibility/redhat7.3/2003-07-25/ If an app is listening for window events from mozilla, it will never receive such events. Reproducible: Always Steps to Reproduce: 1.start mozilla 2.start an app which is listening for "window:*" events (eg gnopernicus). 3. Actual Results: No window events ("window:*"). Expected Results: All window events (window:minimize, window:destroy, etc).

We need to make sure someone from Sun's Brower ATF team is CC'd on these bugs (are they aleady part of gnome-access-bugs?)

Bug 235719 added support for the window:activate and window:deactivate events (needed for GOK) and added the framework to support other at-spi window events, but they have not been implemented yet.

Fernando, anything to do here?

We are firing window:activate and window:deactivate events. Not for: - window:maximize - window:create - window:restore Should we?

Perhaps we should ping Joanie on this.

Interesting. I always assumed that window manager goodness was responsible for this sort of thing rather than the application or toolkit. Regardless, personally I tend towards complete implementations (rather than suggesting consumers should just listen to other events and/or determining something is not worth implementing due to lack of ping response. ;-) ). After all, even if Orca is not (currently) listening for those events, some other AT might have a need for them.

(In reply to comment #4) > We are firing window:activate and window:deactivate events. Not for: > - window:maximize > - window:create > - window:restore Fernando, so these events aren't fired for Firefox windows (by window manager per comment 6)?

I'm not seeing these events. And for what it's worth, I wasn't saying that the window manager did this; merely that I assumed it did. I am often wrong. ;-)

not so often :) ok, then we should fire them, nsWindow should be suitable place for that if we can get accessible for window.

No, is the toolkit implementation the one that should fire these events. What gail does is to listen for gtk "window-state-event" and then firing window:maximize / window:minimize / window:restore / window:create / window:destroy

This patch fires maximize/restore/minimize events for native windows that we block gail implementation (toplevel windows). Other native windows (print dialog, open file dialog, etc...) should get them fired by gail. We are still missing the create/destroy events.

Notice that for our toplevel windows, we have gail listeners, but they are not doing anything because they check for object type to be GTK_WINDOW / GAIL_WINDOW type.

Comment on attachment 518680 [details] [diff] [review] Wip for sending missing window events >+ nsRootAccessible *rootAcc = >+ static_cast<nsRootAccessible *>(accessible); >+ rootAcc->mActivated = PR_FALSE; these lines are wrong, coming from a copy & paste error. Just ignore them

This patch includes create and destroy signals for toplevel windows. However I cannot see the event "window:destroy" coming from the at-spi registry, event if the bridge is sending it correctly. Actually, I cannot see any "window:destroy" event from any gtk application so it could be an at-spi registry bug.

> Actually, I cannot see > any "window:destroy" event from any gtk application so it could be an at-spi > registry bug. No, it was properly propagated, but a bug on pyatspi prevented my event log application from catching it: https://bugzilla.gnome.org/show_bug.cgi?id=644492