GNOME Bugzilla – Bug 407663
Support the "Find" operation in Firefox better
Last modified: 2008-07-22 19:27:16 UTC
Via Ctrl+F and Ctrl+G, Firefox provides a means to quickly search web content for text. The interface to this is not well supported by Orca.
Unfortunately, there seem to be a number of problems in Firefox that prevent us from providing better support. I've filed bugs at mozilla.org. In particular: 1. at-spi events for matching text are not generated when using Find toolbar https://bugzilla.mozilla.org/show_bug.cgi?id=371273 2. at-spi events not generated for the Phrase Not Found label on Find toolbar https://bugzilla.mozilla.org/show_bug.cgi?id=371279 The first is critical because text is being matched and highlighted, the document frame scrolls, etc., and we're not being notified at all. The second is less critical. Still, it would be nice to be able to inform the user when the text typed cannot be found in the document. In addition, I filed a third: In Find toolbar, all buttons should be in Tab order https://bugzilla.mozilla.org/show_bug.cgi?id=371276 While the user can use keyboard shortcuts for the Find toolbar's push buttons, vision is required to identify what letter should be pressed with Alt. This bug is blocked until the Firefox folks fix things on their end. Adjusting the summary to reflect that.
Created attachment 87173 [details] [review] The first of undoubtedly lots of patches :-) Here's the latest scoop on all of the Find issues: 1. Most of the controls in the Find tool bar still are not in the Tab order 2. We still don't get any events when searching to indicate that the caret is moving 3. We still don't get any events when searching to indicate that text is being selected 4. We still don't get any events after searching and returning to the document frame to indicate that that the caret has moved. BUT on a happy note getNSelections() no longer returns 0 when text is selected. So.... This patch does the following: If the locus of focus has changed from an entry on a toolbar to the document frame, we should see if something somewhere is selected. If something is, we begin the long, arduous journey to find that thing. :-) The trouble is that without a caret moved event, we think we're in the same place we were before the search. text.getSelection() only gives you the proper offsets if the selection is in the object you specify. If that's not where we happen to be, and we have no way of knowing where it might be.... Most of the time I do not think we are going to see too much of a performance hit. However, if the document is made up of lots of small objects, and we're near the top of the document, and the match happens to be before us rather than after of us, what we wind up doing is searching the remainder of the document, realizing it's not there, going back to our original location, and searching upwards. When we do this, the delay can be painful. As an example, search on this page for the word "normal" to locate the line that contains "priority: normal". Should be okay. Then repeat to find "severity: normal". This, too, should be okay. Then do another search for normal to return to the "priority: normal" line. Notice how long it takes from the time you press Escape to the time Orca speaks and brailles the results. :-( The good news is that this delay seems to be more the exception than the rule. <shrugs> I have commented on the relevant Firefox bug that a caret-moved event would be very much appreciated. In the meantime, let me know what you think.
Created attachment 87174 [details] [review] minor adjustment to not be so chatty when the matched text is a link When the matched text is a link, it's not selected (in the highlighted sense of the word). I wasn't catching that case in the first version, so we were speaking far more of the hierarchy than we should. This version takes care of that. The question is: In the case of a link being the match, what should be spoken? Right now it's the current line, just like any other match. Should it just be the link? Mike?
On the Firefox bug related to the lack of events when using the Find toolbar, Aaron commented: > I should be able to post a patch this week for this. What that occurs, I'll clean up the above patch to be much more efficient and <fingers crossed> provide access to the changing contents of the screen while the user is still in the Find toolbar.
Created attachment 87963 [details] [review] Proposed patch Mike and I talked a bit yesterday about how to proceed on this one. He and I agreed that first and foremost we need to handle the new events that are causing us to update the locusOfFocus to the document frame when we're really in the Find toolbar. We also agreed that providing full support for the Find toolbar, including providing access to the changing/scrolling contents of the screen was a lot to think about: How much do we speak? When? Etc. Mike said he'd give it some thought and spec things out. Then insomnia kicked in and things just kept seeming to click and, well, I came up with what seems (to me) to be a fully-functioning solution that not only solves the events issue and provides basic support (i.e. press Escape and find out where you've landed), but also includes access to the changing contents of the screen and app-unique preferences to address the needs of our various users.... :-) But I'm not the UI guy of course. So here is my proposal: Mike, please consider this as a proof-of-concept and basis from which to write the spec. I think by actually having something functioning to tinker with, you'll be able to more quickly identify what you like, what you want, and what sucks. <grin> Feel free to tell me it all sucks. The bulk of what I did last night/this morning is the figuring out of events, where and how we needed to handle things, what Firefox bugs still exist that need addressing, and so on. Even if you completely change the user interaction, that work and code will still be needed and is in place. UI changes to what I've done, even significant ones, should hopefully be cake at this point. With that in mind.... There are a couple of ways users can approach using the Find toolbar: 1. Press Control+F, type a bit, then press Escape to return to the document frame and figure out where they've landed, repeating as necessary. 2. Press Control+F, type a bit, then press Enter/Alt+N for the next matching item or Alt+P for the previous matching item. For the first use, I figured that when the user pressed Escape, Orca should speak the new line that received focus. It's the second use that is tougher. Here's what I'm thinking for it: 1. Each time a new line appears with the match, hearing that line is helpful so that you know exactly where you are without having to return to the document frame -- but some users might not want that: Too chatty. 2. When you type and Orca tells you the newly selected text (in this case a line), you stand a good chance of continuing to type before you can react to the announcement. Therefore, similar to what we do for autocompletes (e.g. in the run application dialog), we should continue to speak as the user types so that he/she will have a "second chance" to find out what line they are on without having to return to the document frame. Of course, this too might bug some users as being "too chatty." 3. We need to determine at what point we start speaking these things. If the user types an "x" and there's not an "x" on the current line, they'll be moved to a different line. But they've only typed one character so while technically it's a match, it's not *really* a match. Or is it? Is it a match after 2 characters? 3? Not until 10? Depends on the user. From these observations, I came up with three user settings related to find toolbar support: 1. Speak results during find. If checked, we provide access to the changing updates on the screen. If not checked, we sit very quietly until the user presses Escape to return to the document frame, at which point we speak the line. 2. Only speak changed lines during find. This is the setting that's analogous to what we do with autocompletes. If checked, we won't keep announcing the same line over and over, but the user might miss out on the new match. If unchecked, the behavior is the same as what we do in autocompletes. 3. Minimum length of matched text. This is a spinbutton. The user can select the point at which whatever line announcements they chose get made. For instance, if you pick "4", typing "the" could easily jump you off to some other line. We won't speak it though. When the "n" is added on to make the query "then", we'll speak the line with the selection. All of these have been added to the Minefield pane of the app specific settings dialog box and seem to work. As for Firefox bugs. This may be a long-standing issue that I wasn't aware of, or it may be the Law of Conservation Of Events in action, but we do not get events when text is inserted in, or deleted from, the Find entry. We do not get caret moved events from the Find entry. We might not be able to see the text in the Find entry. but on that I'm not yet sure. The Find toolbar does not have a name. I'll research this stuff further. Let me know what you think about all this Mike. It would be cool to get this in for 2.19.3 (I think), and I bet we can once we have the official UI spec. Thanks much!
Created attachment 88034 [details] [review] new patch to be compatible with other changes to Gecko.py No new functionality added. The previous patch was failing because of other changes made to Gecko.py in the past couple of days.
Hi Joanie, I've just given this a bunch of testing and overall I really like it. I wasn't sure if the extra information given while typing would be distracting or not but for me it doesn't seem to be. One question however: Does the find edit field have a lavel? It would be more useful if firefox presented something suchh as "find edit" instead of just edit when you pressed control+f. Other than that I think this is quite nice.
Wow... Cool. Thanks!! The find entry doesn't have a label. However the find entry has a label next to it. <grin> My plan was to look at the remaining open Firefox bugs related to the Find toolbar -- there are several -- and either add the need for a label as a comment, or file a new bug. In the meantime, I could probably hack around that. Maybe get the label guess stuff to handle entries on toolbars as well as document content.... I'll add that to the next version of the label guess patch. So.... Where do things stand with this? I need to add some notes for translators for the new settings. Other than that, should I check it in? I do want to write something up for the users like Rich did for the app-specific settings feature. I send that to y'all when it's written. Thanks again!
> > So.... Where do things stand with this? I need to add some notes for > translators for the new settings. Other than that, should I check it in? I do > want to write something up for the users like Rich did for the app-specific > settings feature. I send that to y'all when it's written. I'm all in favor of checking the patch in.
Created attachment 88044 [details] [review] i18n compliance, set label relation for spin button I was chatting with Will and he indicated the patch was good with the exception of the i18n issues: 1. Add translator notes for strings 2. use substitution rather than have formatting stuff like <b></b> in the string to be translated In addition, I had forgotten to set the spin button's functional label as its actual label. This is fixed as well. I will be committing this patch.
Patch committed. Updating the status to pending.
For the purpose of documentation: In the 14th May build of Firefox, the following additional find-related fixes were made by Aaron et al.: * The Find label now has a label_for relationship to the entry. As a result, we automatically say "find" when focus moves to that entry, rather than merely "text". * All of the items in the Find toolbar are now in the Tab order. * The wayward events from the Find entry (alluded to towards the end of comment #5) have come back. Woo hoo! :-)
I'm quite happy with this fix.
Okay, then I will close this out as FIXED then. Thanks!