GNOME Bugzilla – Bug 122713
menu is not always reported
Last modified: 2004-12-22 21:47:04 UTC
using gnome-2.4 build from 18/09/03 -launch gnopernicus with speech enabled -enable "say all modifiers" in voice settings -launch nautilus -use cursor keys to highlight an item such as a folder -press shift-F10 to access it's context menu .you should here "switched window", and then "menu X items" .it appears with "say all modifiers" enabled, "menu X items" is not reported. -disable/enable this option and the report of "menu X items" will be present and then absent again.
What speech driver are you using? Is impossible to reproduce this bug on my computer. I am using festival.
I am currently using FreeTTS speech driver. I will try and reproduce the bug with festival.
I've tried reproducing the bug on my machine with the Festival speech driver and it does not occur. Switching back to FreeTTS, I can reproduce the bug again.
This bug is still present, and if anything it is happening even more than before. I am not sure if 'Say all modifiers' has impact or not. Can you confirm this definitely not gnopernicus before transferring to FreeTTS?
Transferring to gnopernicus.
I tried to reproduce this bug on my computer (SuSE machine, with gnome-2.5 from Feb 02 and FreeTTS), but it doesn't occur. The report of 'menu X items' is present even "Say all modifiers" checkbox is enabled or disabled. Otherwise, I tried that on my RedHat machine (with gnome-2.4 and festival) and 'menu X items' is NOT reported even this checkbox is enabled/disabled. I think this problem doesn't have anything to do with 'Say all modifiers' or with FreeTTS/Festival speech engines. In my opinion, missing of SPI_STATE_FOCUSED for that menu is responsible for that behavior. David, can you tell me please if you see the same behavior on SuSE?
Yes I do, I've been using SuSE for the past few months now and the problem has been present. I'll try again to find a more reproducible case.
Summary should be updated to "Nautilus doesn't have SPI_STATE_FOCUSED on context menus in some situations" to reflect the real problem (by someone with "sufficient power" to do so. See the top of the description for a reproducible case in which to find the Nautilus problem. Gnopernicus will not enumerate the children of an object to report the number of menu items if the object isn't focused. This is correct behavior in Gnopernicus; Nautilus needs to make these objects have SPI_STATE_FOCUSED.
I believe this bug was fixed by a change to atk on November 26th last year. I am closing as a duuplicate of bug #127400. Please reopen if the problem still occurs. *** This bug has been marked as a duplicate of 127400 ***
Peter's proposed summary does not seem to be correct. When the context menu is popped up it does have the state FOCUSED set. David reports that the problem still exists. Transferring back to gnopernicus.
with the stack from March 15th this bug cannot be reproduced. David, does this bug still occur on your computer?
Yes it does, using stack from CVS Mar 22. Using freetts speech driver also.
By stack I have meant the entire gnome stack, not the gnopernicus version. With that stack and current gnopernicus version (from CVS) this bug is not present on my computer.
Which speech driver are you using?
I am using FreeTTS.
Created attachment 26154 [details] [review] patch to check if the absence of FOCUSED state is the problem here With this patch gnopernicus will show the items from context menu even if they doesn't contain state FOCUSED.
I do not believe that Remus's patch should be necessary as I do not believe that an item from the context menu does not contain FOCUSED. Can someone show me such a testcase? It is exists it is a bug in atk or gail.
I have discussed this with David. The problem occurs with both context menus and window menus. If you pop up a window menu it is spoken correctly. If you then pop it down you hear that focus has gone back to some object in the window. If before gnopernicus has finished speaking you pop up the menu again it does not speak the number of items in the menu. If you do wait until the gnopernicus has finished speaking before popping up the menu it does speak the number of item correctly. Changed summary to better describe problem.
Created attachment 26458 [details] [review] patch to log all outputs sent to speech This patch will log all output sent to speech. That will help to see if the problem is the information sent or the speech queue logic.
Remus, Does this mean that you cannot reproduce the problem?
Yes, the problem is not reproductible on my computer.
David, can you recheck if this bug is still present using FreeTTs and with ".orbitrc" file present in "~"? (See bug 138648).
Yes, I will check this and get back to you.
I am still seeing this problem, and I have a .orbitrc file present.
Using gnome stack from March 11th I managed to reproduce this problem. I applied Remus' proposed patch on comment #19 and, running gnopernicus with GNOPERNICUS_LOG=at-spi, the outputs is: AT:818c0e8p----"window:create" for 8181630p "" role "window" from "GAIL" with details 0 and 0 AT:81800d8p----"window:deactivate" for 818bfc8p "Computer" role "frame" from "GAIL" with details 0 and 0 AT:8180138p----"window:activate" for 8181630p "" role "window" from "GAIL" with details 0 and 0 AT:8181588p----"focus:" for 81814c0p "" role "menu" from "GAIL" with details 0 and 0 <SRSOUT priority="3" preempt="false"><TEXT voice="system">create window</TEXT></SRSOUT> <SRSOUT priority="0" preempt="true"><TEXT voice="role">Menu</TEXT><TEXT voice="system">10</TEXT><TEXT voice="system">items</TEXT></SRSOUT> <SRSOUT priority="2" preempt="true"><TEXT voice="system">switch to window</TEXT></SRSOUT> So the information is sent to speech. The problem is the order of sending information to speech: the at-spi events order are received in a particular order and the appropriate information is sent to speech in a different order. We need to know when this events ('window:create' and 'window:activate' for 'window' role) are received for a pop-up menu. There are two possible ways to check this: - using a new role (Padraig, should this pop-up menus receive a different role? Somethig like 'pop-up' ...) - using the object hierarchy (check if this object has some menu-item children).
I don't think a new role is the best choice here. Can you folks (BAUM) please indicate which events are resulting in which speech (above)? We can then try to help you resolve the issue above.
The 'window:create' event is spoken <SRSOUT priority="3" preempt="false"><TEXT voice="system">create window</TEXT></SRSOUT> The 'window:activate'event is spoken <SRSOUT priority="2" preempt="true"><TEXT voice="system">switch to window</TEXT></SRSOUT> The 'focs:' event for the menu is spoken <SRSOUT priority="0" preempt="true"><TEXT voice="role">Menu</TEXT><TEXT voice="system">10</TEXT><TEXT voice="system">items </TEXT></SRSOUT>
This popup menu has ROLE_WINDOW. Gnopernicus should not report window events ('window:create', 'window:activate',...) for objects with role window. If these events are not spoken, 'Menu, X items' will be reported, so the problem is solved.
Created attachment 27141 [details] [review] Proposed patch. Are you agree with this solution ?
Patch applied to CVS head and gnome-2-6 branch.
Should I close this bug ? I believe the problem is fixed now.
Yes.