This proposal came from a discussion a bunch of us (asa, ben, brendan, bryner, chofmann, dbaron, mscott) had at the Foundation, but I've filled in a some additional details that we didn't discuss, but also left a bunch of questions. The goal is to combine the efficiency of TAF with the discoverability of the Find dialog and make the whole thing easier to use. The basic proposal is that type-ahead-find would occur in a new toolbar that would drop down (logically in the style of a Mac OS X sheet, but visually just the bottommost browser toolbar). When the toolbar is shown, it is always the thing in the browser window that has focus -- anything that would cause it to lose focus to anything else in the browser window other than a menu should cause it to go away. This toolbar would show roughly what TAF currently shows in the status bar, along with some buttons (probably with hotkey labels, although that seems a bit awkward). Regular TAF (the no-"/" version) could continue to exist for links only as an accessibility feature. This toolbar would appear, with the textfield blank, and take focus, when any of the following things occur: * The user presses "/" (perhaps to be discontinued after a bit) * The user presses Modifier-F (Modifier == Appropriate platform modifier) * The user selects Edit | Find in this page... It would appear, with the textfield filled in with the previous search and simultaneously find the next occurence of the previous search, when any of the following things occur: * The user presses Modifier-G. * The user selects Edit | Find again (ISSUE: Is this really what we want "Find again" to do? Do we still want the menuitem?) While the toolbar is shown and contains text (when it is shown, it is always the thing in the browser window with focus), any of the following will also cause a "Find Again": * The user presses Modifier-G. * The user selects Edit | Find again * The user presses Enter for more than the first time (unless we use Enter to dismiss the toolbar). As the user types in the toolbar, the text would appear in the toolbar's text field and roughly the current typeahead find behavior would occur in the browser, highlighting the first occurrence of the matched text as a secondary selection. However, characters typed that do not match should appear in the toolbar (unlike now), along with a beep indicating there is no match (as now). This allows the user to delete typos without becoming confused. Future enhancement (hard): highlight the matching part of the text typed in the FastFind toolbar's text input (but don't highlight the non-matching characters that we would, in this proposal, allow the user to type). Question: Should TAF's concept of selection be merged with the real selection? That might be a little less confusing for users, but it actually doesn't seem all that useful and might get in the way. Future enhancement (hard): Highlight all occurrences of the string (in a different highlight color) once the user stops typing for a certain interval or presses Enter (unless we use Enter to dismiss the toolbar) When the user presses "Esc" or clicks on the page, the toolbar goes away, destroying the selection. Question: Or would there be an advantage to have two different ways of making it go away? I doubt the advantage would outweight the confusion, at least for the ways I can think of. (Current TAF uses "Enter" to mean "go away but make the TAF selection the real selection". However, I'd prefer it to mean "I'm done typing" and then "Find again", as above.) Question: If the user starts typing after pressing Enter, should the typing replace or append to the current text being searched? Where should the find start? Ideally, until the user uses the "Find Next" feature, the search should highlight (and, if needed, move the viewport to) the the first occurrence of the text whose location is below the top of the viewport. (Note that this might require restoring the original viewport position, e.g., if user enters "abcdef" and there's text "abc" in the sidebar, below the viewport, but text "abcdef" in the main part of the page (later in the content tree). Scrolling to see the "abc" shouldn't put the "abcdef" out of range because it's above the new top of the viewport.)

Great. I'm all for merging the two kinds of find and making FAYT more discoverable. 1. The F3 key is also a way to "find next" on some platforms. 2. The Enter key currently means follow the current link. I would only want Enter to mean "find next" if FAYT for text was being used, as opposed to FAYT for links. 3. Would the toolbar show up for FAYT for links? 4. If we get rid of the "find in page" dialog we should make sure the important features it supports are available in FAYT. Currently find in page is still a useful compliment to find as you type, because: - you can paste into it. It would be great if paste worked with FAYT. - you can do a case sensitive search. We have a case sensitive search checkbox in the toolbar, or base it on when the user types mixed-case text. - you can turn wrap around off. Maybe not so important. - you can search textfields and textarea. We had turned this off for FAYT because the green selection wasn't working and no one had the time to fix it. Otherwise it just had a caret so it looked like data entry was happening. 5. FAYT was originally designed as an accessibility feature and putting in some of these great new ideas for mainstream users may cause some problems, perhaps for screen readers. Let's remember FAYT's roots as we do this and not make find any less accessible than it is now, if anything improve it. - The current "find in page" dialog is totally accessible with screen readers. We'd have to test to make sure the new design's putting the focus in this toolbar, and highlighting the correct part of the patch didn't cause any funkiness with screen readers. - Screen magnifiers normally jump to the area of the screen where the selection goes. However, now they will stay at the toolbar near the bottom of the screen rather than showing the user what they've found. That's not a good thing. The only ways I can think of fixing this problem is to have the toolbar be something that can be turned off, or to hack in the screen magnifier to ignore the toolbar's caret/focus. > Question: Should TAF's concept of selection be merged with the real > selection? That might be a little less confusing for users, but it > actually doesn't seem all that useful and might get in the way. It does use the real selection now, we just color it green when FAYT is active. > Future enhancement (hard): Highlight all occurrences of the string (in > a different highlight color) once the user stops typing for a certain > interval or presses Enter (unless we use Enter to dismiss the toolbar) This would be really useful and a killer feature that people would notice in reviews. Note that this can be optimized by doing a couple of things. First, don't do it if they've just typed a single character or if there are more than 200 matches. Second, can we do the visible area of the screen first, then the rest of the doc as a background task? This will give the user the feeling that it happened instantly.

I like this idea. "Any of the following will also cause a 'Find Again': ... The user presses Enter for more than the first time." So the first time someone hits Enter, nothing will happen? That doesn't sound good for discoverability. It's going to be tricky to decide what Enter should do. It could follow a found link (like Esc+Enter), stop Find (like Esc), or act as Find Again (like Ctrl+G). I'd prefer if Enter's behavior did not change based on whether you're restricting Find to links or searching through all text. "When the user presses 'Esc' or clicks on the page, the toolbar goes away, destroying the selection." I think it would be better if Esc left the text selected, like Esc in the current Find dialog does. Leaving the text selected would make it clearer that you can tab from it to nearby links or form controls, press Ctrl+G to Find Again, etc.

*** This bug has been marked as a duplicate of 250231 ***

v