GNOME Bugzilla – Bug 574344
Support for different progress bar "verbosity levels" should be implemented
Last modified: 2009-08-04 06:02:01 UTC
Please describe the problem: When downloading files, either in Firefox or when downloading an update for Firefox/Thunderbird, the progress bars speak an update (as configured in the Orca Preferences-Speech tab) even though the window/dialog containing the progress bar does not have focus. This results in a very distracting speech feedback environment when you are trying to do other work. Steps to reproduce: 1. Start Orca and configure in Orca Preferences to announce progress bar updates. 2. Start Firefox and go to a web site where files can be downloaded (such as http://www.cs.utah.edu/nlp/nlpmtg.html). 3. Select a file to download and save the file to a directory of your choice. 4. Switch back to the Firefox page where you selected the file and wait for the time specified in the Orca Preferences dialog. Actual results: After the download begins and you have switched back to the web page in Firefox, you will continuously get progress updates from the download window, despite the download window not having focus. Expected results: The progress bar updates would not be spoken after focus is moved to a different window. Does this happen every time? yes. Other information: I do not know what would happen if you switched focus to a different application than Firefox--for instance, gnome-terminal. Will Walker says that the updates won't be spoken, but I haven't yet tested that. I will try to test it soon.
Created attachment 130179 [details] [review] Patch generated by Will Walker Applying this patch results in no speech updates of the progress bar, even when the download window has focus.
Created attachment 130180 [details] Debug log generated while using the patch Log starts with Firefox open. Tab key pressed to get to a link to download a file. Download completes with focus always remaining in the download window. Keyword to search for at start of process is "Schank". Tab pressed to get to the next file. This file fails to download and there is a traceback in the log. Shift tab pressed twice to get to a third file (keyword "Gorsz"). File is downloaded and focus moves to Minefield window, back to download window, to gnome-terminal, and back to download window. Basic conclusion: lots of events being generated by the progress bar, but no speech events are associated with these events.
(In reply to comment #0) > I do not know what would happen if you switched focus to a different > application than Firefox--for instance, gnome-terminal. Will Walker says that > the updates won't be spoken, but I haven't yet tested that. I will try to test > it soon. What the patch in question does is only allow the progress bar notifications to happen if the progress bar is in the active window. The new piece of code is essentially this check: self.getTopLevel(obj) == self.findActiveWindow() I thought bug #561965 was preventing this code from working well. To verify this, I ran Orca from trunk with the attached patch applied and began a download of a 5Mb file using Firefox 3.1beta2 on my OpenSolaris 2008.11 b108 machine (GNOME 2.24.2). Like David, I didn't hear the progress bar updates happen even if the download dialog had focus. But, by Alt+Tab'ing away from the downloads window to another window, and then releasing Alt+Tab to give the other window focus, and then Alt+Tab'ing again back to the downloads window, the progress bar updates started coming in. This led me to believe the bad behavior associated with this patch was an effect of bug #561965. In the debug log and from David's comments, it seems as though the Alt+Tab is not working for him. I see these relevant events in the order of the time they occur: 1) The download window is created (but not activated yet): vvvvv PROCESS OBJECT EVENT window:create vvvvv OBJECT EVENT: window:create detail=(0,0) app.name='Minefield' name='19% of 1 file - Downloads' role='frame' state='active enabled resizable sensitive showing visible' relations='' ^^^^^ PROCESS OBJECT EVENT window:create ^^^^^ 2) We get a progress bar update. Note that we never got a window activated event, so the download window is not active as far as Orca knows: vvvvv PROCESS OBJECT EVENT object:property-change:accessible-value vvvvv OBJECT EVENT: object:property-change:accessible-value detail=(0,0) app.name='Minefield' name='None' role='progress bar' state='enabled horizontal opaque sensitive showing visible' relations='' Finding top-level object for source.name= --> obj.name=Schank80.pdf 1 minute remaining — 502 KB of 2.6 MB (23.5 KB/sec) --> obj.name= --> obj.name=19% of 1 file - Downloads Script.getKnownApplications... ...Script.getKnownApplications ^^^^^ PROCESS OBJECT EVENT object:property-change:accessible-value ^^^^^ 3) We finally get the window:activate event: vvvvv PROCESS OBJECT EVENT window:activate vvvvv OBJECT EVENT: window:activate detail=(0,0) app.name='Minefield' name='19% of 1 file - Downloads' role='frame' state='active enabled resizable sensitive showing visible' relations='' ACTIVE SCRIPT: Minefield (module=orca.scripts.apps.Mozilla) (reason=window:activate event) Script mapping for Minefield is Mozilla Looking for settings at app-settings.Mozilla.py... ...found app-settings.Mozilla.py LOCUS OF FOCUS: app='Minefield' name='19% of 1 file - Downloads' role='frame' event='window:activate' GENERATOR: _getDefaultBrailleRegions obj = firefox-bin role = application GENERATOR: _getBrailleRegionsForFrame obj = 19% of 1 file - Downloads role = frame Finding top-level object for source.name=19% of 1 file - Downloads BRAILLE LINE: 'firefox-bin Application 19% of 1 file - Downloads Frame' VISIBLE: '19% of 1 file - Downloads Frame', cursor=1 default.findCommonAncestor... Finding top-level object for source.name=19% of 1 file - Downloads GENERATOR: _getSpeechForFrame obj = 19% of 1 file - Downloads role = frame already_focused = False utterances: (19% of 1 file - Downloads) (frame) SPEECH OUTPUT: '19% of 1 file - Downloads frame' ^^^^^ PROCESS OBJECT EVENT window:activate ^^^^^ 4) We get a progress bar value changed event, but we don't present anything (odd): vvvvv PROCESS OBJECT EVENT object:property-change:accessible-value vvvvv OBJECT EVENT: object:property-change:accessible-value detail=(0,0) app.name='Minefield' name='None' role='progress bar' state='enabled horizontal opaque sensitive showing visible' relations='' Finding top-level object for source.name= --> obj.name=Schank80.pdf 1 minute remaining — 502 KB of 2.6 MB (23.5 KB/sec) --> obj.name= --> obj.name=19% of 1 file - Downloads Script.getKnownApplications... ...Script.getKnownApplications ^^^^^ PROCESS OBJECT EVENT object:property-change:accessible-value ^^^^^ 5) We get a bunch more value changed events, then we get a window:activate event for some strange reason: vvvvv PROCESS OBJECT EVENT window:activate vvvvv OBJECT EVENT: window:activate detail=(0,0) app.name='Minefield' name='NLP Group Meeting Schedule -- Spring 2009 - Minefield' role='frame' state='active enabled resizable sensitive showing visible' relations='' ACTIVE SCRIPT: Minefield (module=orca.scripts.apps.Mozilla) (reason=window:activate event) Script mapping for Minefield is Mozilla Looking for settings at app-settings.Mozilla.py... ...found app-settings.Mozilla.py LOCUS OF FOCUS: app='Minefield' name='NLP Group Meeting Schedule -- Spring 2009 - Minefield' role='frame' event='window:activate' GENERATOR: _getDefaultBrailleRegions obj = firefox-bin role = application GENERATOR: _getBrailleRegionsForFrame obj = NLP Group Meeting Schedule -- Spring 2009 - Minefield role = frame Finding top-level object for source.name=NLP Group Meeting Schedule -- Spring 2009 - Minefield BRAILLE LINE: 'firefox-bin Application NLP Group Meeting Schedule -- Spring 2009 - Minefield Frame' VISIBLE: 'NLP Group Meeting Schedule -- Sp', cursor=1 default.findCommonAncestor... Finding top-level object for source.name=NLP Group Meeting Schedule -- Spring 2009 - Minefield GENERATOR: _getSpeechForFrame obj = NLP Group Meeting Schedule -- Spring 2009 - Minefield role = frame already_focused = False utterances: (NLP Group Meeting Schedule -- Spring 2009 - Minefield) (frame) SPEECH OUTPUT: 'NLP Group Meeting Schedule -- Spring 2009 - Minefield frame' ^^^^^ PROCESS OBJECT EVENT window:activate ^^^^^ 6) The screen saver kicked in (strange): vvvvv PROCESS OBJECT EVENT window:activate vvvvv OBJECT EVENT: window:activate detail=(0,0) app.name='gnome-screensaver' name='None' role='window' state='active enabled focused resizable sensitive showing visible' relations='' ACTIVE SCRIPT: gnome-screensaver (module=orca.scripts.toolkits.GAIL) (reason=window:activate event) Looking for settings at app-settings.gnome-screensaver.py... ...could not find app-settings.gnome-screensaver.py ---------> QUEUEING EVENT object:state-changed:active LOCUS OF FOCUS: app='gnome-screensaver' name='' role='window' event='window:activate' GENERATOR: _getDefaultBrailleRegions obj = gnome-screensaver role = application GENERATOR: _getBrailleRegionsForWindow obj = role = window GENERATOR: _getDefaultBrailleRegions obj = role = window BRAILLE LINE: 'gnome-screensaver Application Window' VISIBLE: 'Window', cursor=1 default.findCommonAncestor... GENERATOR: _getDefaultSpeech obj = role = window already_focused = False utterances: (window) GENERATOR: _getSpeechForWindow obj = role = window already_focused = False utterances: (window) SPEECH OUTPUT: 'window' ^^^^^ PROCESS OBJECT EVENT window:activate ^^^^^ I also see where you gave focus to gnome-terminal and went back to the Firefox download dialog. That *should* have done the trick. David, if you feel comfortable with editing code, can you try adding some debug statements just after the "if settings.enableProgressBarUpdates:" line? I'd like to know what your machine thinks the event source and top level window are? Something like the following, at the proper indent level, of course: debug.printDetails(debug.LEVEL_OFF, "FOO: ", self.getTopLevel(obj)) debug.printDetails(debug.LEVEL_OFF, "FOO: ", self.findActiveWindow()) In addition, which version of Firefox are you using?
Sorry, I forgot to give my version of Firefox. It is 3.2a1pre, latest nightly build. Also, running Intrepid fully updated and upgraded and using Orca from svn, rev. 4621. I'm not a python coder (yet), but I'll try to stick those lines in and run it again either tonight or tomorrow morning. And, as I remember it, I received a phone call at the time I started the first download--probably why the screen saver got the chance to kick in.
Created attachment 130238 [details] Debug log with additional print statements added Will, I added the print statements you requested. sillyme, I went back to download the same files (I knew they were big enough) and forgot they were cached. So I downloaded a third, which genereated the correct download dialog. Still no speech output, but there are foo entries in the log showing that Minefield is the top level application. I need to go look at the Firefox bug, but I now have direct access to dialog boxes with speech when they open in Firefox, so if it is that bug, it is in the process of being fixed in version 3.2a1pre. Let me know if there is anything else I can do. Thanks!
Thanks David! The two FOO lines are a little different (look at the state) FOO: app.name='Minefield' name='41% of 1 file - Downloads' role='frame' state='active enabled horizontal opaque resizable sensitive showing visible' relations='node child of' Script.getKnownApplications... ...Script.getKnownApplications FOO: app.name='Minefield' name='46% of 1 file - Downloads' role='frame' state='active enabled resizable sensitive showing visible' relations='' This is going to lead me to believe that the equality check for self.getTopLevel(obj) == self.findActiveWindow() is failing. I'll need to dig into this some more. It might be that the Gecko accessibility implementation has no shame about not worrying about making frames top level windows. A quick check with Accerciser would show this, but I'm on my son's iMac at the moment. If you want to try adding a debug line to output the result of the equality check, though, it would probably confirm this.
(In reply to comment #6) > If you want to try adding a debug line to output the result of the equality > check, though, it would probably confirm this. > I can see that you are trying to get me to learn python and dig through the Orca code... ;-) I added the following line just below the previous two new debug statements: debug.println(debug.LEVEL_OFF, "BAR: " + str(self.getTopLevel(obj) == self.findActiveWindow())) I'll attached the debug log.
Created attachment 130247 [details] debug log showing equality check is failing Searching for "bar:' shows that equality doesn't hold
(In reply to comment #8) > Created an attachment (id=130247) [edit] > debug log showing equality check is failing > > Searching for "bar:' shows that equality doesn't hold Yech. This might be a different FF bug. Try killing your firefox process and make sure that none exist. Then, run firefox from a command line using "GTK_MODULES= firefox" as the command. This makes sure that the GTK_MODULES environment variable is not set for the firefox process. You may still need to Alt+Tab away from and back to the Downloads window to hear the updates, though (I'm looking into that). BTW, I was hoping this would be a simple fix we could do for 2.26. But, as a result of all this bizarre interaction and dependency on bugs being fixed outside Orca, I'm going to say it's too high of a risk and we'll need to postpone to 2.28.
Created attachment 130308 [details] debug log showing that starting firefox using GTK_MODULES does not change behavior Sadly, the equality test still fails despite starting firefox using GTK_MODULES= firefox. Search for "bar:" to see results of test. If I get the chance, I'll find a copy of Firefox 3.1 and test this problem there as well. Likely tonight or tomorrow.
Created attachment 130356 [details] Debug log using Firefox (Shiretoko), v.3.1b4pre Firefox started using: GTK_MODULES= ./firefox Log starts in Firefox, the download is started, a quick switch to gnome-terminal occurs, then back to the download window. Log shows equality fails.
Created attachment 130357 [details] Debug log using Firefox 3.0.7 For completeness, I ran the same download using Firefox v.3.0.7. Firefox started using: GTK_MODULES= /usr/bin/firefox Log starts in Firefox. File download is started. Focus moved to gnome-terminal, then back to the download window. Log shows that equality fails.
Note also that we've had a user request to allow the presentation of progress bars in unfocused windows: http://mail.gnome.org/archives/orca-list/2009-March/msg00208.html
Since Will is working on braille and other issues at the moment, I'll take this one.
(In reply to comment #6) > This is going to lead me to believe that the equality check for > self.getTopLevel(obj) == self.findActiveWindow() is failing. I'll need to dig > into this some more. Hehehe. You forgot the golden rule of Gecko: Thou shalt not do an equality check because Gecko constantly (emphasis on the word constantly) kills accessibles. Still working on a patch that not only will (hopefully) deal with this Gecko "feature", but will include a setting whereby users can customize exactly when progress bars should be spoken. Stay tuned.
Created attachment 139705 [details] [review] Implement a progress bar verbosity setting This adds a new setting, progressBarVerbosity, which specifies when progres bar updates should be spoken, assuming they are enabled. ALWAYS means that any progress bar update will be spoken. APPLICATION means that progress bar updates from the active application will be spoken, even if they are not in the active window. WINDOW means that the progress bar must be contained in the active window in order to be spoken. The default verbosity level is APPLICATION, which was Orca's behavior prior to this fix. Note that at the moment, this setting is not customizable by the Orca Preferences dialog. In other words, at the moment, users will need to hand edit their user-settings.py and/or any app-settings *.py files. Important notes for users wishing to test this patch: 1. To ensure that you edit the user-settings.py file correctly, it is suggested that after applying the patch you get into the Preferences dialog and press the OK button. This will cause a new line to be added for the setting: orca.settings.progressBarVerbosity = orca.settings.PROGRESS_BAR_APPLICATION You can then remove the "APPLICATION" from the end of the setting and turn it into WINDOW or ALWAYS as you see fit. (Note the capitalization as it counts.) Then quit and restart Orca. 2. If you reverse this patch, Orca will no longer know about the setting in question and will likely throw you into the Preferences dialog the next time you start Orca. Therefore, it is recommended that you either back up your user-settings.py file or that you remove that settings line prior to reversing the patch. Anyhoo, having gotten the functionality working (and tested with Firefox and pylinted), I'm now going to see what I can do about modifying the Orca Preferences dialogs so that users don't have to deal with hand editing their user-settings.py files.
Created attachment 139716 [details] [review] add gui support - take 1 This version includes a stab at implementing gui support for changing the progress bar verbosity level. By "stab" I mean the following: As best as I can tell from my testing, it works like a charm. Aesthetically, I'm not jazzed by it.... I spent several hours playing around with various options, placements, etc. This one struck me as the best of those attempts because it minimizes the changes to the gui and sucks the least. <grin> Will, please review the code changes and make recommendations regarding the aesthetics. Thanks! BTW, just in case people have tried the previous version, note that this version changes one of the setting names *ALWAYS to *ALL to match what's in the new combo box. Adjust as needed.
Changing the summary to reflect what this bug/RFE has become.
(In reply to comment #17) > Will, please review the code changes and make recommendations regarding the > aesthetics. Thanks! Many thanks for picking this one back up. The changes look fine (and I *hope* they work). There's a test/harness/bin/progressbar and test/keystrokes/progressbar test that you might try (and update if needed). For the wording, _("Progress bar verbosity") confused me at first since I was thinking "Brief", "Verbose", etc. In addition, it's missing a trailing ":" like we tend to do elsewhere. Maybe _("Restrict progress bar updates to:")? Thanks again!
Thanks Will. I ran the progress bar regression test. No changes were needed. I committed the patch you reviewed, after having made the change in label you specified. The longer string even makes it look prettier. :-) http://git.gnome.org/cgit/orca/commit/?id=623e52e8b4595ba523976410820d79e36eabbf53 I also made the string and UI announcements. Closing as FIXED.
Reopening. I had completely forgotten about a Tab order issue. :-( Focus goes from the checkbox to the Say All combo box to the new progress bar verbosity combo box due to Gtk+ tables employing a row-then-column Tab order. Thanks and props to Jacob Schmude for catching this right away.
Created attachment 139839 [details] [review] Fix for the issue pointed out by Jacob I couldn't sleep because I was too busy kicking myself for forgetting about this Tab order issue. What this patch does, rather than explicitly change the Tab order, is create a vbox in which the progress bar hboxes live, places the vbox where the progress bar checkbox and spin button were, and then sets the beast to span two rows. It's admittedly a pathetic hack, BUT it's a pathetic hack which will require far, far, far less effort to maintain than doing a gtk.Container.set_focus_chain. Hack committed to master.