GNOME Bugzilla – Bug 402835
In Firefox 3.0 a submenu of the bookmarks menu cannot be accessed, if speech is activated.
Last modified: 2007-10-11 02:02:22 UTC
Please describe the problem: When I try to enter a submenu of the bookmarks menu, I get bounced back to the main bookmarks menu as long as speech is activated. Turning speech off and using braille only, I can access the submenus. Steps to reproduce: 1. Open Firefox 3.0 2. Open the bookmarks menu 3. Try to access a submenu Actual results: The submenu doesn't open, you get bounced back to the bookmarks main menu. Expected results: The submenu sould be opened to select a website, stored there. Does this happen every time? It happens every time. Other information: It doesn't happen in Firefox 2.x. I use Espeak as speech output for Orca.
Thanks for logging this bug and for being a member of the Orca community. Using eSpeak as my synthesis engine, I've tried reproducing this without success. I wonder if it is related to the actual name of the submenu and/or bookmark? Alternatively, it may also be related to the way you are accessing the submenu versus how I'm doing it (I just use the arrow keys after I've pressed Alt+B to open the bookmarks menu). Are you doing anything differently? In addition, does speech go away completely, or does Orca keep speaking once you've moved past this stage? Finally, can you set your debug level to ALL in your ~/.orca/user-setting.py file, re-run Orca for the purposes of exposing the experience, then quit Orca and post the resulting debug.out file as an attachment to this bug? Here's the lines you need in user-settings.py (either uncomment the ones that are in there for you, or just add these to the end of the file): orca.debug.debugLevel = orca.debug.LEVEL_ALL orca.debug.debugFile = open('debug.out', 'w', 0)
1. I.ve tested Firefox 3.0 with Festival speech, and there were no problems. 2. I tested the same issue with Espeak again, and suddenly it works! I've no explanation for that phenomenon, except that Espeak might not be very reliable, since it must be connected via Speech-Dispatcher to Orca. 3. The whole thing is no hoax! To Will: I used several methods to access those submenus: Alt+B, arrowing down to a submenu, arrowing right to open it. And: Doing the whole procedure by pressing keys, Alt+B and the first letters of the submenus. Earlier: Nothings worked. Now: Everything works. When Orca failed, it simply bounces me back to the main bookmark menu, but kept on working.
Created attachment 81605 [details] Debugging file
Today I've retested Orca with Firefox 3 after adding the new Gnome speech server (0.4.8) together with the lastest Espeak (1.19). The bug is back. I send the debug.out as attachment.
Created attachment 81671 [details] Debug file The second debug file should show what happens, when I try to access a bookmarks submenu.
I've been able to reproduce this consistently on my Ubuntu Feisty system (with all updates until this morning -- haven't added those 116 packages in yet): Steps to reproduce: 1/ Start Orca (latest from SVN trunk/HEAD). 2/ Start Firefox (latest from nightly builds). 3/ Give Focus to Firefox and type Alt-b to bring up the bookmarks menu. 4/ Arrow down until you get to the "Ubuntu and Free Software Links" menu item, then arrow right into this menu. 5/ Arrow down until you get to the "Mozilla Firefox" menu item and try to arrow right into it. It "bounces back".
And those steps don't cause it reliably to happen for me. Rich would you mind posting a full debug.out of you performing those steps so that I can compare it with what I get when I perform them? Thanks!!!
Created attachment 83974 [details] Orca debug.out generated whilst testing this problem. Sure. Attached.
Created attachment 83982 [details] My debug.out when reproducing the steps
Thanks Rich!!! The difference seems to be in the reported role of the Mozilla Firefox submenu. if you look at Rich's beginning at line 3667, and mine beginning at line 1260, we each get an object:children-changed:add for "Mozilla Firefox". But in Rich's, Mozilla Firefox claims to be a menu item; in mine, it claims to be a menu. Then it's all downhill from there. Both Rich and I get the same series of events, namely: * object:property-change:accessible-name * object:property-change:accessible-name * object:state-changed:visible * object:state-changed:showing But in Rich's case, the event source is name=None role='invalid'; in mine it's name='Open All in Tabs' role='menu item'. My *guess* is that Open All in Tabs is a child of the Mozilla Firefox menu, but in Rich's case Mozilla Firefox is a menu item and menu items can't have children.(??) I wonder why sometimes submenus think they are menu items....
> I wonder why sometimes submenus think they are menu items.... I wonder if there is some sort of timing problem here -- maybe the object isn't a menu until it is populated. But, maybe it isn't populated until the bookmarks menu is popped up. Finally...maybe some of our machines are quicker than others and Orca is getting at the menu when it is a menu item on some machines and when it is a menu on other machines. Just a guess.
While I cannot reproduce this 100% of the time, I have been able to reproduce it a lot more frequently using Bookmarks -> Ubuntu and Free Software Links -> Mozilla Firefox and a different home/start page. (Thanks Rich!!) Two important (IMHO) observations: 1. When I am able to reproduce it, I can quit Orca (leaving Firefox running) and the problem still occurs. 2. I have been able to reproduce it on occasion immediately upon rebooting **without having first launched Orca.** Rich, can you confirm either or both of the above? I guess the next question is: If it's not an Orca thing, Is it an at-spi thing (i.e., it won't occur unless accessibility is enabled for the session) or is it purely Firefox? I'll keep trying to narrow things down.
That was easier than I thought. I went into Ubuntu's Assistive Technology Preferences dialog, disabled assistive technology, rebooted, launched Firefox, and was able to reproduce the problem immediately. This bug is not Orca, and it's not at-spi. I'm going to file a bug against Firefox.
Here's the Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=372778 While I can reproduce this issue *reasonably* reliably now, there seem to be quite a few variables that cause the bug to not be reproducible. Therefore I encourage anyone who is experiencing this problem to add themselves to the CC list of the Firefox bug and add any information you can to help the Firefox team track this down. Because this bug is independent of Orca and at-spi, I'm closing this bug as NOTGNOME.
Per Will: Reopening this and changing the summary to blocked so that we can track it.
Removing target milestone from [blocked] bugs. We have little control over them, so we're better off letting priority and severity be our guide for poking the related components.
The bug we're now tracking is this one: https://bugzilla.mozilla.org/show_bug.cgi?id=387990 The culprit seems to be the mouse pointer. If it just so happens to be resting over the submenu (any submenu) in question that submenu will collapse.
The above bug has been marked as fixed for Mozilla. I just built Firefox and confirmed that it is indeed fixed. Closing this one out as NOTGNOME.
The fix for the above bug has been reversed due to side effects. Reopening for the purpose of tracking.
The above Mozilla bug is FIXED again. Reclosing as NOTGNOME.